EJB3's impact on design patterns
Well, I'm just starting to get into EJB3, and enjoying what I work with so far. I'm curious how EJB3 may impact my own use of certain design patterns, and I'm looking for input. It's a trade off between faster development, and "better design".
I work on a moderately sized J2EE application, that runs entirely within the local JVM. There are two established patterns that I want people's input on when utilized in conjunction with EJB3. I'm questioning their value at this point (I used them with the previous EJB standard 2.1).
1. Transfer Objects
Since [a] I'm working within the same JVM, and thus using local interfaces only, and entity beans are now basically annotated transfer objects, what's the point? Can't I just pass the actual entity objects to the display layer (JSP)? I understand that this is probably forwned upon, but why is my real question. Maybe it's just extra work for nothing to create the transfer objects for new EJB3 projects.
2. DAO Objects
The major purpose of DAO objects was to insolate the application business logic from the data access specifics. Since EJB3 provides database independence (almost for real this time :-) what's the point?
Of course it provides a cleaner interface for business logic, but personally, I find that I end up with 32 super-specific methods on my DAOs, that can only be used by a single application/location, that I may as well have had the 'SQL' (now EJBQL) in the business tier to begin with.
I mean if we consider that EJBQL provides DB independence, what's the difference between having some EJBQL query in the business logic, versus having a function like "getAllCustomersWithGreenShirtsAndYellowTies" in the DAO?
Thanks,
Mal.
[1778 byte] By [
gregrwadea] at [2007-10-2 18:32:46]
Sorry about the bold. I have no idea what happened there, but I think it's due to some cut-and-pasting for spell check :-)
what are ejbs buying you here? that's what i'd like to know.%
> Well, I'm just starting to get into EJB3, and
> enjoying what I work with so far. I'm curious how
> EJB3 may impact my own use of certain design
> patterns, and I'm looking for input. It's a trade off
> between faster development, and "better design".
Learn Spring and get rid of those EJBs:
http://www.springframework.org
>
> I work on a moderately sized J2EE application, that
> runs entirely within the local JVM. There are two
> established patterns that I want people's input on
> when utilized in conjunction with EJB3. I'm
> questioning their value at this point (I used them
> with the previous EJB standard 2.1).
>
> 1. Transfer Objects
>
> Since [a] I'm working within the same JVM, and thus
> using local interfaces only, and entity beans are
> now basically annotated transfer objects, what's the
> point? Can't I just pass the actual entity objects to
> the display layer (JSP)? I understand that this is
> probably forwned upon, but why is my real question.
> Maybe it's just extra work for nothing to create the
> transfer objects for new EJB3 projects.
I would ditch the DTOs. Parallel hierarchies like this are a bad smell. Twice the work to maintain, unless you generate them automatically.
> 2. DAO Objects
>
> The major purpose of DAO objects was to insolate the
> application business logic from the data access
> specifics. Since EJB3 provides database independence
> (almost for real this time :-) what's the point?
EJB3 isn't about database independence, AFAIK.
DAOs aren't about database independence, they're more about layering your application properly, IMO. Whether you choose to implement in terms of EJBs or Hibernate or something else is immaterial to clients.
> Of course it provides a cleaner interface for
> business logic, but personally, I find that I end up
DAOs are for layering persistence. The service interface is for layering business logic.
> with 32 super-specific methods on my DAOs, that can
30 finders? How big are these tables/objects? I'm assuming that you have delete and saveOrUpdate methods, with the rest as finders of one flavor or another.
Maybe DAOs aren't your problem. Perhaps your objects are too bloody big.
> only be used by a single application/location, that I
> may as well have had the 'SQL' (now EJBQL) in the
> business tier to begin with.
I wouldn't.
> I mean if we consider that EJBQL provides DB
> independence, what's the difference between having
> some EJBQL query in the business logic, versus having
> a function like
> "getAllCustomersWithGreenShirtsAndYellowTies" in the
> DAO?
It's my opinion that EJB3 is not about database independence, but I'll admit that I'm not a spec expert.
How are EJBs helping you with inheritance and polymorphism? Can you do polymorphic queries? Can you subclass an entity EJB?
Ask yourself: What are the EJBs buying you here that you can't get from a POJO? Would Spring and Hibernate do just as well, if not better?
%
Not sure I'd be totally dismissive of EJB 3.0 just yet Duffy. I have yet to read anything significant on Spring 2.0's integration with J2EE 5, but I did come across an interesting article on how to do so:
http://www.jroller.com/page/malbari?entry=javaee_5_spring_2_and
I would like to see if Spring 2.0 + EJB 3.0 is a winning combination. There's still a lot left in Spring, and Sun seems to have embraced IoC, at least partially. I guess only time will tell.
- Saish
Saisha at 2007-7-13 19:54:21 >
Good advice, Saish. You're ahead of me on EJB3. (Sounds like the OP is, too.)%
Not really, just curious how the two will play together. :^)
I'm still really unclear just how EJB 3.0 is working under the covers. Is it really full IoC like Spring? Or is it just using annotations to simplify EJB creation (e.g., it's Sun's version of doclets on steroids)? I'm a bit nervous because supposedly EJB 3.0 will still allow and support EJB 2.0 deployment descriptors. Either they did perform additional optimizations to EJB (such as auto-optimizing a remote call to a local one where appropriate) or they simply put lipstick on a pig. :^)
- Saish
Saisha at 2007-7-13 19:54:21 >
Pucker up, piggie. You look so fine! It's a nice image - thanks. 8)%
LOL. I heard that saying before (from Charlotte's Web?). What got me thinking was this one developer who said, "Hey, let's make executing stored procedures easier to execute." He assumed every database table had a uid sequence as its primary key (not correct in our system). He then proceeded to make overloaded methods that would return each primitive: executeStoredProcDouble(), executeStoredProcInt(), executeStoredProcString(), etc., each of which took an int as a parameter.
That was bad enough (the one I told him to re-write took an array of objects as parameters and returned an array of objects as OUT values). However, he had gone along and added some new XML configuration to store error results, added tons of documentation, created several helper classes simply to handle resource closure and finally created a series of custom appenders for Log4J.
That's when I got the idea of lipstick on a pig. Nice features. Crappy original concept. :^)
- Saish
Saisha at 2007-7-13 19:54:21 >
> LOL. I heard that saying before (from Charlotte's Web?).
Is that where it's from? I read that book to my daughters, but I don't remember that saying. Then again, I don't remember much at my age.
> What got me thinking was this one developer
> who said, "Hey, let's make executing stored
> procedures easier to execute." He assumed every
> database table had a uid sequence as its primary key
> (not correct in our system).
Oh, my. Not in many systems that I know of. But even if it were true, doesn't that seem too granular to you? Sounds chatty.
> He then proceeded to
> make overloaded methods that would return each
> primitive: executeStoredProcDouble(),
> executeStoredProcInt(), executeStoredProcString(),
> etc., each of which took an int as a parameter.
So querying for a row with 50 columns would mean 50 stored proc calls? Do I understand that right? Nice!
> That was bad enough (the one I told him to re-write
> took an array of objects as parameters and returned
> an array of objects as OUT values). However, he had
> gone along and added some new XML configuration to
> store error results, added tons of documentation,
> created several helper classes simply to handle
> resource closure and finally created a series of
> custom appenders for Log4J.
Beautiful!
> That's when I got the idea of lipstick on a pig.
> Nice features. Crappy original concept. :^)
LOL. Great story.
%
PS - How are you doing these days? Everything is well? You're ready for summer?
PS - How are you doing these days? Everything is well? You're ready for summer?
Summer is glorious! I've wanted a convertible all my life, and finally got on in February. It was eight long weeks until I could finally enjoy it. The spring going into summer (before it gets really hot) is my favorite time of year. The green on the leaves seems, well, greener, or more alive than later in the year.
So, life is good. How's by you?
- Saish
Saisha at 2007-7-13 19:54:21 >
BTW, off topic: check out www.digg.com. It's a tech site news where readers vote on the most interesting topics. I'm checking it nearly hourly now. :^)- Saish
Saisha at 2007-7-13 19:54:21 >
> BTW, off topic: check out www.digg.com. It's a tech
> site news where readers vote on the most interesting
> topics. I'm checking it nearly hourly now. :^)
Thanks for the tip. A co-worker turned me on to Digg a few months back. I've been holding out on you! It's the greatest. Some of the science articles are a bit suspect from time to time, but I love the concept.
%
> PS - How are you doing these days? Everything is
> well? You're ready for summer?
>
> Summer is glorious! I've wanted a convertible all my
> life, and finally got on in February. It was eight
> long weeks until I could finally enjoy it.
Sounds terrific. It's great to get your heart's desire, at least once.
> The
> spring going into summer (before it gets really hot)
> is my favorite time of year. The green on the leaves
> seems, well, greener, or more alive than later in the
> year.
Sure is nice here right now. The place that I work now is the nicest setting I've ever been in. It's right at the base of a mountain. Watching it bloom this spring has been great.
> So, life is good. How's by you?
Pretty darned good. I wish I were smarter and writing more code, but things are pretty good for me.
%
Sure is nice here right now. The place that I work now is the nicest setting I've ever been in. It's right at the base of a mountain. Watching it bloom this spring has been great.
I'm in Michigan. What's a mountain? :^)
You're living in CT, right? Are you near the Appalachians? The Green Mountains? Trying to remember which ones are out east. I lived in Denver and Vancouver. Waking up to amazing scenery just makes life that much easier to enjoy.
Pretty darned good. I wish I were smarter and writing more code, but things are pretty good for me.
Glad to hear things are going well. Tho if you were any smarter, I'm sure Gosling would be the poster here, writing about your latest enhancements to Java.
- Saish
Saisha at 2007-7-13 19:54:21 >
> Sure is nice here right now. The place that I work
> now is the nicest setting I've ever been in. It's
> right at the base of a mountain. Watching it bloom
> this spring has been great.
>
> I'm in Michigan. What's a mountain? :^)
True.Someone from CO would laugh at the hill I'm calling Avon Mountain.
> You're living in CT, right? Are you near the
> Appalachians? The Green Mountains? Trying to
> remember which ones are out east. I lived in Denver
> and Vancouver. Waking up to amazing scenery just
> makes life that much easier to enjoy.
Nah, south and east of Hartford.
I hear mountain country is spectacular, but I've yet to see it.
> Glad to hear things are going well. Tho if you were
> any smarter, I'm sure Gosling would be the poster
> here, writing about your latest enhancements to
> Java.
You flatter me. I have a very long way to go, that's for sure. Every day at work convinces me that it's true.
%
If you like to test your EJB3 application, you should try Ejb3Unit. The Ejb3Unit project automates Entity and Session bean testing outside the container for the EJB 3.0 specification.
Ejb3Unit is a JUnit extention and can execute automated standalone junit tests for all EJB 3.0 conform JEE projects. The out of container test approach leads to short build-test-cycles, because no container deployment is necessary anymore. EJb3Unit uses an internal in memory database by default. Alternatively a user defined database can be specified. An example configuration can be found at http://ejb3unit.sourceforge.net/.
> I work on a moderately sized J2EE application, that> runs entirely within the local JVM.Why are you using EJBs in the first place, then ? http://www.interface21.com/books/j2eewithoutEJB.html
