Should model objects be flexible

Question

Hello,

[Sorry but work is proprietary so I cannot give details of objects]

I am working on a Java application with a colleague. I am doing the client side and he is writing the server code.

The application displays a table of X objects. The columns of the table show some of X's attributes. In addition we have a column that shows a count of Y for each X. (Association is many-to-one Y to X and one way, Y has a reference to its parent X).

The count of Y is not an attribute of X but is obtained via a query on the DB.

I am using a TableModel so it would obviously be easier to use X objects as the model for the table. But since the Y count is not an attribute of X I will need to create a container object to hold an X plus a count. This is rather annoying as it adds a class that seems unnecessary.

I suggested to my colleague that he add an extra field to X plus a getter:

private void Map info = new HashMap();

This would make the model objects X more flexible. I can store any state I need at any time in the client without affecting the main attributes of the model which are specific to the nature of X. The keys would only be defined in the client so the model would not be polluted.

He has refused because he feels that the model objects should only model the domain and the extra field is not related to the domain objects and so should not be added. He thinks that the client should handle this.

Both viewpoints seem to have merit so I would be interested in what other readers think/feel about this.

Thanks,

Tim

Answer 1

I think you are confusing the database model with the Model in MVC. Keep in mind that the MVC pattern is a design pattern for presentation layer. The Model i.e., in MVC can be the database model (entities in database) in a simplistic application but that is not necessary.

I my opinion you should have a separate class (Table Model) as you said which should contain the fields that you are displaying in the Table. This model will get populated from you Business Logic Layer i.e., should be the output of your BLL. You can also term this as a DTO (Data Transfer Object). The idea is to have only the data that you need. If you need the count then only have the count in the DTO instead of all of the Y. This will not only make your application manageable but also reduce the data transfer than goes on between the layers hence reducing the memory footprint of your application and increasing the performance as well.

Answer 2

I'm in exactly the same position (I'm mostly the server side guy) and I see it like your colleague.

In our case the server side is a web service. You never know who will be calling the service in the future so I want to keep it as general as possible. Whenever we need special data in the model we extend the appropriate classes and add them this way. Often this is a no brainer since we need to subclass anyway (e.g. we need PropertyChangeSupport in a lot of the classes for MVC).

However I don't know if this solves your 'count' example. We also encountered a similar situation and I just created a special DTO as user446612 suggests that holds the data.

Answer 3

Thank you for the responses guys.

Tingu said:

I think you are confusing the database model with the Model in MVC

Okay yes. So you are saying that there are effectively two different model objects, one for the database and one for the M in MVC in the client application, and that the client side model is populated by the BLL from the retrieved database model objects?

musiKk is saying the same thing by my reading.

We are using the server side model as the data model (MVC M) in the client and the objects are simple.

musiKk gave the following reason:

You never know who will be calling the service in the future so I want to keep it as general as possible.

This is exactly argument put forward by my colleague. I completely agree that this is essential. However my thought here was that adding a map of object to the model in no way makes the model less general. It is provided as a convenience to the client and is an empty map.

The advantages are:

(1) saves the client having to create subclasses or create new objects for a simple case like this with a single extra field

(2) very flexible as transient state can be encapsulated with the object as it is used in the client

The disadvantages are:

(1) objects are bigger which makes it larger when moving across the network

(2) if you subclass you have the extra field even if you don't use it