Zend has done a fine thing not to add the M in MVC in their framework.
M = Model = Model for what?
Surely not for business logic, there is not ONE business logic but
millions of it. M in MVC can only be an infrastructure or persistence
thing, nevel BL itself.
"Model" for most (php) frameworks is just a persistance
layer/technology, almost always sadly clustered and polluted with some
real business logic (or vice versa).
A form should NEVER include business logic. Not in the sense of REAL
buisness logic, like how certain processes are handled/fired or what
happens if some data associated with another has to be checked (or
another constraints, rules, etc., etc.)
It's an very easy exercise to determine what's business and what
"application logic" (in the sense of presentation logic or UI):
imagine another UI which has no chance of showing a html form but also
can submit data in some form that can be validated and saved and that
can be responded to also (e.g. via SOAP, SMS or Mail).
The "logic" that is doing something with data coming from a html form/
iphone / handheld or even paper(!) should be always the same. That's
business logic. Everything else is AL/PL/UI.
In short:
If you MUST perform a "concept" of your business in all forms of
code/UI/data sources/software, then it is business logic.
So: even a "controller" isn't business logic either.
It's just a broker between UI and BL and orchestrates such things like
routing, input validation, form processing, calling business services
(here we go...) and probably returning or displaying something.
Cheers!
Philip G schrieb:
Okay, humor me on this one. But this is something I need to understand; why?
Here's my logic: the whole purpose of the MVC pattern is to separate out
the pieces of code, specifically the presentation logic (view), from the
business logic (controller). However, Zend_Form and its decorators seem
to have taken a step back in this, putting presentation logic
(decorators) right smack in the middle of business logic (form processing).
I have to ask, why?
Does this make sense? If so, can you please explain to me as to why?
I can understand Zend_Form for easy form processing, but quite frankly,
I rather have a Zend_Form that works for processing, validation and an
easily method of retrieving the errors, instead of an all-in-one:
display, processing, validation, error display.
Maybe I just don't get decorators? To me, decorators put presentation
logic smack in the middle of business logic. A step explicitly
unfavorable within the MVC pattern. Am I missing something here?
---
Philip
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
http://www.gpcentre.net/