Announcement Announcement Module
No announcement yet.
Repositories and Models (beans) Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Repositories and Models (beans)

    We've been using the general repository pattern in our webapp for a while.

    I'm trying to sort through one of the possible ways to design this. After working if a few different ways I'd like to know how people generally design their architecture in terms of repositories and beans.

    When creating a bean do you add a reference to the repository that build it?
    Some of our systems do do this (not all).

    This would mean that to save the bean you would be able to call

    Without having to load an appropriate repository because the bean would know which one it came from and be able to manage itself (part of the concept of OOP).

    Alternatively is not given the bean any reference to the repository that made it and leaving it up to the developer to load the repository and then save the bean back using a repository method such as:

    This would exist anyway as it's a part of the purpose of the repository.

    The question then is: Which pattern do you use? and; What do you think the benefits/pitfalls of each are?


  • #2
    Well basically you describe the 2 camps here. I'm with the second one though .

    I put business logic inside my domain model and leave as much of the infrastructure out of it. That kind of stuff I put inside a service layer which delegates it to repositories. We even sometimes have multiple ways of storing an object, that is quite easy done in a service. Next to that I don't really like the fact that a bean knows where it comes from/needs to be stored.

    But there is no real silver bullet here, nothing solves everything. I would at least make it consistent through out your whole code base so that people know what to use.


    • #3
      If you're using JPA, the EntityManager provides a generic (ie entity non-specific) interface for persistence operations. Coupled with transparent persistence (ie if you can reach an object and modify the object's state within a logical unit of work it will automatically flush those changes through to the database) I see diminishing value of maintaining a dedicated repository layer. Specifically, what changes between one repository and another? About the only thing that differs are finder methods, and occasionally you have different backends for different entities. Another benefit of repositories is they can be stubbed for unit tests, although in my experience those projects that do automated testing tend to perform integration testing anyway and as such don't stub their repositories at all.

      For the above reasons (and several others) we elected in Spring Roo to introduce persistence operations directly into the entities, although Roo is far from unusual in this regard. Both Rails and Grails do it, and so do other frameworks like Django. I believe the world is moving in this direction. With Roo your persistence methods are not only automatically provided, but they're also nicely type safe, debuggable and code completion-aware. So you can invoke Person.findAllPersons() and you'll get back a List<Person>. You also get free integration testing of the methods.

      I'd be cautious about writing DAO/Repository layers in 2009 unless you have a lot of solid engineering arguments to support it, as they take time to write and will need to be maintained for years into the future. There certainly remain valid scenarios in which they are entirely appropriate, but those scenarios are not highly commonplace in my experience (assuming you're building a typical JPA-based app like most Spring users do).


      • #4

        To be honest I think we have two issues neither one necessarily a real engineering issue.

        A. I first introduced Spring to our developers in the middle of last year. Partly as I needed a way to introduce unit testing and everything was being written (business logic included) in the JSP layer, and causing havoc as a result. Most of the developers I had at theat point were more familiar with PHP and none really that familiar with anything on the enterprise scale. So introducing an ORM etc was something I shied away from. I wanted Spring then Unit testing.

        B. The 'systems' at the organisation I'm with are at best hap-hazard. We have some vendor systems we have a mixture of home grown scripts etc. Until last year some systems were getting data purely from database tables dumped to files and read via perl scripts into a local db. Engineering in effect is unpredictable.

        Basically writing repositories was a small step from what was being done already and easy to get the developers to understand. We are now working on introducing this to the other java development team. I think the general maturity in the organisation for this kind of developmant is a long way behind.

        At this stage I'm working out what would be a good way design the code so that the progression into a more mature solution can actually take place.

        Part of the original question has come up for me because of an article I was reading on Mocks and Stubs and it occured to me we were using a pattern that wasn't very OOP oriented (not saying it doesn't work though).

        It occurs to me that the way we are using our beans at the moment is nothing more than glorified data structures. What I'm looking at is how much of the intelligence could be shifted to the bean.

        Thanks for the feedback from both you and Marten. I think I'll take a look at OpenJPA and Hibernate as a next step. I'll keep an eye on Roo too.



        • #5
          I prefer a service layer. Often a bean needs to be saved to multiple locations etc. It also seems cleaner that the bean doesn't know where it is going to be saved to, it is basically just a data structure definition.