我有几个实体具有计算字段，例如 TotalCost。现在我将它们全部作为属性，但我想知道它们是否实际上应该是方法。有这方面的 C# 标准吗？
public class WorkOrder
{
public int LaborHours { get; set; }
public decimal LaborRate { get; set; }
// Should this be LaborCost()?
public decimal LaborCost
{
get
{
return LaborHours * LaborRate;
}
}
}
使用计算属性而不是方法是可以的，只要计算不会花费明显的时间
参见物业使用指南
摘自属性与方法部分：
当成员是逻辑数据成员时使用属性。
在以下情况下使用方法：
该操作是一种转换，例如Object.ToString。
该操作的成本足够高，您想要与 用户应该考虑缓存结果。
使用 get 访问器获取属性值将有一个 可观察到的副作用。
连续两次呼叫会员会产生不同的结果。
执行顺序很重要。请注意类型的属性 应该能够以任何顺序设置和检索。
该成员是静态的，但返回一个可以更改的值。
该成员返回一个数组。返回数组的属性可以是 非常具有误导性。通常需要返回一份副本 内部数组，以便用户无法更改内部状态。这， 再加上用户可以轻松假设它是索引的事实 属性，导致代码效率低下。在下面的代码示例中， 对Methods 属性的每次调用都会创建该数组的一个副本。作为一个 结果，将在下面创建该数组的 2n+1 个副本 循环。
我认为方法应该对对象执行操作，通常是改变对象的状态。即使属性是经过计算的，属性也应该反映对象的当前状态。所以我认为你应该保留你的财产。
我认为它们都应该是属性。 只要它不改变对象的状态，我就很乐意将其作为属性。
此外，如果我使用您的类进行数据绑定（WPF 等），那么我可以直接绑定到您的属性，而无需修改/扩展该类。
如果它们a）轻量级并且b）没有副作用，我会让它们成为属性。
轻量级当然有点模糊，但经验法则是：如果我不得不担心调用属性（无论是在循环中还是在其他地方），它可能应该是一个方法。
我会把它们作为财产留下。但没有“标准”理由以这种或那种方式做事。如果你一个人，就做你最喜欢做的事。如果您在一个团队中，请遵循团队其他成员所遵循的惯例。
如果某个属性的计算成本特别高，我可能会将其更改为 GetWhatever() 方法。这向任何使用我的类的人暗示，该值需要一些重要的工作才能达到，并且调用者应该缓存该值而不是多次调用该方法。
琐碎的计算在属性内部是完全合适的。
在我看来，这是一种偏好；这就是你想做的事。 除非涉及逻辑，否则我在大多数情况下都会做礼仪。 此外，如果您需要传入参数来更改功能，那么显然会应用一种方法......
视情况而定，如果您的“属性”变得庞大并且需要大量的业务逻辑，那么它们不应该是属性，而应该有一个方法。 您发布的示例看起来可以作为财产。 没有标准的做法，跟着你的直觉走；如果看起来需要做很多事情，您可能需要一个方法。
无论如何，它很大程度上只是语法糖，所以希望你在团队中遵循约定，或者你喜欢什么，只要它只是返回有关对象的信息而不更改它或与其他对象交互。
MSDN 提供了相关信息here
类库设计者经常必须 决定是否实现一个类 成员作为属性或方法。在 一般来说，方法代表行动， 属性代表数据。
你觉得是哪一个呢？计算/获取LaborCost 或数据的操作？
WorkOrder workOrder = new WorkOrder();
workOrder.LaborHours = 8;
workOrder.LaborRate = 20;
decimal cost = workOrder.LaborCost; // This is OK here
但是如果您也打算对同一个对象执行此操作：
worOrder.LaborHours = 18;
decimal newCost = workOrder.LaborCost
现在这不可能是财产。如果能成为一个方法就更好了
有时，您还必须考虑您正在建模的内容......在某些领域，计算值通常或预期是模型的属性 - 属性。 如果是这种情况，则将其写为属性，即使计算一点也不微不足道或计算成本有点高。 只需在您的 API 上记录它或实现一些缓存机制即可最大限度地减少此属性的重新计算。