C# 数据建模问题-数据和计算的分离以及访问器逻辑

好的，所以我想听听大家对这个话题的看法

我有一个愚蠢的数据对象-CustomerOrder

CustomerOrder有价格和数量，但也有TotalCash属性（价格*数量）。所以我有一个totalCash属性，但我不想直接将计算结果放入对象中，因为这会打破愚蠢的数据对象规则。我确实需要在整个应用程序中一次又一次地获取现金流，因此我需要集中计算。我可以创建一个cashFlowCalculator类并传入customerOrder，但我不希望每个简单的计算都有另一个类

---

有什么想法或最佳实践吗？

我理解将数据对象与业务逻辑分开的基本原理。通过将LINQ与设计器生成的类一起使用，我可以使用包含业务逻辑的部分类实现来扩展生成的类。我觉得这已经足够满足我的需要了。如果这对您不起作用，那么我将同时拥有数据对象和业务对象——可能有1-1对应关系，可能没有。工厂类或方法可用于在业务对象和数据对象之间进行转换。然后，只需在业务对象中实现您的业务逻辑，而不需要辅助对象进行计算。

在相同的情况下，我会打破“哑数据对象规则”，因为我不希望特定的计算经常更改。我可能会把它作为一个getter来实现

---

对于更复杂的场景，有必要创建一个OrderCalculator类，该类接受与订单相关的类，并可以执行各种计算，例如包括税、测量利润等。这样，您就可以将执行计算的责任委托给CustomerOrder之外的人。这样一来，客户订单就不需要知道德克萨斯州的州税来确定是否需要销售税，例如。

为什么不采用扩展方法

public sealed class CustomerOrder
{
    public decimal Price;
    public decimal Quantity;
}

public static class CustomerOrderExtensions
{
    public static decimal GetTotalCash(this CustomerOrder data)
    {
        return data.Price*data.Quantity;
    }
}

---

您甚至可以将扩展静态类移动到不同的命名空间中。

如果这是从datatable更新的数据传输对象（DTO），我建议向该表中添加TotalCash Datacolumn，并将Datacolumn属性设置为“price*quantity”。在dumb（DTO）类中创建从datatable更新的TotalCash只读属性。从面向对象的角度来看，这是应该采用的方式

另一种选择[对于这里的老手来说可能太简单了；-）]是让哑数据对象具有计算字段的属性，但让检索数据的SQL查询进行计算（一次）；当然，这些字段只读为

< P>我认为你应该考虑如果你真的想要ToalCalm是一个计算/导出的属性……/P> 考虑-如果计算的业务逻辑发生变化，对现有记录的TotalCash属性进行追溯性更改可能是不可取的

我会考虑将属性设为DTO的非计算成员，也可能使用ToalCutoCalp服务类来确定设置值。

---

只要我的2美分。

我会计算您的DTO中的总现金（这将是YAGNI）。如果将来您需要更改TotalCash的行为，那么可以考虑使用TotalCashCalculator并通过DI将其传递到订单中。

您使用的是数据集和数据表吗？好问题-派生/计算属性非常常见。我很想看到一些最佳实践由此产生。