This week's book giveaway is in the Servlets forum.
We're giving away four copies of Murach's Java Servlets and JSP and have Joel Murach on-line!
See this thread for details.
The moose likes OO, Patterns, UML and Refactoring and the fly likes Model question Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Model question" Watch "Model question" New topic
Author

Model question

Norma Caballero
Greenhorn

Joined: Jan 30, 2004
Posts: 27
Hello,
I have a question regarding the model tier. I joined a development team to work on a migration from client/server to a web application. We are using Struts. and in the model tier, we use many classes, the approach we follow is to have one model class for each DB table. We have methods that populate the objects with the data from the DB. But for example, if we have a student table we create Student.java. And some cases we need to manage a collection of students, and we are instrcted to create a class named Students.java, which in its constructor retrieves all the values an populates a collection. How do you feel about this approach? Is this the right way to go? because sometimes I feel there are too many classes out there in our project.
Chris Mathews
Ranch Hand

Joined: Jul 18, 2001
Posts: 2712
We are using Struts. and in the model tier, we use many classes, the approach we follow is to have one model class for each DB table.
This is typical... though I prefer to model my domain objects after the abstractions that they represent which is not necessarily a one-to-one match with the database. In these cases, you end up with a mismatch between the object model and the relational model. Object-Relational Mapping (ORM) tools come in very handy here.
We have methods that populate the objects with the data from the DB.
It is also very typical to separate the persistence logic from the domain object itself, in fact it is considered a best practice.
And some cases we need to manage a collection of students, and we are instrcted to create a class named Students.java, which in its constructor retrieves all the values an populates a collection.
Not too thrilled about this part. I like to model my relationship in the domain objects. There a Teacher object might hold a Collection of references to Student objects. Again, a good ORM tool comes in very handy for handling these types of details. It is possible to handcode this... I just don't recommend it.

How do you feel about this approach? Is this the right way to go?
All in all, the approach that you described seems okay (with the exception of my couple gripes).
because sometimes I feel there are too many classes out there in our project.
Why do you feel this way? What would be your alternative? The point of OOP is to manage separation of concerns. This almost always results in a large number classes but is ultimately a much more maintainable solution.
BTW, this question is really more about design and less about Struts... therefore I am going to ask that this thread be moved to the OO forum for further discussion.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
As mentioned above, an object per table (or view) is common. It makes some object purists crazy. They believe you can build a meaningful object model, but on stateful servers this is extra difficult to justify. Still, some of the big names in the biz say weak models like this are core evils in too many systems.
On one project we battled hard and long with consultants who wanted the searchForThings method to return a collection of Things. This was way too expensive - building all those Thing objects, sending them across the wire from server to client, taking up client memory, etc. So we wound up returning a collection of ThingListItems. The search retrieves just a few key fields that we display to the user so they can pick one Thing to work on. Then we go back and get the whole Thing.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Stan James:
On one project we battled hard and long with consultants who wanted the searchForThings method to return a collection of Things. This was way too expensive - building all those Thing objects, sending them across the wire from server to client, taking up client memory, etc. So we wound up returning a collection of ThingListItems. The search retrieves just a few key fields that we display to the user so they can pick one Thing to work on. Then we go back and get the whole Thing.

Ah, but you could have done that in a more transparent way, for example returning LazyLoadThingProxies from the search which at first only know their key fields and load the other data when they need it.
On the other hand, for simple data-presentation applications, that could be overkill, too...


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Chris Mathews
Ranch Hand

Joined: Jul 18, 2001
Posts: 2712
Originally posted by Ilja Preuss:
Ah, but you could have done that in a more transparent way, for example returning LazyLoadThingProxies from the search which at first only know their key fields and load the other data when they need it.

Personally, I always avoid sending LazyLoadThingProxies across the wire to a Remote client. The thought that a list of size N could potentially invoke N additional remote calls scares me... and I hardly ever worry about performance up front. In this situation I would much rather the client explicitly state which full object(s) it needs to load and do it all in a single call.
Norma Caballero
Greenhorn

Joined: Jan 30, 2004
Posts: 27

because sometimes I feel there are too many classes out there in our project.
Why do you feel this way? What would be your alternative?

Particullarly by the situation I described above that a model class encapsulates a database table and a collection of those objects is encapsulated in another class.
I don't know another way to solve it, this is the first time I've been using struts, though this has nothing to with using or not using struts, in my previous projects we used Javabeans to represent the model. And we used a business layer and DAO.
In this project we have the model classes and that's it, they are the ones executing the queries and business logic. Wouldn't it be better to apply an integration tier pattern such as DAO, to interact with the database?
Chris Mathews
Ranch Hand

Joined: Jul 18, 2001
Posts: 2712
Originally posted by Norma Caballero:
In this project we have the model classes and that's it, they are the ones executing the queries and business logic. Wouldn't it be better to apply an integration tier pattern such as DAO, to interact with the database?

Sorry, I got the impression from your initial post that the persistance logic was separated from the Domain Model, not contained within it. I wouldn't recommend this design... I like to see the Domain Model decoupled from the persistance logic. It makes working and adapting to change with each much easier.
Norma Caballero
Greenhorn

Joined: Jan 30, 2004
Posts: 27
Hello, I am sorry I didn't specified that or made clear that in my first post. Thanks for your answers.
So, applying an Integration tier would be a good option?
Chris Mathews
Ranch Hand

Joined: Jul 18, 2001
Posts: 2712
Originally posted by Norma Caballero:
Hello, I am sorry I didn't specified that or made clear that in my first post. Thanks for your answers.
So, applying an Integration tier would be a good option?

I personally don't really like the term "Integration Tier" but yeah I think it is a good idea.
Norma Caballero
Greenhorn

Joined: Jan 30, 2004
Posts: 27
Thanks a lot!!!

What term would you use?
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: Model question
 
Similar Threads
Views maps to business entities, good choice?
How to prevent deadlocks in Swing?
How to map these tables to classes?
GUIContoller
Class Diagram