使用来自企业应用程序体系结构模式的Money模式。指定金额为十进制，货币为枚举。

同意货币模式:当你使用小数时，处理货币太麻烦了。

如果您创建了currency类，那么您就可以将所有与货币相关的逻辑放在那里，包括正确的ToString()方法、对解析值的更多控制以及对除法的更好控制。

此外，使用Currency类，就不会意外地将货币数据与其他数据混淆。

使用来自企业应用程序体系结构模式的Money模式。指定金额为十进制，货币为枚举。

另一种选择(特别是如果您滚动自己的类)是使用int或int64，并指定后面的四位数字(甚至可能是2)为“小数点的右侧”。所以“在边缘”，你需要一些“* 10000”在入口，一些“/ 10000”在出口。这是微软SQL Server使用的存储机制，请参见http://msdn.microsoft.com/en-au/library/ms179882.aspx

这样做的好处是，所有的求和都可以用(快速的)整数算术来完成。

我使用过的大多数应用程序都使用十进制来表示钱。这是基于应用程序永远不会涉及一种以上货币的假设。

这个假设可能是基于另一个假设，即该应用程序永远不会在使用不同货币的其他国家使用。我见过一些案例，结果证明这是错的。

现在，这种假设正以一种新的方式受到挑战:比特币等新货币正变得越来越普遍，而且它们并不局限于任何国家。仅在一个国家使用的应用程序可能仍然需要支持多种货币，这并非不切实际。

有些人会说，仅仅为了钱而创建甚至使用类型是“镀金”，或者在已知需求之外增加额外的复杂性。我坚决不同意。一个概念在您的领域中越普遍，就越有必要做出合理的努力，预先使用正确的抽象。如果您想了解复杂性，可以尝试在一个过去使用十进制的应用程序中工作，现在每个十进制属性旁边都有一个额外的Currency属性。

如果您在前面使用了错误的抽象，那么稍后替换它将是百倍的工作。这意味着可能会在现有代码中引入缺陷，而最好的部分是这些缺陷可能涉及大量的金钱、金钱交易或任何与金钱有关的东西。

用小数以外的数并不难。谷歌“金币类型”，您将看到许多开发人员创建了这样的抽象(包括我)。很容易。这就像使用DateTime而不是将日期存储在字符串中一样简单。

创建自己的类。这看起来很奇怪，但是. net类型不足以覆盖不同的货币。