0

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

问题：您是否应该将 BusinessObject 传递给 Helpers 构造函数，然后在构造函数中实例化 Helper 的可公开访问的 Entity 变量，或者您是否应该只将 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 对象起作用...？

大家怎么看？？？

4

3 回答 3

0

有什么理由不能将逻辑移动到 BusinessObject 中

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

完全取消助手类。使阅读更具语义意义，并​​且无需检查空值。

需要维护的类也减半

于 2011-05-27T01:32:49.253 回答
0

让你的 CarHelper 类扩展 Car 怎么样？

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

两全其美

于 2011-05-27T01:44:44.433 回答
0

这是非常正确的......在我看来，将 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 类，它将实体中的更改保存到数据库中。

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

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

  1. 将实体传递给对其进行操作的方法？或者
  2. 将实体包装到 Helper 类的构造函数中？
于 2011-05-27T01:37:38.973 回答