Hey everyone,
Sorry about the repost (most of you probably havent seen it as I posted it on Nabble, and of course realized that it didnt get sent because I didnt have a subscription to the mailing list (cancelled it because I was reading everything on Nabble). Anyhow, I am reposting the message now that I have re-subscribed to the list, so it will get some exposure beyond Nabble. I have just gone through an article "Model Infrastructure" -> http://weierophinney.net/matthew/archives/202-Model-Infrastructure.html A most excellent insight on Zend Framework and Domain Models (Matthew you are my hero!) The comments in the article brought me to a slide show "Zend Framework Workshop, DCP09" -> http://www.slideshare.net/weierophinney/zend-framework-workshop-dpc09 An even better, and more up to date insight (Matthew I bow down to your greatness). // on a side note: I love all you guys/gals who have contributed and made Zend Framework what it is today (and what it will be tomorrow) ---- Ok enough rambling, on to nitty gritty. In the first artcle, we are building a model, using a Gateway pattern. The model itself extends Zend_Auth (brilliant, but not necessarily what you are supposed to be doing with light weight models). I poked through the Patterns of Enterprise Architecture / Martin Fowler. In the book, he refers to the gateway pattern being the pattern of choice due to its ease and flexibility. Reading through the comments in the article, I came across the second (and newer/different) ideals by using a DataMapper pattern in replacement to the gateway pattern. I then started reading up on the DataMapper pattern. I like both patterns, both are very functional. However I did get a little confused. The first thing I am a little confused about: My logic is that we have a data source (be it a database table, a web service, a file, etc). Now according to PoEAA, a service is the 'business logic' of the application. However, Matthew places a service between the Controller and the DataMapper. (Makes sense to me). On the other hand I also see services as being the layer between the DataMapper and the DataSource. (For example we have "Zend_Service_Amazon". Is that not something we could/would layer between the DataMapper and the DataSource (being Amazon). (Forgive me if I am wrong, I really haven't worked with that 'service' yet, I am just throwing out an example). So if that *is* a service, then by my logic: App_Model_DbTable_User extends Zend_Db_Table_Abstract (in the slideshow) *should* really be App_Service_DbTable_User extends Zend_Db_Table_Abstract because in my logic, the layer between the DataMapper (App_Model_User_DataMapper) and the DataSource (The database table) is a service, and in this case is an extended class of Zend_Db_Table_Abstract In saying that, here is how I envision the structure: |--> /models | |--> User.php (Default_Model_User implements Zend_Acl_Role_Interface) | |--> Article.php (Default_Model_Article implements Zend_Acl_Resource_Interface) | |--> /services | |--> User.php (Default_Service_User) | |--> Article.php (Default_Service_User) | |--> /User | | |--> DataMapper (Default_Service_User_DataMapper) | | |--> DbTable (Default_Service_User_DbTable extends Zend_Db_Table_Abstract) | | | |--> /Article | |--> DataMapper (Default_Service_Article_DataMapper) | |--> DbTable (Default_Service_Article_DbTable extends Zend_Db_Table_Abstract) So in my vision, the /models stays fairly clean, contains basic properties and no business logic at all (however may contain behaviors that manipulate the data/properties themselves). The service contains the business logic (create, login, save, etc) and would have the ability to create new objects (without id's say in the case of the User). The DataMapper handles the actual 'creation' of the User/Article object (as it comes from the database (or other data source)). I am not altogether sure where the best placement of the DataMapper is because it deals with a model it could go in the model directory structure, but it also deals with the data source (which as I stated to me feels like a service), so it could go into the service directory structure. If my thoughts on this are out of line, please correct me. The other thing I was thinking is that I should have a contract (implements) for the DataMapper class which defines the requirements of the data mapper. For example the service will want to call functionality of the data mapper in order to do things. Lets use 'save' as an example: $user = (an instansiated modified Default_Model_User object loaded from the database) $userService->getDataMapper()->save($user); Now within the DataMapper object we have a method called save, which contains the logic to call the Zend_Db_Table_Abstract class (Default_Service_User_DbTable in my case) Now lets say we want to use a different data source. The new data source has a different api to work with data. No problem, we create a new (or modify existing) DataMapper. The save function in the new / modified data mapper, makes the appropriate calls to the api, and appropriately saves the data to the new data source. The problem that could arise, maybe we decided to call the 'save' method as 'wHey everyone, Sorry about the repost (most of you probably havent seen it as I posted it on Nabble, and of course realized that it didnt get sent because I didnt have a subscription to the mailing list (cancelled it because I was reading everything on Nabble). Anyhow, I am reposting the message now that I have re-subscribed to the list, so it will get some exposure beyond Nabble. è
