Thank you for coming to my forum.
Yes, please post all comments and questions here. I am trying to move my viewer's activities away from youtube for the purpose of better communication and organization.
Quick Start really changed since last time i checked up on it. I think even as late as this summer it was still pre ZF 1.5 with many mistakes. There were many comments with attempts to help others make it work. This was one of the factors that motivated me to get the videos going. Now it looks like a proper tutorial that has current and working information. Also, data mapper design pattern was not included back then either.
The reason for me to not use too many techniques in any one video is to be able to concentrate on one particular topic I am discussing. As much as the goal is to show how different peaces can interact together in a full project rather than showing isolated code snippets that no one knows where to put as in the official manual, I still want to avoid information overload. If I am going to explain how to get data into, say, accordion pane I would also have to simultaneously explain about Data Mapper and viewers will surely get lost. This is a good topic for a "database techniques" video that I am planing on doing.
About Data Mapper itself, it surely is a good design pattern. It does an even better job of separating business logic from data storage logic than a typical DB wrapper. That said, I think many times a typical DB wrapper, like Zend_Db_Table itself is good enough. According to site linked from QuickStart, (
martinfowler.com/eaaCatalog/dataMapper.html) it is best used when objects in application have a data structure incompatible with data structure in the storage. DataMaper prevents having complex process of extracting data from application object into storage and vice versa from showing up inside of business logic model. This is especially crucial for developers in a team (to avoid assignment conflicts) and for maintenance (if something needs to be changed to storage back end, the entire application should not be affected).
So it is very good for more complex objects but in my simple book class that i am creating in tut 18, it would probably be an overkill. My object data and database data are so similar, that the code I now have in the book model class for getting information about a book from DB is going to be identical to the one I would right in a DataMapper. I would only introduce an unnecessary overhead of having another object in memory. In my case the abstraction of Zend_Db_Table is already sufficient to make my application storage independent.
However, that is a matter of opinion. I would like to know your thoughts on my tutorial #18.
I've just briefly looked at doctrine and again, its an attractive solution for complex projects. A little frustrating, however, at how you have spend time to learn yet another toolkit while working on a project in order to get something done, instead of spending that time on the actual problem at hand.
Forum