ansaurus

Question

java web applicaton layout, please explain some design principles/patterns

Answer 1

+1 A:

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.

Nathan Hughes 2009-12-28 18:42:30

if they are injected, where would that code generally be? the DI code?

mrblah 2009-12-28 19:23:50

ok that managers just seem to be wrappers around the Doa's, and the services seem to, similiar to what you said, wrap multiple manager calls to form a transactional unit.

mrblah 2009-12-28 19:25:26

>> if they are injected, where would that code generally be? the DI code?Spring would be doing the injecting, you wouldn't have code to do that. Unless you count configuring the spring app context in the web.xml. (Maybe I don't understand your question)

Nathan Hughes 2009-12-28 20:41:32

@nathan, I just didn't know where the injecting is done that's all. I'll look at the web.xml then thanks.

mrblah 2009-12-28 21:09:10

Hope my edits clear that up, the point is Spring takes care of the DI so your code doesn't have to.

Nathan Hughes 2009-12-28 21:31:33

Answer 2

A:

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

Droo 2009-12-28 20:10:33

generally it is a good idea to separate impl and spec as much as possible, but to do it always by project-split could be overkill. every new project involves more overhead (e.g. build-system, code browsing). you mentioned transitive dep problems: they will anyway come through later binding during runtime (when all libraries are loaded). I would only separate projects when spec and impl are meant to be decoupled as a concept, one api -> multiple vendors (e.g. jpa-api -> hibernate-impl, jaxb-api -> jaxb-vendor-impl).

manuel aldana 2009-12-28 20:31:16

ansaurus

tags:

views:

answers:

java web applicaton layout, please explain some design principles/patterns

related questions