where to turn next? need help with model layer talking to the database

[Rick Reumann]

Hi,
I can almost guarantee there a lot of people in the same boat I am in so hopefully this post isn't too off topic, since I'm not so sure it's j2ee per se.
I'm looking where to turn next for 'next step' resources. I don't think I'm probably the only one sort of stuck in the situation I am in. The situation is I want to make sure that I'm designing my web applications in a proper J2EE compliant design fashion, but not using EJBs and probably a lot of the other components that are involved with J2EE (maybe then I'm not asking about J2EE . I know there is a lot more to do with J2EE than EJBs, but I'm finding the literature out there very overwhelming in a technical sense. I'm not a complete newbie, I've been coding with JSP for about 3 years now, currently using Struts for my front end and controller architecture and did finally get that Sun programmer's test out of the way. I think I have a pretty good grasp of separating out the presentation from the business logic with MVC, but where I'm finding the most difficulty is trying to determine the best way to architect my business layer and how it should talk to the database through JDBC. As I look for resources into these issues the biggest problem I'm running into is finding concrete examples of the design patterns. Sure there is the pet store app but that's way overkill for the simple stuff I want to accomplish. Then on the other side most of the JSP books seem to barely touch on how your servlets should talk to a business layer and then from there access the database. I hear so much about using DAOs, but then when I try to search on finding out how these are coded I never can find concrete examples of how these are implemented, or if there are concrete examples they seem to deal solely with EJBs.
Sorry for this long post, but I'm getting a bit frustrated as to where to turn next. I know I need to read up on design patterns. I haven't read Gang Of Four yet, so I know I need to hit that up plus learn as much as I can about other patterns (So any books with concrete examples anyone can recommend, I'll check them out.). Simon, I saw what you mentioned in this post https://coderanch.com/t/309554/EJB-JEE/java/Design-Pettern and I've looked over the Sun J2EE link you provided on that post, but I was looking for some more depth of the patterns that have some concrete examples (Maybe I'm just stupid but I'll be honest I have a tough time following what they are talking about there without seeing some actual code). While I start reading some good material that hopefully others will recommend (that aren't too EJB heavy), maybe someone can give me some concrete feedback on how to best have my servlets talk to some business layer which in turn talks to the database.
Let me first explain how I currently have my JSP architecture set up, which I know probably isn't the best. Let's take a watered down example of doing an Update Employee application..
1) front end JSP form (using Struts all the fields are also tied to an underlying EmployeeForm bean.
2) JSP submits to a custom EmployeeUpdateAction class
3) In the EmployeeUpdateAction I might have a method ..
EmployeeBusinessObject.updateEmployee( EmployeeForm f )
4) the updateEmployee( EmployeeForm f ) in EmployeeBusinessObject doesn't do a lot in this case but get the appropriate String parameters from the EmployeeForm bean and create an EmployeeBean out of the form, then it would call a method like
EmployeeRepository.updateEmployeeRecord( EmployeeBean e )
(Other stuff might potentially be called in this business layer besides just the above updateEmployeeRecord, but in this example it doesn't do much.)
5) EmployeeRepository I guess is sort of like a wimpy DAO. It has all the SQL and jdbc calls to do the updates, inserts, gets etc. In this example it has updateEmployeeRecord( EmployeeBean e ) but it would also have methods like Collection getEmployeeRecords() which would return a collection of EmployeeBeans. I'm guessing this level of abstraction here isn't good enough. I see some examples where they are returning cached Row sets and all kinds of other things so I'm guessing what I am doing is too simple and not OO enough, so I'd really like some pointers in this regard.
Any advice on what I should start reading to make sure I'm doing things the right way would be much appreciated. Sorry if this post was OT for this forum. Feel free to move it or repost it to a more appropriate one if need be.
Thanks so much,
confused where to go next,
Rick

[pjoisha]

I think you're moving along on the right track. I would just add a Stateless Session as a front-end to your DAO. We have taken this approach for one of our read-only type of applications ie Servlet->SLSB->DAO->DB. However, for read/write type of application the J2EE patterns recommend taking Servlet->SLSB->Entity Bean->DAO->DB. It could be stateless or stateful bean depending on ur requirments. The data passed back and forth between Servlet and SLSB could in the form of Value Objects.
As far as examples goes I don't recall seeing any simplistic examples but I know that OReilly is coming out with a Struts books in which I know, from TheServerSide.com, that one of the chapters talks about tieing a Struts tier to EJB tier.
PJ
[ May 07, 2002: Message edited by: Prashanth Joisha ]

[Rick Salsa]

