java web应用程序布局，请解释一些设计原则/模式

我正在研究这个使用hibernate、jsp和spring框架的JavaWeb应用程序。（据我所知！）

文件布局如下所示：

classes/com/example/project1

内部项目1

/dao
    _entity_Dao.java
/dao/hibernate/
    _entity_DaoHibernate.java
/factory
     DaoFactory.java
      DaoFactoryImpl.java
/managers
      _entity_Manager.java
/managers/impl
      _entity_ManagerImpl.java
/model
      _entity_.java
/service
      _xxxx_Service.java
/service/impl/
      _xxxx_ServiceImpl.java

你们在什么地方读过这种布局吗？这被认为是最佳实践吗

---

工厂、经理和服务之间的区别是什么？（高级）

对于使用Spring构建的应用程序的典型布局，我将查看随附的示例web应用程序（意思是Spring）

使用像DaoFactory这样的东西肯定不是最佳实践，应该注入DAO。一般来说，除了一些不寻常的情况，你不应该需要带弹簧的工厂。当web应用程序启动时，spring读取配置信息并构造所有对象，并根据配置xml和/或注释将它们插入（这是假设对象的单例作用域，这对于DAO和服务之类的无状态对象来说很常见，作为原型作用域的对象会在应用程序请求时创建新的副本）

在Spring应用程序中，服务类似于无状态会话Bean，它是一个事务层，包含用例的应用程序逻辑。因此，如果您的用户采取的操作导致多个不同的表得到更新，您可以将DAO注入到该服务中，让该服务上的方法在daos，并将Spring配置为将该服务包装在代理中，从而使该方法具有事务性

---

我见过manager被用作我所描述的服务的另一个名称。在这里，我不知道他们在用它做什么。

我不喜欢在一个项目中结合界面和impl的想法。仅仅因为你想使用界面并不意味着你想使用impl，它是一个麻烦的可传递依赖项。主要的原因是因为将有多个IML（假设是JPA/JDBC/Hibernate或Axis2/CXF等）。接口不应绑定到实现，否则就失去了重点。这还允许轻松地进行依赖注入，因为IML只是驻留在类路径上，然后是代理或Spring（例如）可以注入实现

很可能，您所需要的只是：

Interface Project
   dao
      EntityDao    
   types
      Entity

HibernateImpl Project
   dao
      EntityHibernateDao
   src/main/resources/
      EntityMapping.cfg.xml

---

如果它们被注入，代码通常会在哪里？DI代码？好吧，管理者似乎只是围绕Doa的包装器，服务似乎与您所说的类似，包装多个管理器调用以形成一个事务单元。>>如果它们被注入，代码通常会在哪里？DI代码？Spring将进行注入，您将没有代码来执行此操作。除非您将在web.xml中配置spring应用程序上下文计算在内。（可能我不理解您的问题）@nathan，我只是不知道注入是在哪里完成的，仅此而已。我将查看web.xml，然后谢谢。希望我的编辑能够澄清这一点，关键是Spring负责DI，所以您的代码不必如此。一般来说，尽可能多地分离impl和spec是一个好主意，但总是通过项目拆分来完成这项工作可能会有些过分。每一个新的专业人士ject涉及更多的开销（例如，构建系统、代码浏览）。您提到了可传递的dep问题：它们无论如何都会在运行时通过后期绑定（当所有库都加载时）。我只会在spec和impl作为一个概念解耦时分离项目，一个api->多个供应商（例如jpaapi->hibernate impl，jaxb-api->jaxb-vendor impl）。在类名中使用下划线肯定被认为是不好的做法