业务对象中需要构建哪些功能？
您认为至少应该将哪些功能内置到持久业务对象中？
例如：
- 验证
- 与同一类型的另一个对象进行比较的方法
- 撤消能力（回滚更改的能力）
What functionality do you think should be built into a persistable business object at bare minimum?
For example:
- validation
- a way to compare to another object of the same type
- undo capability (the ability to roll-back changes)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
由域和域规定的功能商业。
请阅读领域驱动设计。
The functionality dictated by the domain & business.
Read Domain Driven Design.
持久性业务对象应包含以下内容：
通常，您将抽象功能以将它们检索到支持以下内容的存储库中：
您还可以将此类功能包装到集合类中（例如 BusinessObjectTypeCollection） ），但是，在域驱动设计中使用存储库模式来提供这些类型的访问器（例如 InvoicingRepository.GetAllCustomers、InvoicingRepository.GetAllInvoices）有很多进展。
您可以将业务规则放在“新建”、“保存”、“更新”、“删除”中……但有时您可能有一个外部业务规则引擎来将对象传递给它。
A persistable business object should consist of the following:
Often, you'll abstract the functionality to retrieve them into a repository that supports:
You could also wrap this type of functionality into collection classes (e.g. BusinessObjectTypeCollection), however there's a lot of movement towards using the Repository Pattern in Domain Driven Design to provide these type of accessors (e.g. InvoicingRepository.GetAllCustomers, InvoicingRepository.GetAllInvoices).
You could put the business rules in the New, Save, Update, Delete ... but sometimes you could have an external business rules engine that you pass off the objects to.
这只是答案的一部分，但我想说您需要一种方法来获取与该对象有关系的所有对象。一开始，您可能会尝试变得聪明，只为某些关系提供单向导航性，但我发现这通常带来的麻烦多于其价值。
所有持久性框架还包括查找器、进行级联删除的方法……排序……
一旦开始建模，所有业务对象都应该知道如何管理自身。每当您发现另一个类过多引用您的业务对象时，通常就应该将该行为推入业务对象本身。
This is just one piece of an answer, but I would say that you need a way to get to all objects with which this object has a relationship. In the beginning you may try to be smart and only include one-way navigability for some relationships, but I have found that this is usually more trouble than it's worth.
All persistent frameworks also include finders, ways to do cascading deletes... sorts....
Once you start modeling, all business objects should know how to manage themselves. Whenever you find another class referring TO your business object too much, it's usually time to push that behavior into the business object itself.
在问题中提到的三件事中，我想说验证是唯一真正需要的。其他取决于应用程序的整体架构。
此外，业务规则应该位于业务对象中。
对象是否应该进行自己的序列化是一个有趣的问题。过去，我通过让每个对象处理自己的序列化而取得了巨大的成功，但我也看到了使用序列化模块加载和保存业务对象的优点，就像 GUI 写入和读取对象一样。然后，您的验证也将防止数据库或文件中出现错误。
我想不出还有什么一般需要的。
Of the three things noted in the question, I would say that validation is the only one that is truly required. The others depend on the overall archetecture of the application.
Also, the business rules should be in the business objects.
Whether an object should do its own serialization is an interesting question. I have had great success in the past by having each object handle its own serialization, but I can also see merit in having a serialization module load and save the business objects just the same way as the GUI writes to and reads from the objects. Then your validation will protect against errors in the database or files too.
I can't think of anything else that is required in general.