我正在编写一个使用Spring作为我的主要框架的大中型Web应用程序，我想知道是否应该为每个仓库创建一个服务层，或者为多个仓库提供一个服务是一个好习惯吗？
例如，如果我有一个notes，user和user_notes表，我打算将notes和user_notes放在一个服务层中，这是一个很好的做法吗？
答案 0 :(得分：0)
取决于。
如果没有正当理由存在无数空洞服务并不是一种好的做法，并且拥有多重职责的课程（无论是服务还是其他什么）都不是一种好的做法。 。是否与ServiceA进行交互会自动意味着您还会在接下来的几行中与ServiceB进行互动？也许那些可以合并。只使用大型服务的部分？检查拆分成较小的部分是否有意义。
当你以这种方式看待它并且你决定UserNotesManagingServiceThingy是一个单位然后做它。如果没有，那么拆分它。无论如何，第一个看待你的设计的人都会有相反的感受。
答案 1 :(得分：0)
理想情况下，每个域实体都应该拥有自己的服务。当任何用例需要从多个实体获取数据时，所有这些实体的顶部应该有一个外观服务。该Facade将负责按顺序调用其下的所有实体。
下一个重要的部分是根据用例的要求整理来自所有这些服务的数据，这通常由视图设计决定，或者在休息api的情况下 - 响应的模式。
要将此整理数据从服务传送到控制器，应创建针对特定用例的DTO（数据传输对象）。但是，DTO不应该理想地用作表单支持bean。它们只应用于跨层传输数据并将其交给Controller方法。
从DTO到UI特定表单支持bean的映射应该在ViewHelper中完成，或者作为Controller中的私有方法完成。
所以流程是 UI / View（表单支持Bean）＆gt;控制器＆gt; （DTO）＆gt;服务＆gt;（模型）＆gt; DAO＆gt; DB和反向相同。
此处的服务可以是外观，可以扩展为 Facade Service＆gt;多个服务，如上所述。通过外观对多个服务进行委派也有助于以更好的方式管理事务。
要回答有关注释，user_notes和用户实体的特定问题，似乎应该有两个服务UserService和NotesService。您可以在NotesService中使用FetchNotesByUserId（）等方法，在UserService中使用其他方法，以防万一用户和Notes具有多对多关系。