我的服务对象真的属于实体包吗？
我注意到我工作的地方，我们倾向于将服务级别对象放入实体包中。这让我怀疑我的实体类概念是否错误。我认为实体类代表关系数据库中的表，对吗？如果是这样，您建议将这些对象放在哪里，也许放在服务对象包中？
I've noticed where I work, that we have a tendency to put our Service level objects into our entity package. This made me wonder if my concept of an entity class was wrong. I though entity classes represented a table in a relational database, am I correct? If so, where would you recomend putting these objects, perhaps in a Service objects package?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我根据他们的关注点在逻辑上将他们分开。即使有数据访问层、服务层等，其要点也是关注点分离。我倾向于有点过分，但我会做类似的事情：
也就是说，如果您打算将所有内容都保留在同一个项目中。我可能会将服务和模型代码分离到它自己的项目中，以防万一（例如），您可能编写一个单独的 Web 服务并重用相同的域模型。
仅供参考，我不是 DAO 的粉丝，但它们相当普遍。我不确定将 dao 放在哪里，但我可能会遵循相同的约定。额外的包只是另一个文件夹，没什么大不了的，并且尽可能地组织代码是有意义的。
I logically separate them based on their concern. The point of even having a Data Access layer, Service layer, etc. is separation of concerns. I tend to go a little over board, but I do something similar to:
That is, if you intend to keep everything in the same project. I would probably separate the service and model code into it's own project, in case (for example), you might write a separate web service and reuse the same domain model.
FYI, I'm not a fan of DAOs, but they're pretty prevalent. I'm not sure where I would put a dao, but I'd probably follow the same convention. An extra package is just another folder, it's no biggie, and makes sense to organize your code as much as possible.
在我这里，我们在模块内的包中定义实体对象。然后，服务接口将位于同一包、同一模块中，但实现将位于不同模块的同一包中。将与 EntityX 相关的所有代码保存在同一个包中可能会很好；其中包括 Entity、Dao 和 Service 的定义和实现。
Where I'm at, we define the entity object in a package within a module. Then, the service interface will be in the same package, in the same module, but the implementation will be in the same package in a different module. It can be nice to keep all the code related to EntityX within the same package; that includes the Entity, Dao, and Service definitions and implementations.