Hi Rick,
I know how you feel, for I was there a while ago myself. First off, I'd recommend taking a look at EJB Design Patterns by Floyd Marinescu, who works for the Middleware Company, the premiere training firm for J2EE.
The book describes the best Design Patterns for the J2EE enviroment. The GOF patterns I find, don't really apply well with J2EE. They need some modification, and the patterns in this book do just that.
Also, the book has a chapter on describing how to design the different layers in your J2EE app. An excellent chapter, as it covers everything from the web tier to your data stores.
After reading this book, it all made sense. I had an idea of what to do, but couldn't apply it.
You seem to have a good idea of how things are suppose to work.
For your app, you'd probably make a helper class that your Struts action form would call. This helper class, will call on your J2EE container using RMI (assuming your jsp/servlet and app server are on different machines). This helper class would talk to you J2EE app server using RMI.
Now for EJB's, DAOs are commonly used with BMP (Bean Managed Persistance). This is where you are writing all of your JDBC code. The class that you've made it the same thing you'd do in a BMP Entity bean. A DAO is another layer of abstraction. The idea is that your application code should not know that its talking to an oracle database. It should just know that the class its talking to will give it the imformation it needs. A DAO is usually an interface that concreate classes inherit from. These concrete classes will know how to specifically talk to a certain db. One db and that's it. It would allow us to quickly change from an SQL Server database to and Oracle database, depending on how we instantiate the DAO object.
With that advent of CMP (Container Managed Persistance), your J2EE container talks care of all the persistance for you. You just tell it in a deployment descriptor, what database you want to use.
Phew... That was a mouth full. I hope I answered what you wanted to know. If not, let me know what I can clarify or talk about it I missed it our wasn't clear.
HTH,
/rick

[Rick Reumann]

Is it ok then, for lack of a better word, my DAO, to return actual objects such as a collection of Employee beans? Or is it better for the DAO to return some kind of result set off to a business oject?

[pjoisha]

I would prefer to have my DAO objects return the EmployeeBeans (which I consider are Value Objects or Data Transfer Objects ..as the EJB Design Patterns book calls it). This way the DAO can be used across applications. I would only stick the workflow logic in the Stateless Bean, meaning if I had to generate, for example, a EmployeeDeptBean I would make my SLSB go after 2 DAO (one for Employee and the other for Dept with each of them returning the EmployeeBean and DeptBean respectively) and then collapse them together for EmployeeDeptBean in the SLSB.
PJ

[Rick Reumann]

Thanks for the feedback Rick...

<snip>..
First off, I'd recommend taking a look at EJB Design Patterns by Floyd Marinescu, who works for the Middleware Company, the premiere training firm for J2EE.

Just looking at the description of the book on the site above, it looks like this book might be too advanced for me. You don't think it will?

<snip>.. For your app, you'd probably make a helper class that your Struts action form would call. This helper class, will call on your J2EE container using RMI (assuming your jsp/servlet and app server are on different machines). This helper class would talk to you J2EE app server using RMI.

Haven't done anything with RMI. Everything except the database is on the one server though.

Now for EJB's, DAOs are commonly used with BMP (Bean Managed Persistance). This is where you are writing all of your JDBC code. The class that you've made it the same thing you'd do in a BMP Entity bean. A DAO is another layer of abstraction. The idea is that your application code should not know that its talking to an oracle database. It should just know that the class its talking to will give it the imformation it needs. A DAO is usually an interface that concreate classes inherit from. These concrete classes will know how to specifically talk to a certain db. One db and that's it. It would allow us to quickly change from an SQL Server database to and Oracle database, depending on how we instantiate the DAO object.

This above is exactly what I want to see some concrete examples of. Does the book you mentioned go into some concrete examples of this.
If you have any more comments feel free to e-mail off list as I'm sure many of my questions are way too basic Thanks again.
[email protected]

[Rick Salsa]

Hi,

Just looking at the description of the book on the site above, it looks like this book might be too advanced for me. You don't think it will?

I hadn't read the GOF book when I looked at this title. I didn't find it to difficult to follow. Its written in an excellent manner that makes it easy to understand and follow. Some patterns you might have to go over more than once. There is a book review of it in the book review section here. Also, amazon has good reviews of it.

Haven't done anything with RMI. Everything except the database is on the one server though.

Are you using J2EE (Entity beans, etc..)? If you are, and everything is in the same app server, then you don't need to worry about RMI. You can use local interfaces and not have to worry about that.

This above is exactly what I want to see some concrete examples of. Does the book you mentioned go into some concrete examples of this.

I can't remember off the top of my head. I'll take a look when I get home and let you know.
One other thing, that I forgot to mention in my other post. I wouldn't be worried about returning a Collection. In J2EE applications, when you're returning more than one object, it must be in a collection. In the applications that I have made, I've never returned anything in CachedRowSet, etc. I don't believe in having a lot of code in my jsp pages. I used a framework called WebWork that has a tag that will iterate over a collection and display the values.
I'll drop you a quick email so you can email with any other questions, or maybe post here if you like.
/rick