Re: [fw-mvc] Application structure

Great!
Thanks again, Matthew!

--
Ramses Paiva
Software Consultant
SourceBits Technologies
www.sourcebits.com

On Wed, Sep 24, 2008 at 6:50 PM, Matthew Weier O'Phinney <matthew@zend.com> wrote:

-- Ramses Paiva <ramses@sourcebits.com> wrote
(on Wednesday, 24 September 2008, 09:39 AM +0530):

> What about the session? Is it supposed to be handled as model and the accessors
> to it should be placed in the business logic, or it should be handled as
> temporary data that could be handled by the controllers and passed to the model
> by the controllers?

I tend to use sessions as request data, and pass this data from my
controller to my models and views. Your models should not be dependent
on session data, as they may be consumed in a non-session-aware script
(for instance, a cronjob); views should no be session aware for the same
reason. Your controller, however, is *environment* aware, which includes
sessions.

> I always have to access session variables in every place, views, controllers
> and models.
> To the views, the controllers could simply assign view variables. But for
> controllers, I could handle the session by the model and controllers could
> retrieve it from there, or the controllers could handle the sessions, setting
> and passing it to the models and to the views.
> What's the best approach?
>
> Ramses
>
> On Tue, Sep 23, 2008 at 7:18 PM, Matthew Weier O'Phinney <matthew@zend.com>
> wrote:
>

>     -- Ji   N mec <konference@menea.cz> wrote

>     (on Monday, 22 September 2008, 09:45 PM +0200):
>     > I would like to ask about "where should I put the code". Sometime
>     > I am asking myself, should I put this code into model or leave in
>     > controller or create own library class..?
>     >
>     > For example, there is a new user account registration process. I have
>     > to show a registration form in a controller (should I create the form
>     > object in the controller or create new class extended from the
>     > Zend_Form or create the form object in the controller...?),
>
>     The quick start clearly shows extending the Zend_Form object in a custom
>     class.
>
>     > after submitting there is need to validate data (should I do it
>     > directly in the controller or in a library...?),
>
>     This is open for debate. Some consider such validation part of the
>     decistioning/branching logic of the controller. Others feel it should be
>     part of the model. I've done both approaches. They're both valid.
>
>     Deciding what view and model to use (and what data to pass to each) is
>     *definitely* in the realm of the controller. This is not business logic
>     -- it's considered application logic. And yes, there *is* a difference.
>     Application logic is geared around the workflow of a request, while
>     business logic is related to the objects making up your model, and is
>     typically data oriented.
>
>     > then I save a user account data (again, do it in the controller, model
>     > or a library which will cooperate with a model...?) into the database
>     > table...
>
>     Your model is a class, or set of classes. Somewhere, at some point, you
>     have to pass data to the model. This should happen in the controller.
>
>     > I'm thinking that controller should respond to all user requests (and
>     > should not contains any business logic) and through (library) objects
>     > works with models and access data sources and do anything else.
>
>     Your models should work with data sources. And, currently, we're doing
>     exactly what you suggest in the Quick Start.
>
>     > I am asking you because when I looked over your quick start
>     > application, there is in GuestbookController two protected functions -
>     > _getModel() and _getGuestbookForm() and, maybe I am totaly wrong, but
>     > this doesn't fit in my concept of M/V/C separation (I would rather put
>     > this code into separeted class object which returns a concrete form
>     > object).
>
>     That's all these methods are doing -- they're simply returning the
>     concrete instances of the model and form objects, which are defined in
>     separate classes. Somehow, some way or another, the controller needs to
>     get these instances. How else would you suggest grabbing them?
>
>     > I know there is no dogma about this question and probably this be up
>     > to each programmer, but are there any advices/propositions/rules how
>     > to divide a ZF (or whatever other MVC) application and where to put
>     > the code? I still haven't found sufficient answers for my questions.
>     >
>     > What do you think abou it? What is your best practise?
>
>     The Quick Start. ;)
>
>     --
>     Matthew Weier O'Phinney
>     Software Architect       | matthew@zend.com
>     Zend Framework           | http://framework.zend.com/
>
>
>

--

Matthew Weier O'Phinney
Software Architect       | matthew@zend.com
Zend Framework           | http://framework.zend.com/