.net - 基础商务舱：不好吗？

Question

我想创建我的基础业务类，例如 EntityBase，以具有一些常见的行为，例如实现用于跟踪对象更改的接口（IsNew、IsDirty）和 INotifyPropertyChanges 接口。

但是很多人说拥有一个基础业务类并从中派生所有业务对象是个坏主意。通常他们说在实体类中有表示代码是不好的。但我认为这只是一个理论。实践中有什么不好？他们说：自己试试。通常没有更多的争论。

那你们怎么看？是好还是坏？如果不好，为什么？请尝试做一个实际的人，而不是理论的人。

Answer 1

很多人赞同单一职责原则的理念，即一个类应该只有一个职责范围。通过将状态跟踪、渲染等构建到一个公共基类中，您肯定会违反 SRP。如果你的班级处理了很多任务，它会有很多改变的理由。

Answer 2

这不好。我们使用这个已经好几年了，我们可以在我们的基类中放入任何足够通用的东西，以使其适用于所有继承的类。

Answer 3

从面向对象设计的角度来看，这可能不是最优雅的解决方案，但如果要使用数据绑定，在基类中实现 INotifyPropertyChanged 通常是个好主意。通过这种方式，您可以最大程度地减少必须在所有实体中实施它的负担。

在更改跟踪的情况下，如果您想将该职责与基类分开，您应该查看工作单元模式，尽管正如您在.net 应用程序中指出的那样，看到更改跟踪实现很常见。依赖于 ORM。

Answer 4

如果您的业务实体不需要从这些基类派生，我认为拥有一组接口和基类来实现这些接口并提供您在业务实体中想要的一些通用功能，这并不一定是坏事。这为您的实施提供了灵活性，同时提供了实施的便利。

例如，我有一个 IValidatedEntity 接口，它几乎应用于我创建的每个业务对象。它要求业务对象实现一些验证规则。但是，我的审计对象只在内部创建，我使用单元测试来确保我不能创建无效的审计对象，因此这些类不实现 IValidatedEntity 接口

我的大多数类都从 Web 获取输入并包含字符串数据，它们都派生自 XSSValidatedEntity 类（它实现了 IValidatedEntity 接口），但通过 HTML 解析器提供 XSS 检查以防止将 HTML 注入数据库。对于我的大多数类，这都可以正常工作，但在那些我想允许有限（安全）HTML 的情况下，我显然不能从这个类派生。

Answer 5

您所描述的内容听起来更像是一个表示对象，但 IsDirty 和 IsNew 也可以在域模型中使用。在决定在基础对象中包含什么之前，您应该清楚地了解业务需求是什么。专注于业务对象片刻，需求会有多静态？你是否掌握了所有控制对象如何交互的规则，这些规则会改变吗？如果他们改变，多久改变一次？这对你来说可能是最具挑战性的

您可能会发现，根据应用程序，您的大部分工作应该来自实现业务流程，因此应该来自 CRUD 功能的架构。虽然很重要，但不是你努力的重点。换句话说，您的业务对象将支持业务流程的概念，而不包括 IsDirty。然后，您的数据访问层可以专注于记录的状态并确定是插入还是更新数据。