java web applicaton layout, please explain some de

问题:

I'm looking at this java web application that is using hibernate, jsp's, and spring framework. (from what I can tell!)

the file layout is like this:

classes/com/example/project1

inside project1

/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

Have you guys read about this sort of layout somewhere? Is it considered best-practice?

What is the difference between a Factory and a Manager and a Service? (high level)

回答1:

For typical layout of an application built with Spring I'd look at the example web applications that ship with it (meaning Spring).

Using things like DaoFactory is definitely not be a best-practice, the Daos should get injected instead. In general you should not need factories with Spring except for some unusual cases. Injecting is done when the web application starts up, spring reads the configuration information and constructs all the objects and plugs them in according to configuration xml and/or annotations (this is assuming singleton-scope for your objects, which is usual for stateless things like daos and services, things scoped as prototypes get new copies created as the application asks for them).

In Spring applications a service is similar to a Stateless Session Bean, it is a transactional layer encompassing application logic for a use case. So if your user takes an action that has the effect of causing several different tables to get updated you can inject the daos into that service, have a method on that service do the updates on the daos, and configure Spring to wrap that service in a proxy that makes that method transactional.

I've seen manager used as another name for what I described as service. Here I don't know what they're doing with it.

回答2:

I don't like the idea of combining your interfaces and impls in one project. Just because you want to consume the interface doesn't mean you want to consume the impl and it's cumbersome transitive dependencies. The main reason is because there will be more than one impl (hypothetically, i.e. JPA/JDBC/Hibernate, or Axis2/CXF, etc.). The interfaces should not be bound to the implementation, otherwise the point is lost. This also allows for easy dependency injection as the impls simply reside on the classpath, then something like a Proxy or Spring (e.g.) can inject the implementations.

In all likelihood, all you need is a:

Interface Project
   dao
      EntityDao    
   types
      Entity

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