编写服务只是为了重构持久性逻辑？
我有一段业务逻辑，我认为它应该属于域类。但逻辑应该以持久化到数据库结束，这显然不应该是域类的一部分。那么这是什么意思？这种情况会迫使我将逻辑放入服务中吗？或者至少有一个服务引用域类的逻辑方法，然后持久化到数据库。（？）
举例来说，我想将交易发布到证券账户中。许多验证逻辑仅在帐户字段内部，因此看来该逻辑应该位于域类内部。但我随后需要一个 AccountTransactionService，它只需调用域类的逻辑，接收有关事务是否执行的 true/false，然后保存对象（如果发生更改）。看来很多Service类只做这种方法的“转发”，然后根据结果进行保存。但这也许是一种非常典型的服务性质？
只是寻求一些建议，因为我不习惯编写服务类，这很好地反映了这一点。除了重构域类对持久性逻辑的依赖之外，我还应该考虑 Service 类的什么其他目的？
顺便说一句，我只是编写供个人使用的应用程序。因此，我实际上不必仅仅为了遵守所有准则而遵守。
I have a piece of business logic, that I feel should belong in a domain class. But the logic should end with persisting to the database, and this should obviously not be part of the domain class. So what does this mean; Will such situation enforce me to put the logic in a Service? Or at least a service referencing the logic methods of the domain class, and then persisting to database.. (?)
Say for example I want to post a transaction into a securities account. Much verification logic is internal to the account fields only, and such it seems this logic should be inside the domain class. But I then need an AccountTransactionService which simply calls this logic of the domain class, receives a true/false, on whether transaction was performed, and then saves the object if changed. It seems it will be many Service classes which only does this type of "forwarding" of methods, and then saving based on the result. But maybe this a very typical nature of services?
Just looking for some advice, as I'm not used to writing service classes, which this well reflects. What other purpose should I consider for the Service class, except just to refactor out the dependency on persistence logic from the domain class?
Btw, I'm just writing applications for my personal use. So I don't really have to respect all guidelines just for the sake of it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在典型情况下，拥有此类服务（所谓的“应用程序服务”）是可以的，但是如果您有很多逻辑位于域逻辑和持久性逻辑之间的边界，这迫使您编写大量几乎复制粘贴的服务根本不这样做。如果任何“最佳实践”对您没有任何帮助，您就不应该遵循它们。
这是一个有趣的话题，并且非常依赖于具体情况，您能否分享一些代码以解决具体问题？
In the typical case it's okay to have such services, so called "Application Services", but if you have a lot of logic that lies on the boundary between domain logic and persistence logic that is forcing you to write tons of the almost copy-paste Services that just don't do this. You shouldn't follow any "best practices" if they gives nothing to you.
This is an interesting topic and is very dependent on the particular case, could you please share some code in order to solve concrete problems?