Announcement Announcement Module
Collapse
No announcement yet.
Separating interface and implementation with Spring Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Separating interface and implementation with Spring

    Hi,

    I'm a new Spring user and I have a few questions.

    Our system is set up in such a way that the data access module is separate from the application. So, this gives us two, separately-maintained, modules. Data access is defined in module A, our web app is in module B. Before compiling module B, we must compile and import module A. Fairly simple, so far.

    Module A has no concept of a Web application. Our classes are (now) generated with Middlegen and we use Hibernate. For the time being, I haven't written any DAO implementation. When I sat down to do so, I realized that I needed to extend some of Spring's classes (HibernatDaoSupport, for example). This would pollute our model.

    It looks to me that I would need to define my DAO interfaces in module A but put the implementation in module B, where it's OK to use the web context stuff. Or, create another module that would contain the Spring implementation of the data access.

    Is my assessment correct or am I missing something obvious?

    Thanks,

    L

  • #2
    This would pollute our model
    Does it matter if it's behind an interface?

    put the (DAO) implementation in module B, where it's OK to use the web context stuff
    Your concern seems to be in making web dependencies in the DAO. This is not an issue - you shouldn't have to access web context stuff to implement the DAO.

    Comment


    • #3
      As mentioned, your web layer ALONE deals with web related objects (HttpSession, HttpServletRequest etc). The web layer's Controllers must build themselves or obtain your domain model POJOs from the services layer. Your services layer never sees any web related objects. Your services layer in turn deals with the DAO layer, and I'm sure you get the idea by now.

      Your services layer is where you put transaction demarcation and enforce security. You pass domain object POJOs around in method arguments. The only real exception is some application-wide concern such as the currently logged on user or perhaps the license your application is running. Rather than passing such objects around in every method signature, you can put such inter-layer concerns in a ThreadLocal (or if they don't vary between requests, like a license, they belong in the Spring application context). Such objects will never contain a web related (HttpSession, HttpServletRequest etc) object. If a services or DAO layer is accessing a web related object, it indicates a fundamental design problem.

      Your DAO layer is often where you'll introduce domain related interceptors to ensure items presented to the DAO layer are completely valid. You could do that on services layer beans, but then if the services layer creates a bean or modifies it (which is very common) it wouldn't get intercepted. Sometimes people also do this using a persistence engine-specific interceptor, which I find unnecessarily limits portability and they're generally less flexible than an AOP Alliance MethodInterceptor.

      Comment


      • #4
        I think Spring's application context is what has me a bit confused. I was under the impression that in order to locate all the objects needed to get things working, I needed to configure and run in a Web environment. But of course, that isn't true and I think even the applicationContext.xml file does not need to be located in the WEB-INF directory.

        Let me take a closer look at the docs again.

        L

        Comment


        • #5
          You can have as many application context XML files as you like, named whatever you like, located wherever you like, and used within any client/server type you like. This includes standalone console application, Swing application, web servers, and application servers. Typically you'll put your services and persistence layer beans (along with their related transaction and security and possibly validation interceptors) in WEB-INF/applicationContext.xml. Then you'll put your web layer beans in xxxx-servlet.xml (assuming you're using Spring MVC).

          Comment

          Working...
          X