基础商务舱：不好吗？

Question

我想创建我的基本业务类，比如EntityBase，有一些常见的行为，比如实现跟踪对象（IsNew，IsDirty）和INotifyPropertyChanges接口中的更改的接口。

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

那你们觉得怎么样？是好还是坏？如果不好，为什么？请尽量做一个实际的人，而不是理论上的。

Answer 1

很多人赞同Single Responsibility Principle的想法，其中说一个班级应该只有一个责任区。通过将状态跟踪，渲染等构建到一个公共基类中，您肯定会违反SRP。如果您的类处理许多任务，则有很多原因需要更改。

Answer 2

这很糟糕。我们已经使用了好几年了，而且我们的基类中没有任何东西可以放在通用的基础上，它应用于所有继承的类。

Answer 3

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

如果要将更改跟踪从基类中分离出来，那么在更改跟踪的情况下，您应该查看Unit of Work模式，尽管在您指出的时候看到更改跟踪已经很常见了.net不依赖于ORM的应用程序。

Answer 4

我认为，如果您的业务实体不需要从这些基础派生，那么实现那些提供您希望在业务实体中使用的常用功能的接口和基类的集合并不一定是坏事。类。这为您提供了实施的灵活性，同时提供了实施的便利。

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

我从Web获取输入并包含字符串数据的大多数类派生自XSSValidatedEntity类（实现IValidatedEntity接口），但通过HTML解析器提供XSS检查以防止将HTML注入数据库。对于我的大多数类而言，这种方法很好，但在那些我想允许有限（安全）HTML的情况下，我显然无法从这个类派生。

Answer 5

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

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