Win a copy of Think Java: How to Think Like a Computer Scientist this week in the Java in General forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Model question

 
Norma Caballero
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 2712
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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...
 
Chris Mathews
Ranch Hand
Posts: 2712
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Posts: 2712
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 2712
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks a lot!!!

What term would you use?
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic