Question

To make my doubt clear, I have this scenario:

I have an app that sells cars and houses (just an example!), so I created a module to show all the cars, called Cars, and one to show all the houses, called Houses.

I have a Manager module that should have a CRUD system for Cars and Houses.

Where should I put my models for cars and houses? I should create a module just to put my models, like a Main module? Or I should put my models in Cars and Houses modules and access them in Manager module?

Let’s say I create a CarModel with the methods select, insert and delete. If I put this model in Cars module I can have a security problem because Cars now have access to insert and delete methods…

On the other hand, I could create a CarModel inside Carsmodule with only the select method and then create again a CarModel with insert and delete in Managermodule, but It will make very difficult to maintenance of the code…

What’s the best way to solve this issue?

Answer 1

So to answer your question at a high level, there’s really two ways you can go about breaking up your modules in the context you’ve given:

• All-in-one module (combine admin/CRUD with the actual module providing the entities and front-end stuff). One of my devs has taken this approach with this module: https://github.com/speckcommerce/SpeckCatalog
• Separate modules. For example, ZfcUser provides no user administration, but ZfcUserAdmin makes use of the entities / mappers in ZfcUser and provides additional user management / admin functionality.

Neither approach is wrong or right. It really just depends on your preference and how you want to break down the functionality of your application. E.g., Will you ever want to build a site that would use the Houses or Car module without the management / CRUD system?

On a more technical level, there’s several ways you can handle “models” or “entities” using Zend\Db. Two common patterns are the TableGateway pattern and the Data Mapper pattern.

• Table Gateway: I’ve blogged about this one: http://blog.evan.pro/zf2-tablegateway-hydration

• Data Mapper: This is my preferred solution. I haven’t blogged about this one yet, but you can find a usage example in ZfcUser. Also, a base data mapper is not built into ZF2 like the Table Gatway is, but it’s a much more flexible solution. Check out the AbstractDbMapper provided by ZfcBase.

I’ll take this opportunity to tease a couple of slides from the ZF2 tutorial that Rob Allen and I gave at PHPNW12 and will also be giving again at ZendCon in a couple of weeks:

Table Gateway http://evan.pro/caps/2ddbaf.png
Table Gateway Select http://evan.pro/caps/0904b8.png
AbstractDbMapper http://evan.pro/caps/a31480.png
Mapper Select http://evan.pro/caps/a2a04f.png
Summary http://evan.pro/caps/3ec9e6.png