I'm very insterested by this subject to... in particular about the subject of
validation. The MVC framework doesn't specify the way it should be processed
(if I'm right).
Therorically, the validation should be performed by the model, that is best
suited to deal with the domain logic (to perform validation on functional
dependencies, for exemple) as well as the data format controls (length,
numbers ranges) because it is usually strongly tied with persistance.
Of course, for performance and practical issues, the user interface (ie
'view') could also perform some basic validation.
So your design seems perfectly ok to me !
Just one thing: Controllers code is not always so basic, as must at least
handle what i'd call "data conversion": this is not stricly validation, but
you often need to convert the data passed from the view to the controller,
to a format expected by the model, and vice-versa: data from the model
sometimes need to be formatted before it can be passed to the client: that's
exactly what you are doing when passing back error array to the view instead
of passing your MessageModel:
$view->field_error_array = $messageModel->getLastErrors()
In some case (ie: client not having the same technology as the server) this
step is an important concern !
For my part, to enforce independence between view and model in php, I try to
always pass data to the view using string / array of string (well, I try ;-)
). Don't know if I'm right about this point...
So, for me:
* View: basic validation (required fields, length, number & date
formats...)
* Controllers: data conversion view->model, model->view
* Model: complete data validation
But I'd like to hear some other sound about this subject (in my experience
Validation is a crucial part for any application using interface)...
Jean-Baptiste HUNTZINGER
Sam Davey wrote:
>
> Before everyone groans 'not another missing model component question' I
> completely understand why a Model component is not included in the
> framework. After all a model is a domain-specific representation of part
> of an application so there is little to be gained from creating some sort
> of generalization of a 'model'. Rather than be included in the framework,
> model classes should be created as required by a particular application.
>
> However I would like some advice as to how a true MVC application should
> be designed using the framework. Given the current jumble of
> application/control/view logic of my current system I want to be
> absolutely sure I do thing properly from the outset when designing new
> systems using the ZF.
>
> I have been closely following the 'Understanding the Zend Framework'
> tutorials on IBMs developerWorks website and it has been an excellent
> resource, hopefully others will be familar with it.
> http://www-128.ibm.com/developerworks/views/opensource/libraryview.jsp?search_by=understanding+the+zend+framework
>
> The tutorial chronicles the creation of an online RSS/Atom feed reader.
> The first few tutorials showed how easy it was to organise systems into
> controller->action requests and how the Zend_Filter_Input and Zend_Db
> components worked. But all the code was included within the controller.
>
> My question is this.
>
> In MVC, if the controllers purpose is to interpret input from the view and
> manipulate the model based on that input (decoupling the view from the
> model) then shouldn't all the input validation code and database code be
> wrapped up in a model and never be included in the controller? And a
> controller should be increadibly simple and just call methods in a model
> based on a particular action.
>
> e.g. The following is my take on how a controllers logic should be if
> performing a simple insert into a database based on input from a form
> (certain values passsed to the view are not listed for brevity)
>
> class MessageController extends Zend_Controller_Action
> {
> public function insertAction()
> {
> $messageModel = new MessageModel;
> // If there was a problem with the input then pass details of the
> error back to the form
> if(!$messageModel->validateInsert())
> {
> $view = Zend::registry('view');
> $view->field_error_array = $messageModel->getLastErrors()
> echo $view->render('addMessage.php');
> }
> // Otherwise just call the insert() method and go back to a list of
> existing messages
> else
> {
> $messageModel->insert();
> $view = Zend::registry('view');
> echo $view->render('viewMessages.php');
> }
> }
>
> ... other actions
> }
>
> Although I have found the IBM tutorial incredibly useful... I just want to
> make sure I wasn't developing bad habits early. I can see that whacking
> all the code in the controller is quick and easy and would probably work
> fine for small applications but a large application would suffer wouldn't
> it?
>
> Can someone clarify how strict MVC should work with the Framework, is my
> take on controller logic correct?. Does anyone know of any tutorials which
> follow strict MVC?
>
--
View this message in context:
http://www.nabble.com/Advice-for-Model-design-tf2311120.html#a6426129
Sent from the Zend Framework mailing list archive at Nabble.com.
