EJB non-OO / Anemic Domain Model - Please help!


EJB design: EJB non-OO / Anemic Domain Model - Please help!

  1. EJB non-OO / Anemic Domain Model - Please help! (2 messages)


    Apologies in advance for the long post but it may be of interest to some who like a "clean" design.

    I'm quite confused about Object Oriented Domain level design in an EJB context and where exactly to put Business Logic. I'd really love to hear some feedback as this problem really drives me crazy.

    In a nutshell we tend to do the following layering which I believe is relatively typical in EJB layering (although some may use different persistence frameworks etc):

    1/ Use cases are reflected in Component level SLSBs(Stateless Session Beans). Transaction attributes are set at this level.
    This is our service layer where Workflow type business logic occurs.
    2/ DAOs with Hibernate implementations. (We also have Entity Beans floating around but that's another story)
    3/ Bean classes/DTOs link 1 and 2 above together as well as being exposed over applicable Remote interfaces of SLSBs

    Basically, in our domain model we have DAOs and Bean/DTO classes, where the DAOs take DTOs/Beans as parameters and return values. Almost all business logic happens in the SLSBs service layer.

    I find the above approach really encourages poor procedural style programming.
    The problem is :
    Where do we put domain level business logic ? :
    - If we put it into the DAOs it means we are polluting our data access with persistence logic.
    - If we put it in the DTO/Bean classes this may not be good for Remote calls (or does this really matter, should we just pass domain classes over Remote interfaces ?, ie. How does domain business logic code affect serialization?)
    - We could introduce domain level POJO facades, it would seem that this would produce an explosion of classes. Eg. For a "Product" domain concept we might then have the following :
           - "Product" SLSB at the service layer (or some other facade with "Product" use cases.
           - "Product" POJO Facade with domain level business logic
           - "Product" Bean/DTO
           - "Product" DAO
           - Potentially "Product" hibernate Entity type bean classes.
    .....That's just too much to manage !!
    Now, I originally come from a C procedural programming background which was pseudo Object Oriented.What we used to do is have a module file with functions that operated on C data structs.
    - Then I did C++ for some years and we used to encapsulate business logic with member data in domain classes in a classical Object Oriented manner. DB code was not clearly seperated which obviously had its share of problems, but it seems more OO-like than what I do now with J2EE/EJB.
    - The Bean/DTO Classes in J2EE seem akin to what C Structs are, - not much better anyway.
    - SLSB methods are akin to the C functions which operated on the C structs.
    It seems to me like we have gone back in time.

    Can anybody shed some light on the above problem? I read M. Fowler's articles on Anemic Domain Classes but it seems to me that domain level business logic would pollute J2EE layering ?

    Thanks in advance,

    Threaded Messages (2)

  2. Youre requirements will define how many layers you implement in your system. I've seen systems with the following:

    Action Classes
    Facade SLSB/DTO
    Business Logic POJO
    stored procedures

    This is likely overkill for most, but there are advantages/disadvantages to having these layers. You need to decide if that advantage out-weighs the cost of implementing that layer of abstraction.

    It appears you are specifically asking about the Business Logic POJO/Facade SLSB layer. Should you combine or separate these. Pros of combining: less work. Pros of separating: better maintainability with changing requirements, flexibility to re-use your business logic outside of a J2EE container (POJO batch job?), maybe flexibility to move away from or change J2EE containers

    If these benifits are not a concern then combine them. IMO, the benifit of better maintainability with changing requirements is enough to in most cases separate these.

    Don't put them in DTO or DAO/Hibernate.
  3. Anemic Domain Model[ Go to top ]

    This is what Martin Fowler refer as Anemic Domain Modle (http://www.martinfowler.com/bliki/AnemicDomainModel.html)

    Read the book below for more details:

    In a nutshell, you should use the "Domain Model" and "Service Layer" pattern to design your application. Put "DTO" and "Remote Services" Layer on the top of the service layer if you need remote call

    hope this help