I think we are missing entire layer here - service layer. It lays under
application/services and it is registered as default space in autoloader.
I'm thinking about how it should look like with doctrine models.

http://dev.juokaz.com/programming/service-layer-in-web-applications

Any advices on this topic and good examples are welcome.

Regards,
Saša Stamenković


On Fri, Nov 19, 2010 at 7:00 PM, Fozzyuw <[email protected]> wrote:

>
> 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