So, this is are the 5 tiers (please correct me if I misunderstood something).
I think often people will group Data Storage, ORM and the Repository in one 'layer' as far as your code is concerned. Also, don't forget about presentation.
If I have business logic that is related to a single entity, should I implement it in the Entity, or in the Service?
Yes, if it is behavior related to the entity then it should reside within the Entity. Entities shouldn't just be simple data containers, rather the Entity/Model layer should encapsulate both data-structure and behavior related to your business model. In this way, if you need to reuse the Model layer in another app, you dont have to dig around to find the related behavior that you stuck in other layers.
For example, if I have a post and want to retrieve all its comments that are approved, > should it be Post.getApprovedComments (entity) or > CommentsService.getApprovedCommentsForPost(Post post)?
Difficult to say without knowing more about your architecture and ORM. I'd probably go with the Post.. route (comments should be a collection on the Post entity), and then getApprovedComments could be a simple linq query or such. The Service based approach you suggest doesn't look very OOP to me.
(No, it's not right to use post.getComments().filter(c -> comment.approved), because that moves business logic out of the Model. Just in case someone asks.)
I'm not entirely sure I agree with you here. For something this simple, some might think it acceptable.
I'd add that:
Service (handles business logic like Get the 5 newest posts ordered alphabetically by title, uses the Repository)
...is in my opinion not a good example of a service. The service layer is doing nothing in this example - this should just be a query method defined in the PostRepository.
发布评论
评论（1）
我认为就代码而言，人们通常会将数据存储、ORM 和存储库分组在一个“层”中。另外，不要忘记演示。
是的，如果它是与实体相关的行为，那么它应该驻留在实体内。实体不应该只是简单的数据容器，实体/模型层应该封装与业务模型相关的数据结构和行为。这样，如果您需要在另一个应用程序中重用模型层，则不必四处挖掘以找到卡在其他层中的相关行为。
如果不了解更多关于您的架构和 ORM 的信息，很难说。我可能会选择 Post.. 路线（评论应该是 Post 实体上的集合），然后 getApprovedComments 可以是一个简单的 linq 查询等。您建议的基于服务的方法对我来说看起来不太面向对象。
我不完全确定我同意和你在一起。对于这么简单的事情，有些人可能会认为可以接受。
我想补充一点：
……在我看来，这不是一个很好的服务示例。在此示例中，服务层没有执行任何操作 - 这应该只是 PostRepository 中定义的查询方法。
希望其中一些能有所帮助......
I think often people will group Data Storage, ORM and the Repository in one 'layer' as far as your code is concerned. Also, don't forget about presentation.
Yes, if it is behavior related to the entity then it should reside within the Entity. Entities shouldn't just be simple data containers, rather the Entity/Model layer should encapsulate both data-structure and behavior related to your business model. In this way, if you need to reuse the Model layer in another app, you dont have to dig around to find the related behavior that you stuck in other layers.
Difficult to say without knowing more about your architecture and ORM. I'd probably go with the Post.. route (comments should be a collection on the Post entity), and then getApprovedComments could be a simple linq query or such. The Service based approach you suggest doesn't look very OOP to me.
I'm not entirely sure I agree with you here. For something this simple, some might think it acceptable.
I'd add that:
...is in my opinion not a good example of a service. The service layer is doing nothing in this example - this should just be a query method defined in the PostRepository.
Hope some of that helps a little...