C#：将 BusinessObject 传递给“BusinessLayer”构造函数或其方法？答案

【问题标题】：C#: Pass BusinessObject to 'BusinessLayer' Constructor or its methods?C#：将 BusinessObject 传递给“BusinessLayer”构造函数或其方法？
【发布时间】：2011-08-31 18:37:56
【问题描述】：

我负责支持使用 BusinessObjects（不包含逻辑，仅包含属性）的 C# Winforms 应用程序和具有操作这些实体的类（“Helpers”）的 BusinessLayer。

问题：如果您将 BusinessObject 传递给 Helpers 构造函数，然后在构造函数内部，实例化 Helper 的可公开访问的 Entity 变量要么您是否应该将实体传递给对其进行操作的方法？

场景一：构造函数

Car myCar = new Car();
CarHelper ch = new CarHelper(myCar);
ch.Wash(suds);
ch.Upgrade(upgradeKit);
ch.Save();

场景 2：作用于实体的方法

Car myCar = new Car();
CarHelper ch = new CarHelper();
ch.Wash(myCar, suds);
ch.Upgrade(myCar, upgradeKit);
ch.Save(myCar);

我在场景 1 中遇到的两个主要问题： A) 下一个开发人员必须深入研究 CarHelper 类，才能意识到它有一个公共 Car 访问器属性，它在需要它的方法中引用该属性。这进一步混淆了 Helper 类，因为每个方法在执行其职责之前都需要检查“null” Car 属性...... B）如果在操作之间存在大量其他代码，则可能会不清楚 ch.Wash() 实际在做什么......它甚至是否作用于 Car 对象......？

大家怎么看？？？

【问题讨论】：

标签： business-objects business-logic-layer

【解决方案1】：

有什么原因不能将逻辑移到 BusinessObject 中

Car myCar = new Car();
myCar.Wash(suds);
myCar.Upgrade(upgradeKit);
myCar.Save();

完全取消辅助类。阅读起来更具语义意义，并且无需检查空值。

要维护的类也减半

【讨论】：

【解决方案2】：

确实如此……在我看来，将 BusinessObject 中的逻辑封装起来使其具有自我意识也是最好的……但我不认为这是一个选项，因为：

在“应用程序”中，BusinessObjects 位于 DAO 引用的命名空间 (....ApplicationServices) 中，因此它实际上不能调用 DAO 方法（因为它会导致循环依赖） - 所以它可以'不实现功能

myCar.Wash(suds)
{
    this.CleanlinessRating = suds.CleaningAbilityRating;    
    // persist the level of Cleanliness to the DB
    CarDAO.Save(this);
}

整个应用程序背后的前提似乎是 BusinessObjects 根本不实现任何逻辑……它们只是信息的容器，没有任何行为。

然后你就有了作用于实体的 BusinessLayer 类...

然后你就有了 DataLayer 类，它将实体中的更改保存到数据库中。

因此，显然，让实体具有自我意识并实现自己的行为是一个很大的“不”（在这个应用程序中）......我确信这是真正的问题。

但是，假设我无法改变这一点，你会怎么做？

将实体传递给对其进行操作的方法？或
将实体包装到 Helper 类的构造函数中？

【讨论】：

【解决方案3】：

让你的 CarHelper 类扩展 Car 怎么样

CarHelper helper = new Car();
helper.Wash(suds);
helper.Upgrade(upgradeKit);
helper.Save();

两全其美

【讨论】：