Objects by Design Forums Here you can view your subscribed threads, work with private messages and edit your profile and preferences Registration is free! Calendar Find other members Frequently Asked Questions Search Home  
Objects by Design Forums : Powered by vBulletin version 2.3.5 Objects by Design Forums > Main Forums > Object-Oriented Design and Patterns > EJB non-OO / Anemic Domain Model
  Last Thread   Next Thread
Thread Post New Thread    Post A Reply
Junior Member

Registered: Jan 2005
Posts: 1

EJB non-OO / Anemic Domain Model


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. Maybe someone else has got this right, or at least a happy medium.

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,

Report this post to a moderator | IP: Logged

Old Post 01-16-2005 04:42 AM
objman is offline Click Here to See the Profile for objman Click here to Send objman a Private Message Find more posts by objman Add objman to your buddy list Edit/Delete Message Reply w/Quote
All times are GMT. The time now is 04:27 AM. Post New Thread    Post A Reply
  Last Thread   Next Thread
Show Printable Version | Email this Page | Subscribe to this Thread

Forum Jump:
Rate This Thread:

Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is OFF
vB code is ON
Smilies are ON
[IMG] code is OFF

< Contact Us - Objects by Design >

Powered by: vBulletin Version 2.3.5
Copyright ©2000 - 2018, Jelsoft Enterprises Limited.
Copyright 1999-2005, Objects by Design, Inc.