[Frameworks] Un Controller ne doit pas avoir de logique métier!

Il existe de nombreuses pratiques pour développer du code propre, pérenne et accessible. Nommer la liste ici serait une perte de temps.

Parmi toutes ces lois, techniques et conseilles, la liste des 13 plus mauvaises pratiques appliquées à Rails soulève un point intéressant que l'on ne retrouve pas forcément dans les sites à base de Frameworks :

Chubby Controllers Must Die

There should be no business logic in a controller.

Read that again.

There should be no business logic in a controller.

Controllers do two things: they take data from the params or session and send it to the model. The MODEL performs all the necessary logic. Then, the controller does the other thing that's completely necessary: it decides what should be shown to the user. That's it. The sum total of a controller action is two steps long.

  1. Send information to the model.
  2. Decide what to display.
If you are doing ANYTHING ELSE in your action, you are doing it in the wrong place. The end.

Le problème n'est pas forcément le développeur, qui ignore cette pratique, mais aussi les créateurs du framework, qui, par l'absence de composants adaptés, force le développeur à mettre du code métier dans ses controlleurs.

J'apprécie particulièrement cette remarque qui soulève un point fondamental sur l'usage des frameworks et prouve que leur utilisation n'est pas le stade ultime en matière de développement efficace.

Ce n'est pas parce que vous utilisez un framework que vous faites les choses bien !

Filed under  //  Development   Projects   chubby   controller   framework   practices   techniques   tips  
Posted by Cyril Nicodème 

Why the form validation are in the View part ?

The question is quite clear and I'm going to explain my point of view.

If you take a look at Struts or JSF,and I'm sure, for a lots of others frameworks out there, the form verification are made in the View side.

For example, this is a wrong method (IMHO) used by JSF templates :

<%@taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
<%@taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
<f:view>
   <h:form>
      <h:outputText value="Name: "/>
         <h:inputText id="name" required="true" maxlength="20" value="#{user.name}">
            <f:validateLength minimum="3" maximum="20"/>
         </h:inputText>
         <h:message for="name" style="color: red"/>
         <h:commandButton value="Submit" action="success"/>
      <h:form>
</f:view>

The point I want to raise is the fact that it's generally the job of the web designer to make the template, the forms, but NOT to make the verifications !

Yes he need to know which value is needed, eventually which type is waited (for implementing nice date picker for example), but not to test if the string is too short or too long, if it's an email, etc.

The side that must handle this kind of operation must be the Controller, that know which type a field must be. Eventually, the Model side can impose its structure to the controller, but never the View side ! A webdesigner must never impose the structure of the data. Right ?

Ok now everyone is boiling about what javascript is able to, and I totally agree with that, but with restrictions.

Client-side verifications must be implemented only to improve user experience. Never forget that javascript can be disabled !

But it's a great idea to tell at your webdesigner the constraints for the form in the fact that he could implement a client-side verification, and then, your controller will do the server-side (final) verification, in case javascript is disabled, or some bad guy try to play with your code :p

I would be pleased to know your opinion about that :)

Filed under  //  Design   Development   General   Javascript   Projects   ajax   controller   model   mvc   side   template   view   webdesign  
Posted by Cyril Nicodème