Hey Kyle,
There I learned to turn off my HTML formatting (is that better? :)
). Anyhow, thanks for your response. Reading through the examples you laid
out, I am gathering due to the actions that _processForm is a protected
function of the action controller. When I said in my post that I code stuff
in the controller, I do that merely for quick testing of a component,
generic, basic setup and development / usage testing. The second part of
that is that once I understand (to the best of my abilities) then I refactor
the code out of the controller (generally, some things I test inside of
models and views as well), and I refactor it to where I feel it best belongs
and is best used (which is kind of the main topic of the thread here, where
does stuff belong). Some people believe that code belongs in the
controller, some people believe that code belongs in the model, some believe
it belongs in the view (obviously depending on the context). Me I have
started looking at it more along the lines of code is the 'muscle' of the
application and belongs 'between' those components. From my perspective,
the Action controller is where I put specific calls to functionality through
services (so basic straight forward lightweight). The model in my world is
simple, handles essentially the state of a data object, with little to no
behaviours (unless they are directly related to the state of the object /
properties themselves). Most of the processing power would reside in the
DataMapper when it comes to models. The view, I have stayed away from all
but the basics with the view, but I believe when I get to developing strong
views, they will most likely be broken down into reusable components in
small manageable bites. Again with the view, very little to no code, and
only code that relates directly to the view itself (ie displaying the
contents or part of the contents of a model or other object that has been
passed to it). I would also look at Zend_View as a service in context, the
actual view would be the final rendered output, the Zend_View_<whatever>
would be the service (which I differentiate from the actual view which would
be the final outputted product be it an HTML page, a PDF file, an Excel
spreadsheet, or whatever format it may be in), Zend_View would be the
service (or whatever class you created/extended/etc) to the 'View' just as
Zend_Db_Table would be the service layer to the physical database.
Now back to what you are saying, I disagree with putting a
_processForm function into the action controller (for reasons I stated
above). The action controller should merely instansiate the service object
(say: Default_Service_MyModel), pass the data to that service and have the
service handle the core of the loading of the Default_Form_MyModel and
validation of the data. Then once the data is validated, filtered, and
whatever else you want to do with it, it gets shipped off from the service
layer to the datamapper which turns around and creates the
Default_Model_MyModel object, and hands it back to the service layer, which
in turn may do other processing such as having the datamapper save the
object to the database, or even return the validated object back to the
action controller to be shipped off to the view renderer. If the validation
fails, it could return some kind of failure / exception back to the action
controller to be handled appropriately.
Note in what I am saying, the Default_Form_MyModel is an object in
itself (which I am gathering you picked up on). The Service merely calls it
and utilizes its capabilities to validate the data. This however also means
that you can instansiate the Default_Form_MyModel, and send it to the View
Rendering 'service' as well (multi use object). In the case of a failure in
the controller to datamapper service layer, the service could return the
instansiated (and thus populated) form object back to the action controller
to be rendered (as populated) in the view. (Hope I made sense with that,
its getting late here).
So my logic is to keep the Model, View, and Controller as skinny as
possible, and insert layers in between each. Here's a best effort ascii
diagram of what I am trying to say:
View (Screen/Monitor/PDF/etc)
|
View Renderer (Zend_View) - Service Layer
|
Action Controller (Zend_Controller_Action)
|
Model Handler (Default_Service_MyModel) - Service Layer
| \
| \
| The Model (Default_Model_MyModel) - a raw instance of the model
(created by the DataMapper, handled by the service layer (handler)
| /
| /
Model DataMapper (Default_Service_MyModel_DataMapper) - DataMapper (builds
the model objects, talks to the datasource service, and is controlled by the
Model handler/service)
|
Model DataSource Service (Default_Service_MyModel_DbTable) - The layer
between the datamapper and the data source that handles the actual
datasource communication API (ie FetchAll())
|
Data Source (Database Table, File, Web Service, etc.
Bear with the terminology I am using above, I am still learning
quite a bit of this and am trying to keep it organized in my head at this
point. Also please do not feel that I am saying you are wrong in your
methods. There are many ways to do the same thing in programming (and many
different views of how DDD and Patterns should be implemented). All I am
merely saying at this point, is that the way you are interpreting the design
processes is a quite a bit different than the way I am perceiving it. I
could also be completely wrong in my logic (hence why I started this
thread), so please feel free to keep discussing your stance and views on
what I have said.
Thanks
Aaron
From: Kyle Spraggs [mailto:the...@spiffyjr.me]
Sent: September 24, 2009 9:21 PM
To: Aaron Murray
Subject: Re: [fw-general] Domain Driven Design / Patterns of Enterprise
Application Architecture [repost]
Since you mentioned a form I'm gonig to show you how I generally handle
forms. It's probably not the best way but it seems to work okay for me. I
utilize the model/mapper setup in the Zend Framework Quickstart.
// Standard add action
public function addAction()
{
$this->_processForm();
}
// Standard edit action
public function editAction()
{
}
// Processes the form for adds/edits.
protected function _processForm($model = null)
{
// Setup the form
$form = new Default_Form_MyForm();
// If it's an edit a model will be passed in with the default values, if
not, create a new one
if (null === $model) {
$model = new Default_Model_MyModel();
}
// If we posted data verify it's correct (this also sets the values of
the form back to what the user entered)
if ($this->_request->isPost()) {
if ($form->isValid($this->_getAllParams()) {
$myModel->setOptions($this->_getAllParams());
$myModel->save();
}
} else {
// If it's an edit and nothing was posted fill in the default values
(nothing happens if it's an add)
$form->populate($model->getOptions());
}
}
For the form I generally do all validation inside the form. This keeps the
controller skinny and the logic where it belongs. If you overload the
isValid method you can easily add your own custom validations as shown
below.
public function isValid($data)
{
$valid = parent::isValid($data);
if ($this->name->getValue() != 'Bob') {
$this->name->addErrorMessage('Bob is the true
name!!')->markAsError();
$valid = false;
}
return $valid;
}
So, if the user didn't enter Bob in the name field they would be presented
with an error and the form would not validate.
I hope this helps.
--
Kyle Spraggs (SpiffyJr)
http://www.spiffyjr.me
