基础商务舱：不好吗？
我想创建我的基本业务类（例如 EntityBase），以具有一些常见行为，例如实现用于跟踪对象更改的接口（IsNew、IsDirty）和 INotifyPropertyChanges 接口。
但许多人表示，拥有一个基本业务类并从中派生所有业务对象是一个坏主意。 通常他们说在实体类中包含表示代码是不好的。 但我认为这只是一个理论。 实践中有什么不好的地方？ 他们说：你自己尝试一下。 通常不再争论。
那么你们觉得怎么样？ 是好还是坏？ 如果不好，为什么？ 请努力做一个务实的人，而不是理论家。
I would like to create my base business class, something like EntityBase, to have some common behavior, such as implementing interface to track changes in the object (IsNew, IsDirty) and INotifyPropertyChanges interface.
But many people say it's a bad idea to have a base business class and derive all your business objects from it. Usually they say that it is bad to have presentation code in the entity class. But I think it's just a theory. What is bad in practice? They say: try it yourself. No more arguments usually.
So what do you guys think? Is it good or bad? If bad, why? Please, try to be a practical person, not theoretic.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
这不好。 我们已经这样做了好几年了，但我们无法在基类中放入任何足够通用的内容以适用于所有继承的类。
It's bad. We had this for several years, and there was nothing we could put in our base class that was generic enough that it applied to all inherited classes.
从面向对象设计的角度来看，也许这不是最优雅的解决方案，但如果要使用数据绑定，在基类中实现 INotifyPropertyChanged 通常是个好主意。 通过这种方式，您可以最大限度地减轻在所有实体中实施它的负担。
在更改跟踪的情况下，如果需要，您应该查看 工作单元 模式将该责任与基类分开，尽管正如您在不依赖 ORM 的 .net 应用程序中指出的那样，很常见看到实现的更改跟踪。
Maybe it's not the most elegant solution from the standpoint of object oriented design, but if you are going to use data binding, it's often a good idea to implement INotifyPropertyChanged in a base class. This way you can minimize the burden of having to implement it in all your entities.
In the case of change tracking you should take a look at the Unit of Work pattern if you want to separate that responsibility from your base class, although it's very common to see change tracking implemented as you point out in .net applications that don't rely in an ORM.
我认为，如果您的业务实体不需要从这些基类派生，那么拥有一组接口和实现这些接口的基类不一定是坏事，这些接口提供了您在业务实体中所需的一些通用功能。 这为您提供了实施的灵活性，同时提供了实施的便利性。
例如，我有一个 IValidatedEntity 接口，该接口几乎应用于我创建的每个业务对象。 它要求业务对象实现一些验证规则。 但是，我的审核对象仅在内部创建，并且我使用单元测试来确保我无法创建无效的审核对象，因此这些类不会实现 IValidatedEntity 接口
我的大多数类从网络获取输入并包含字符串数据派生自 XSSValidatedEntity 类（实现 IValidatedEntity 接口），但通过 HTML 解析器提供 XSS 检查以防止将 HTML 注入数据库。 对于我的大多数类来说，这工作得很好，但在那些我想允许有限（安全）HTML 的情况下，我显然无法从此类派生。
I don't think that it's necessarily bad to have a set of interfaces and base classes implementing those interfaces that provide some common functionality that you want in your business entities, if your business entities aren't required to derive from those base classes. This gives you flexibility in your implementation while providing convenience of implementation.
For example, I have an IValidatedEntity interface that gets applied to just about every business object that I create. It requires that the business object implement some validation rules. However, my audit objects are only created internally and I use unit testing to make sure that I can't create invalid audit objects so these classes don't implement the IValidatedEntity interface
Most of my classes that take input from the web AND contain string data derive from a XSSValidatedEntity class (which implements the IValidatedEntity interface), but provides XSS checking via an HTML parser to prevent injecting HTML into the database. For most of my classes this works fine, but in those instances where I want to allow limited (safe) HTML, I obviously can't derive from this class.
您所描述的听起来更像是一个表示对象，但 IsDirty 和 IsNew 也可以在域模型中使用。 在决定基础对象中包含哪些内容之前，您应该清楚地了解业务需求是什么。 暂时关注业务对象，需求的静态程度如何？ 您是否掌握了控制对象如何交互的所有规则？这些规则会改变吗？ 如果改变，多久改变一次？ 这对您来说可能是最具挑战性的。
您可能会发现，根据应用程序，您的大部分工作应该来自实现业务流程，从而实现 CRUD 功能的架构。 虽然很重要，但不是你努力的重点。 换句话说，您的业务对象将支持业务流程的概念，并且不包括 IsDirty。 然后，您的数据访问层可以专注于记录的状态并确定是插入还是更新数据。
What you are describing sounds more like a presentation object, yet the IsDirty and IsNew could also be used in a domain model as well. Before deciding on what to include in your base objects you should have a clear picture of what the business requirements are. Focusing on the business objects for a moment, how static will the requirements be? Do you have a grasp on all your rules that govern how the objects will interact, and will those rules change? If they change, how often? This may prove the most challenging for you
You may find that depending on the application, the bulk of your work should come from implementing the business process, and therefore the architecture of the CRUD functionality. while being important, is not the focus of your efforts. In other other words, your business objects will support the concepts of the business process, and not include IsDirty. Your Data Access Layer can then concentrate on the state of the records and determine whether to Insert or Update data.
很多人都赞同单一职责原则的想法，它说一个类应该只有一个单一的职责范围。 通过将状态跟踪、渲染等构建到公共基类中，您肯定会违反 SRP。 如果你的类处理很多任务，那么它就会有很多改变的理由。
A lot of people subscribe to the idea of Single Responsibility Principle, which says that a class should only have a single area of responsibility. By building state tracking, rendering and so forth into a common base class, you'll certainly violate the SRP. If you class handles many tasks, it will have many reasons to change.