• Post Reply Bookmark Topic Watch Topic
  • New Topic

JSF / EJB architecture

 
Luke Murphy
Ranch Hand
Posts: 300
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In an EJB 3.0 architecture using JSF and backing beans as the front end, do you like your backing beans talking directly to your injected EJBs or do you prefer a bit of indirection - something like the business delegate pattern?

I can see advantages to business delegate if you are using EJB 2.1, but I think the business delegate is overkill in an EJB 3.0 architecture.

What do you think?
 
Marco Ehrentreich
best scout
Bartender
Posts: 1294
IntelliJ IDE Java Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Luke,

from my personal experiences and latest reading on JEE I'd say it would definitely be overkill. With JEE and more modern technologies and frameworks some of the well known enterprise patterns and concepts known from EJB 2.x applications seem to vanish or become useless indirections which are no longer reasonable or useful. Most notably cumbersome layers of indirection don't make sense with JEE as long as there are no good reasons to have them.

Marco
 
Tim Holloway
Bartender
Posts: 18415
58
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One thing that we pretty well agreed on back last Spring was that it's a very bad idea to attempt to use EJBs or similar ORM objects directly as backing beans, and if you want to know exactly why, I invite you to search this forum and read all the sordid details.

However, I usually don't just cobble up a backing bean and have it go tossing around object model elements either. Most complex ORM systems have certain interrelationships that need to be maintained. For example, an invoice typically has a header, line items, and often refers to other things like client, ship/bill address objects, and so forth. So I interject a business layer.

Sometimes I interject 2 business layers, in fact. The calculation stuff I normally try and handle at the next layer down from the backing bean. The second "business layer" is my Data Services layer. Because I prefer not to keep my ORM objects attached any longer than necessary, this is the layer that works as database transactions.

I've been waffling about adding yet one more layer - a traditional DAO - underneath the Data Services layer. On the one hand, I would prefer to keep the class count low, but on the other hand, sometimes it's convenient to have the actual data access done separately from the integrated transaction. If I have to, I'd rather have tons of little simple classes than a few big gnarly ones.
 
Marco Ehrentreich
best scout
Bartender
Posts: 1294
IntelliJ IDE Java Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What's your opinion on this article about DDD with JEE? I must admit that I don't have much experience with this design idea from big real world applications but it sounds interesting to me. Using an extended persistence context and exposing mapped domain objects directly to the view layer seems to avoid a lot of problems. Of course it's obvious that this is no silver bullet which works for every scenario but I'd love to hear some opinions on this. Any experiences?

Marco
 
Tim Holloway
Bartender
Posts: 18415
58
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have been doing "DDD" for some time now, although not in the way that the author of that article describes.

I have 2 complaints about what he's doing:

1. JPA has perfectly good OO and inheritance mechanisms these days. So the whole section that natters on about needing "instanceof" and procedural tests is moot. I recently did in fact alter a project to use a common base class that mapped to 2 (amost) identical tables, and while there are some "gotchas", overall, it makes life a lot simpler.

2. I don't think it's strictly true, thanks to item #1, above, but it looked uncomfortably like there's business logic inside his domain objects. Whether persistent or not, the more I work with complex data aggregates, the more I prefer to use a Visitor-like approach to them, rather than placing logic within the model objects themselves.

One very good reason for not getting clever with your domain objects is that they are frequently automatically generated by a database reverse-engineering tool, UML designer, or other external source. Which will promptly nuke any added logic, as I can ruefully say. I realized to my horror not long ago that I'd done some projects that wouldn't have been hit that way if I'd just had the wit to use JSF converters instead of doing the format conversions inside the domain objects.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!