When using MVC, to what degree should a model be tailored to a view?

[Corey McGlone]

By first response to that question would be, "Not at all!" But, today, I came upon a case in which I was tailoring a model to make the View easier to write.

I was building a simple web application using Struts. Struts is essentially based on a MVC pattern which clearly delineates your model from your controllers and your views. The whole idea is that the model should be reusable from application to application and it should matter is the view is a JSP page or a Swing GUI. Now, let me explain the situation I ran into.

At my place of work, we are using J2EE 1.3 (a little old, but it's beyond me to change that). With that, we're using Servlet 2.3 and JSP 1.2 - that means we don't have a lot of the bells and whistles available to us that we'd have if we went to JSP 2.0 (particularly, EL).

Now, I've written JSP's before and I know that it's a good idea to keep Java code out of the JSP's. It helps make your JSP files more readable, more maintainable, and it makes the transition to JSP 2.0 easier. Given that, and the fact that the tools I have available to me are somewhat rudimentary (compared to 2.0, that is), I need to make sure that the data available to my JSPs is easily displayed by my JSP.

Well, one of the easiet ways to display something in a JSP is to use a Java Bean. You can use simple tags to do something like this:

<jsp:useBean id="someAttribute" class="foo.bar.MyJavaBean" scope="request />
 
...
 
<jsp:getParameter name="someAttribute" parameter="myValue" />

(Forgive me if the syntax is a little off, I'm trying to write those tags from memory.)

Well that works great! I can get the information I need from the request and print it without using a single line of Java code in my JSP file. So what's the downside? Well, the object I'm pulling from the request needs to be a Java Bean.

So, here was my solution. I turned the model object that I was dealing with (where my business logic is) into a Java Bean. It really didn't hurt anything, but it was something that I did explicitly to make the view easier to deal with.

Was that the wrong thing to do? Was it the right thing to do? It didn't harm the functionality of the model at all, but I did explicitly modify the model to match the requirements of my view. What does everyone else think?

I kinda thought this was a general MVC question (with a specific Struts example), but if someone feels that this belongs in a different forum, feel free to move it.

Thanks,
Corey

Edited by Corey McGlone: I didn't realize HTML was enabled in this forum so my JSP tags weren't appearing properly. Should be fixed now.
[ October 27, 2004: Message edited by: Corey McGlone ]

[Jeanne Boyarsky]

Corey,
I'm also using J2EE 1.3 with Struts, but I wouldn't tailor the model to the view. What I do is create separate view classes based on the model.

For example, I'll have a constructor that takes the model.

public View(Model model) {
  // store relevant data in view
}

The reason I do this is so that my view getters can do formatting. That way I keep the code out of my JSP and all the formatting stuff is centralized in the view classes.

This strategy also allows me to store less in the request/session because I am only storing the needed fields. (Granted this doesn't matter for the request, but I want to be consistent.)

[Corey McGlone]

So you're creating an additional class, which is a Java Bean that contains all of the data fields you acquired from the Model? Does that sound right?

I had considered having the Action class create a special bean, but I guess I just hadn't taken it that one step further. That seems to be a nice idea and not too sloppy. I was afraid I was going to end up with gobs and gobs of objects that way (one for every class in my model) but this would really result in one bean for every view.

[Ilja Preuss]

Yes, that's what I'd do, too: Have an object in your view layer which adapts your model to the needs of the JSPs.

That might increase the number of classes, but as long as that makes it more obvious which code is responsible for business logic, and which for presentation logic, that's quite worth it, in my opinion.

[Corey McGlone]

Thanks, Ilja and Jeanne.

I was almost to this solution, but I was just one step away. This solution is much better. Thanks so much.

[Stan James]

FWIW: I'm using a vendor framework - not Struts but pretty similar - where a front controller servlet calls a POJO "work class" and then forwards to a JSP. The work class calls into the model and builds an XML document to pass to the JSP. The vendor's custom tag library reads the XML document. The XML stuff is extra overhead, but lets the work class build a DOM that exactly matches the needs of the JSP, completely independent of the model, without another layer of classes.

Previously I worked on a framework that two guys in the company built that was all XML in and out. There was something that looked a lot like XSL but was actually interpreted by the framework and included the ability to call out to one or more beans. That was slick because we could define a new custom tailored request-reply pair of XML messages against existing beans with a new XSL-like definition but without touching a line of Java.

[Sathya Srinivasan]

If you consider model object as an 'entity' object, then a view obect is typically a 'value object'.

A way to solve your problem, along the lines of what others mentioned, is to have a wrapper value object around your entity object.

The value object will not have any logic, but would only delegate the methods to the underlying model object.

A potential advantage to this would be that you can expose only the values that you need to display in the view in the value object and hide the rest. Also, if you derive a value to be displayed on the screen using multiple calls to the model, you can do that in the value object too.

[Ilja Preuss]

Originally posted by Sathya Srinivasan:
Also, if you derive a value to be displayed on the screen using multiple calls to the model, you can do that in the value object too.

Good point.

Just today I needed to have a textfield in a form (a Swing application) that should show "this value if specified, otherwise that value + 3". The only thing I had to touch to do this was the PresentationModel (we are using http://binding.dev.java.net/ in this project). Quite elegant...

[Stefan Bell]

Can you just use the ViewHelper pattern?

[Corey McGlone]

Originally posted by Stefan Bell:
Can you just use the ViewHelper pattern?

I'm afraid I'm not familiar with that pattern. Any chance you could point me to an online resource?

[Corey McGlone]

By the way, this is a strategy being employed by some other folks I'm working with. I can't say I'm very fond of this method. If you'd like to comment on that, I'd appreciate whatever you might have to say.

[Jeanne Boyarsky]

Originally posted by Corey McGlone:
So you're creating an additional class, which is a Java Bean that contains all of the data fields you acquired from the Model? Does that sound right?

Yes!

I had considered having the Action class create a special bean, but I guess I just hadn't taken it that one step further. That seems to be a nice idea and not too sloppy. I was afraid I was going to end up with gobs and gobs of objects that way (one for every class in my model) but this would really result in one bean for every view.

It's actually somewhere in between one for every class in model and one for every view. When a view consists of a table with rows, you usually want a bean class to represent the row too.

[Ilja Preuss]

Originally posted by Corey McGlone:


I'm afraid I'm not familiar with that pattern. Any chance you could point me to an online resource?

http://java.sun.com/blueprints/corej2eepatterns/Patterns/ViewHelper.html (found using google)

Sounds quite similar to what we discussed here, doesn't it?

[Corey McGlone]

Originally posted by Ilja Preuss:
Sounds quite similar to what we discussed here, doesn't it?

Yes, it does. Thanks for the link, Ilja.

[Stefan Bell]

Originally posted by Corey McGlone:


Yes, it does. Thanks for the link, Ilja.

It has always been beneficial to me.