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/

Reply via email to