I would totally agree with you, especially since you mention that model
shoul not use a $_GET or $_POST !
This way, only the controller is dependant upon the 'client' technology
(and the format the view is using to communicate: http fors, XML, POJO
objects...).
Sam Davey a écrit :
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
|
