Excellent, thats cleared up most of my confusion. As a lazy programmer it seems like over kill to do validation in both the Controller and Model HOWEVER as someone who appreciates good design it makes perfect sense.
Any data from any type of view (be it web based, command line based or other) is sanitised and converted into a format the Model expects, this is done by the controller. The model method called must receive data in the format specified by its design. It needs to validate what it receives and perform the business logic defined in the method called. As such the model is completely decoupled from the controller and can be taken out of one project and dropped in others at will. Hmm.. This sounds a lot like how all the books on Design Patterns I have describe MVC. Who'd've thought? So to make some soundbites about this post: * The contollers job is more involved than I first suggested since its job is to validate user input and convert it to a format that the model expects, or the other direction where it grabs data from the model and puts it into a format the view will use. * The model needs to validate any data it receives. It should never work with data from $_GET or $_POST since this implies that it is working with a web interface and the model shouldn't be aware of that. * In most cases only the model should interact with the database (if the model relates to a table or tables) >From my point of view other PHP frameworks which are available are slightly muddying the MVC principle since the models tend to be tightly coupled to the actual framework used. This has made it quite difficult to relate what I read about the MVC design pattern to actual implementations. I have a much better understanding now. I can see why other frameworks are useful as rapid development tools but I'd much rather work on components I can reuse in any project. Here's hoping ZF 0.2 will be released soon (and 1.0 is not too far away). Ralph Schindler wrote: > > From my work with modeling / controller code, it seems to me that there > are actually 2 distinct layers of validation. In the web world, the > controller must validate data off the wire for the application, and the > model must validate data for its own business logic and data sanity > within the context of the model. It seems to me that you cannot lump > validation into one place or another, you should have both as they are > attempting to attain two separate goals. > > The controller is trying its best to make sure that data from the user > is sane in the application sense, ie, not trying any silly sql > injections or rouge quoting techniques, etc., making sure that the > correct number and types of arguments are being passed to the > controller... IE, if a controller needs argument $_POST['action'], to > make sure that it indeed exists. If not satisfied, the controller shall > throw an application error handled by the application or controller > exception handler. > > From the models perspective, it should only be concerned with getting > as much data as required to process a business rule.. IE, did the user > provide me a first_name, last_name, birthday. AND is birth_day in the > format that I expect. If not satisfied, the Model throws a Modeling > exception, handled by the controller. > > FWIW, > -ralph > > John Wells wrote: >> Sam, I think you've brought up a very good point actually. I would >> completely agree that the Controller should actually be doing very >> little actual "work" on the data. Especially when it comes to >> validation, as Jean-Baptiste mentioned, I think those basic tutorials >> start to muddle things up. >> >> I saw a friend coding out an application using Code Igniter last week, >> and all of his form input validations were being done within the >> controller. This is actually by design of CI itself, and I'm not sure >> if it could even be done within a Model (although I haven't tried). >> Point is, CI's manual is telling the coder to place validation rules >> within the Controller, and I don't think that's the right place at >> all. >> >> What I like to do in my apps is have my Controller pass to my Model my >> entire $_POST or $_GET array. I have a MyModel::setObject() that sets >> the object properties based on the array given to it (I have a choice >> of whether or not to 'blindly' set properties that haven't been >> declared). Afterward my Controller can call the model's >> MyModel::isValid() method to see if it passed all of the requirements. >> If not, there is a MyModel::$serverMsg array containing a list of >> problems, that the Controller can pass off to the View, etc. etc... >> >> Anyway, I think you're on the right track Sam... >> >> -John W > > -- View this message in context: http://www.nabble.com/Advice-for-Model-design-tf2311120.html#a6444284 Sent from the Zend Framework mailing list archive at Nabble.com.
