Thanks to both Hector and Bill for this discussion.

After Bill's discussion I did go back and read over more of the ZF
quickstart reference and I got a bit more out of the file structure for
models and data access classes.

What I've decided to do is break out some folders like this:

/application/models/DbTable/
/application/models/mapper/
/application/models/

I put the mapper classes that the quick start guide talks about into their
own folder as well and then add it as a resource in my bootstrap.php.

$resourceLoader = new Zend_Loader_Autoloader_Resource(array(
        'basePath'  => APPLICATION_PATH,
        'namespace' => '{My}',
));

$resourceLoader->addResourceType('form', 'forms/', 'Form'); # where I store
form classes
$resourceLoader->addResourceType('models', 'models/', 'Model');
$resourceLoader->addResourceType('data', 'models/DbTable/',
'Model_DbTable');
$resourceLoader->addResourceType('mappers', 'models/mapper/',
'Model_Mapper');

I'll see how that works for organization.

Right now, I'm working with building a product database.  In this case, I
have a several tables that combine to make a whole product.  There's basic
product information (part number, UPC, list price, etc), product attributes
(color, size, etc) and values for product attributes (red, blue, large,
small, etc.).

But in the sense of an full entity, a product is made up of the product
information and it's attributes.  So, I would have a "product" model that
will have an array of attributes models and attributes will have an
attribute value model.  I'm not really sure if attributes and their values
are m models, or if the product model could just organize it, but I'm trying
it like this first.

As Bill mentioned, I can then extend this product model to for E-Commerce
and have it create Invoice models, which handle the saving of data to the
databases invoice table(s), as well as other possible utility methods that
might simply notify a sales or fulfillment person by email.

The idea is to try and get a better grasp of what should be a model and what
shouldn't be, and if not, what is it?  It seems like there are utility
classes such as a logger or, I would think, an email notifier, and data
access classes such as Zend_Db_Table extensions.

But what would be a good Model would be a Product, an Invoice, a User
account which might have a User model, and so on.

So, in general, the M in MVC seems to be a bit more expansive than what it
might appear to be on the surface.

Thanks much!

-- 
View this message in context: 
http://zend-framework-community.634137.n4.nabble.com/ZF-models-and-Zend-Db-classes-tp3049177p3050747.html
Sent from the Zend Framework mailing list archive at Nabble.com.

Reply via email to