Attaching business functions inside the view, not a handicap?

[Jorge Martinez]

Hy,

I have been using JSF for a small time. I have reading about the two types of MVC pattern:

1. The controller gets a request from the view and it calls a service and then calls a view passing some model to render.
2. The functions are attached inside the view like JSF does


Questions:

1 . I read that in the MVC pattern the function of the view is to render the model, just that; the view is not aware of the business logic and the bussiness logic is not aware of the view. But when the bussiness functions are called inside the view, the view is aware of the businness logic. Is this not a handicap? I mean, for example if I change the name of some business method I would have to change the name of the method inside the view that uses it

2. What would be the advantages using MVC pattern of type 2 vs MVC pattern of type 1? I dont see them. I see the pattern 2 like if if I call business methods inside the JSP and not from the controller

Thanks

[Tim Holloway]

Actually, MVC has nothing to do - ¡in theory! - with business logic.

All MVC does is use Controllers to bind together models (and sub-models) with views (and sub-views). When one side changes, the controller refreshes the other, maintaining synchronization.

In practical terms, that's not much use. At some point, you have to do the intitial population and and at least one point you are going to want to take action on the data.

So we escape the MVC carousel by providing action methods, action listeners (not recommended) and AJAX listeners, which is where one normally ties into business logic. For convenience, I'm going to call all of these as "action methods".

A lot of people confuse these types of methods with Controller methods and thereby end up mis-naming their backing beans as Controllers when they are actually Models. You can spot a true Controller because ALL it does is reflect data back and forth between a Model and a View. In JSF, the Controllers are not user-coded, they're pre-provided.

In an ideologically purer universe, Action methods would not be part of the Model objects, they'd be some sort of entity in their own right. But that would require a separate action-handling class, like Struts does, and one of the annoyances of Struts that JSF set out to remedy was to reduce the number of classes required to deal with a given View.

I often caution people NOT to "code logic" into Views. A JSF View Template is (ideally) a static definition of the display, annotated with references to the Model (including action methods/listeners). And yes, it's true that if you change the name of an action method, the reference to that method would have to be changed as well. The alternative would be another layer mapping View abstract actions to concrete action methods, and people complain that Java is too obsessed with abstracton as it is.

Finally, the action method isn't necessarily business logic. It can contain validation code that's beyond the limitations of the simple JSF validators (for example, ensuring that a postal code is in correct form for a selected country) and do other non-business things. Ideally, it calls the actual business methods, but we usually don't go that far unless the business methods are fairly complex.

[Jorge Martinez]

Hy, really thanks. Some doubts:



1. Maybe I was wrong saying in JSF when from the view you call business methods you are attaching the view with the business logic ; this is not true because you are not implementing the business logic in the view, you are just calling a business method from the view, right?

2. This kind of design, I mean, the MVC pattern type 2, what advantages have?

Thanks

[Tim Holloway]

To be somewhat more precise, you are triggering execution of the business method from the view. The actual calling is being done by the FacesServlet.

If you're referring to the MVC2 paradigm that's used by Struts, it's actually not full MVC. It was an initial attempt to make MVC work over HTTP.

Originally, MVC was intended that as soon a a Model was updated, its View(s) would automatically update. But HTTP cannot send out unsolicited messages, so they altered the protocols to allow for that.

JSF is also constrained by HTTP's limitations, but they did a much better job based on what was learned from Struts, so it's a much more complete MVC implementation.

[Jorge Martinez]

Hy,

Thanks but what I meant was what the advantages are of having calls to business methods inside the view that passing just a model the view(objects); I am not talking here about jsf vs struts; I just refer to this difference.

Thanks

[Tim Holloway]

The prime goal of MVC is the decoupling of Model and View, thus ensuring that changes to UI stuff only be need to be done in the View and changes to stored data need only be done in the Model instead of here-there-everywhere. An additional benefit of this strategy is that a 1-to-1 Model/View relationship is not required. One View can pull data from many models. One model can be used to construct many Views. A classic example is when a single set of data displays as both a table and a chart (2 Views) but they're both the same data being rendered (Model), just in 2 different ways.

When you change the View from something that "defines things" to something that "does things", you undo some of that decoupling. When you start making parameterized method calls directly from the View, you up the cost of maintenance, since logic changes now require UI changes as well. And the maintenance programmer has to go en buscar de los tesoros - you have to hunt for what gets done where instead of being able to predict it independently of examination of the code. And if you really do have a Model/View relationship that's not 1-to-1, then changing one can break the other.

And that's completely independent of the security risks you get when you put stuff in the client that could be kept in the server. Clients can be much more easily hacked or even spoofed.