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




On 9/21/06, Sam Davey <[EMAIL PROTECTED]> wrote:
I'm not worried as such... but my problem is the flexability of it all.
Don't get me wrong, thats one of the best features of the Zend Framework,
integrating any subsystems I design using ZF into my legacy system will be
incredibly easy compared to the vast majority of other frameworks available
(cakePHP, symfony etc etc).

I was just trying to clarify that the comprehensive tutorial I was following
was not adhering to MVC, and as such I shouldn't use the examples in the
tutorial as a basis for future development since all of the domain logic was
shoved in the controller.

I gather that by quoting 'MVC is simply a matter of keeping the domain,
application and view logic in separate layers' then you agree with my post.
i.e. the controller should not contain any validation or database
interaction since this is domain logic.  And the controllers main purpose is
to invoke methods on a the model based on input from the view.

I understand the principle of MVC... it is a design pattern.  Therefore from
my point of view its a moot point to say that ZF is not a strict MVC
framework since the strictness comes from your own design. I just wanted to
make sure that my take on it was correct so that I can enforce this
strictness.

I don't agree with your point that ' we clearly can't discuss about Model
when we don't have ORM
functionality yet to put domain logic into'.

Although ORM would certainly be useful for the majority of Models, they are
certainly not dependant on ORM.  Any database interaction can be done using
Zend_Db, granted you sacrifice some development time but basically achieve
the same thing.  Besides, some models may not relate to a database table at
all.


>From: "Mislav Marohnić" <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>CC: "Sam Davey" <[EMAIL PROTECTED]>, [email protected]
>Subject: Re: [fw-general] Advice for Model design
>Date: Thu, 21 Sep 2006 16:19:36 +0200
>
>Sam,
>
>Your approach, although basic, is not incorrect... I don't understand
>what you're worrying about. MVC is simply a matter of keeping the
>domain, application and view logic in separate layers.
>
>Keep in mind that ZF is not a strict MVC framework. Sure it has
>Controller and View, but it's more like a "make your own MVC" thing.
>And we clearly can't discuss about Model when we don't have ORM
>functionality yet to put domain logic into.



Reply via email to