Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

This one has haunted me for so long. When doing MVC programming what do you think is the better programming practice? Should one use fully populated models or the partially filled ones, especially when I know that for this particular task I am going to need only 2 fields from the model object which has 5 others?

Sometimes it just seems criminal to fill a list of 20 model objects with all values from database when you know that you are going to need only a few of them.

Of course partial model means that you will have to write one more method in your DAO apart from the one which fetches everything. Which mean more code to maintain?

On the other hand pulling everything from DB with fully populated models means one method serves all but this is obviously going to give you some performance overhead.

I can see ORM (such as Hibernate or ActiveRecord of Rails) favoring trends in MVC programming and databases like Google’s BigTable full models is accepted trend. But what if you are still using good old JDBC?

Hardware is cheap, development is costly. Is that really true even when the app needs to scale to few hundred thousand requests per hour?

share|improve this question
1  
"On the other hand pulling everything from DB with fully populated models means one method serves all but this is obviously going to give you some performance overhead. " Really? Have you measured any performance overhead from this practice? –  S.Lott Apr 26 '11 at 18:57
    
>>Really? Have you measured any performance overhead from this practice?<< - I had expected this one. No I haven't. But it would be interesting to measure and to be proved wrong otherwise. –  Pritam Barhate Apr 26 '11 at 19:48
    
It's hard to prove overheads don't exist. You can easily quibble over lots of details claiming the measurements aren't valid for some situation. It's much nicer if you use your "typical" setup of database, application language, etc., and profile your preferred configuration to show what the actual overheads are so we don't have to quibble over the various factors we left out of our measurements. –  S.Lott Apr 26 '11 at 19:59
1  
I found an excellent article that covers the question of exposing your domain model vs. sending a DTO at msdn.microsoft.com/en-us/magazine/ee236638.aspx. –  Mayo Apr 26 '11 at 21:44
add comment

3 Answers

You have two options:

1) Leave some fields in the model unfilled

2) Create an extra "lite" model for your specific situation

Which one to choose depends on the two things again:

a) How many fields of the "full" model are going to be ignored

b) How often this "lite" model will be instantiated

If there are just a couple or more fields that can be unfilled, it is okay to go with 1).

If b) is just an exceptional individual situation, there is perhaps no point in creating an extra model just for one usage case.

Another approach is to define a "lite" model and inherit the "full" model from it.

share|improve this answer
    
Thanks for the answer. It makes sense to make a lite model depending upon the need. But sometimes I wonder won't such a strategy will create too many model classes? Especially if I am making models specific to views rather than models specific to business logic. –  Pritam Barhate Apr 26 '11 at 18:55
add comment

If your view only needs 2 properties from the model then you (probably) have the wrong model for that use case! I would look to create a model to suit the view, save the extra DB lookups and only populate the data you need. If a subsequent view needs more detail then you have to ask, do I get the extra data later or should I get it all up front...

As an alternative you could look at some sort of lazy evaluation, so values are populated when you need them. This can work well but is obviously more work and may end up causing multiple round trips to the DB which is not great if you end up doing it a lot.

That said, if you are basically selecting a few extra fields from a table or view then the cost of getting that extra data is, to all intents and purposes zero (OK, there are more bytes on the wire, but the biggest costs are likely to be in the creating and tearing down of a connection), so if there is a chance you will need some extra data I would probably populate the model fully once you are happy you have the right model.

Hardware is cheap, but no amount of hardware can make a bad design perform well.

share|improve this answer
2  
>> If your view only needs 2 properties from the model then you have the wrong model! << - Need not be worng always. Typical Case is showing list of search results in business applications. For example in a CRM - customer - mostly one will show only name and one or 2 important fields in a search listing. But the CRM will have quite a few other fields associated with that customer. –  Pritam Barhate Apr 26 '11 at 18:50
1  
Question says that in this case only 2 properties are needed. –  Steve Haigh Apr 26 '11 at 19:26
add comment

The model is not a DAO.

And another thing : if you say that you have 20 models (customers, from your example), then that is no an MVC model. The domain model does not map directly to a single table row. Instead it should be responsible for all the operations done with your "customers".

In your example, "Customer" is not a domain model, but just an object inside the the model.

As for interaction with database , that responsibility should be delegated to a data mapper object, which should know how to store and fetch your instances of Customer class.

share|improve this answer
    
P.S. if you have database logic inside the model, then it will push the domain business logic into the controller. –  mefisto Apr 26 '11 at 20:29
    
One class that does everything operation for customers is a bad idea as it will be difficult to maintain. –  Andy Apr 7 at 0:11
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.