c＃中用于赚钱的最佳数据类型是什么？
使用Money pattern来自Patterns of Enterprise Application Architecture;将金额指定为十进制，将货币指定为枚举 .
小数 . 如果你选择加倍，你就会对四舍五入的错误开放
十进制有一个较小的范围，但更精确 - 所以你不会失去所有那些便士随着时间的推移！
详情如下：
http://msdn.microsoft.com/en-us/library/364x0z75.aspx
正如在decimal中描述的那样：
decimal关键字表示128位数据类型 . 与浮点类型相比，十进制类型具有更高的精度和更小的范围，这使其适用于财务和货币计算 .
您可以使用小数如下：
decimal myMoney = 300.5m;
我使用的大多数应用程序都使用 decimal 来代表金钱 . 这是基于这样的假设：应用程序永远不会涉及多种货币 .
decimal
该假设可以基于另一个假设，即该应用程序永远不会用于具有不同货币的其他国家 . 我见过那些被证明是错误的案例 .
现在，这种假设正在以一种新的方式受到挑战：比特币等新货币变得越来越普遍，而且它们并不是针对任何国家的 . 仅在一个国家/地区使用的应用程序可能仍需要支持多种货币并非不切实际 .
有些人会说，仅仅为了赚钱而创建甚至使用某种类型，或者增加了超出已知要求的额外复杂性 . 我非常不同意 . 一个概念在你的领域中越普遍，就越需要合理地预先使用正确的抽象 . 如果你想看到复杂性，尝试使用过去使用 decimal 的应用程序，现在每个 decimal 属性旁边都有一个额外的 Currency 属性 .
Currency
如果你预先使用了错误的抽象，那么以后更换它将是工作量的一百倍 . 这意味着可能会在现有代码中引入缺陷，最好的部分是这些缺陷可能涉及金额，金钱交易或任何有钱的事情 .
而且's not that difficult to use something other than decimal. Google 560790 and you' ll看到很多开发人员已经创建了这样的抽象（包括我） . 它's easy. It'就像使用 DateTime 一样简单，而不是在 string 中存储日期 .
DateTime
string
另一种选择（特别是如果你在路上需要一些"* 10000"并且在出路时需要一些"/ 10000" . 这是微软SQL Server使用的存储机制，参见http://msdn.microsoft.com/en-au/library/ms179882.aspx
这种情况的不同之处在于，所有求和都可以使用（快速）整数运算来完成 .
同意Money模式：使用小数时处理货币太麻烦了 .
如果你创建了一个Currency-class，那么你可以把所有与钱相关的逻辑放在那里，包括一个正确的ToString（）方法，更多的解析值控制和更好的控制分割 .
此外，使用Currency类，没有机会无意中将资金与其他数据混合在一起 .
创建自己的类 . 这似乎很奇怪，但.Net类型不足以涵盖不同的货币 .
System.Decimal
十进制值类型表示十进制数，范围从正数79,228,162,514,264,337,593,543,950,335到负数79,228,162,514,264,337,593,543,950,335 . Decimal值类型适用于需要大量有效积分和小数位且没有舍入误差的财务计算 . Decimal类型不会消除舍入的需要 . 相反，它最大限度地减少了因舍入而导致的错误 .
我想通过zneak指出this excellent answer为什么不应该使用double .
9 回答
使用Money pattern来自Patterns of Enterprise Application Architecture;将金额指定为十进制，将货币指定为枚举 .
小数 . 如果你选择加倍，你就会对四舍五入的错误开放
十进制有一个较小的范围，但更精确 - 所以你不会失去所有那些便士随着时间的推移！
详情如下：
http://msdn.microsoft.com/en-us/library/364x0z75.aspx
正如在decimal中描述的那样：
您可以使用小数如下：
我使用的大多数应用程序都使用
decimal来代表金钱 . 这是基于这样的假设：应用程序永远不会涉及多种货币 .该假设可以基于另一个假设，即该应用程序永远不会用于具有不同货币的其他国家 . 我见过那些被证明是错误的案例 .
现在，这种假设正在以一种新的方式受到挑战：比特币等新货币变得越来越普遍，而且它们并不是针对任何国家的 . 仅在一个国家/地区使用的应用程序可能仍需要支持多种货币并非不切实际 .
有些人会说，仅仅为了赚钱而创建甚至使用某种类型，或者增加了超出已知要求的额外复杂性 . 我非常不同意 . 一个概念在你的领域中越普遍，就越需要合理地预先使用正确的抽象 . 如果你想看到复杂性，尝试使用过去使用
decimal的应用程序，现在每个decimal属性旁边都有一个额外的Currency属性 .如果你预先使用了错误的抽象，那么以后更换它将是工作量的一百倍 . 这意味着可能会在现有代码中引入缺陷，最好的部分是这些缺陷可能涉及金额，金钱交易或任何有钱的事情 .
而且's not that difficult to use something other than decimal. Google 560790 and you' ll看到很多开发人员已经创建了这样的抽象（包括我） . 它's easy. It'就像使用
DateTime一样简单，而不是在string中存储日期 .另一种选择（特别是如果你在路上需要一些"* 10000"并且在出路时需要一些"/ 10000" . 这是微软SQL Server使用的存储机制，参见http://msdn.microsoft.com/en-au/library/ms179882.aspx
这种情况的不同之处在于，所有求和都可以使用（快速）整数运算来完成 .
同意Money模式：使用小数时处理货币太麻烦了 .
如果你创建了一个Currency-class，那么你可以把所有与钱相关的逻辑放在那里，包括一个正确的ToString（）方法，更多的解析值控制和更好的控制分割 .
此外，使用Currency类，没有机会无意中将资金与其他数据混合在一起 .
创建自己的类 . 这似乎很奇怪，但.Net类型不足以涵盖不同的货币 .
System.Decimal
我想通过zneak指出this excellent answer为什么不应该使用double .