Hey Shawn,
Now I would like to query the database to return specific
data. For a simple example "SELECT comment, email FROM Guestbook";
Where would that go? The controller?, or the Mapper
models/guestbookMapper.php, The model maybe?
It's ok, common question.
Your answer? "It depends".
If you have a 2 tier application that is just built with a "controller
like layer" and a "view like" layer. Then it goes in the controller.
That's generally not the case though. What you have in the guestbook
application is a standard, yet, lightweight 3 tier MVC application. V &
C you know, but M is the "model". This is a conceptual layer of code
best describe by what its NOT. It's not environment specific (like the
controller), and it does not handle representation or interface concerns
(like the view). It's the model: where any "environment agnostic /
interface agnostic" code would go.
It's called the model b/c you are "modeling" your business processes, or
a better word would be "domain logic".
Since your domain is made of data... and this data needs to be
persisted.. persistence of the data becomes a problem of the model.
Since the classic persistence mechanism is a relational database, which
you utilize SQL to interact with the database, this would mean your SQL
belongs in your model.. "somewhere".
Where exactly is another subject that is completely dependent on the
patterns you decide to employ.
In our example, we employ a mapper approach.
http://martinfowler.com/eaaCatalog/dataMapper.html
This can be used in conjunction with a domain model
http://martinfowler.com/eaaCatalog/domainModel.html
and these domain models can be found via a service layer
http://martinfowler.com/eaaCatalog/serviceLayer.html
your service layer can employ the use of an identity map to ensure it
doesn't duplicate objects during a request
http://martinfowler.com/eaaCatalog/identityMap.html
but you might also decide not to use SQL inside your mapper and instead
utilize Zend_Db_Table, our db table gateway and row gateway solutions.
http://martinfowler.com/eaaCatalog/tableDataGateway.html
http://martinfowler.com/eaaCatalog/rowDataGateway.html
BTW, active record is also one such persistence solution that also,
generally, also mergers its concerns with the domain model and service
layer:
http://martinfowler.com/eaaCatalog/activeRecord.html
.. in your controller, you might want to convert your models to either
an array of data, or a value object (also known in some circles as a
data access object)
http://martinfowler.com/eaaCatalog/valueObject.html
http://en.wikipedia.org/wiki/Data_access_object
Ultimately, your SQL goes in the model "layer".
There are enough links and terms above though so you can start educating
yourself on the variety of patterns that are employed in building
applications great and small.
Try searching the mailing list for "modeling", you'll get some
interesting discussions.
-ralph
