Question

我负责支持使用BusinessObjects（不包含逻辑，只包含属性）的C＃Winforms应用程序和使用操作这些实体的类（'Helpers'）的BusinessLayer。

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

场景1：构造函数

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对象起作用吗？

每个人都在想什么???

Answer 1

是否有任何理由无法将逻辑移动到BusinessObject

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

完全废除助手类。使读取具有更多语义意义，并且无需检查空值。

要维护的课程数量增加一半

Answer 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类，它们将对ent的更改保存到数据库中。

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

但是，假设我不能改变它，你会做什么？

将实体传递给作用于它的方法？ OR
将实体包装到Helper类的构造函数中？

Answer 3

如何让你的CarHelper课程扩展Car

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

两全其美

C＃：将BusinessObject传递给'BusinessLayer'构造函数或其方法？

3 个答案: