This video explains how to layout model classes in order to read data from the database and transpose it to a processable format. Since explaining how classes should work alone is long enough I only did the read form the database part and will do writing to the database next.
The focus of this super long video is two-fold. Firstly, I was often asked about the way I did my BookLister, how it looked similar to new ZF quickstart but did not fully fit into a proper design pattern. There were also many questions on how best to organize code between Model and Controller, what should go where. Even though there is little to none ZF specific functionalities discusses, I hope to answer all those quetions about best practices in organizing an MVC. Experienced developers may find all of this old news and boring but I just cannot ignore many requests from newcommers to this not so welcoming paradigm. Secondly, I was asked to look at a full CRUD in ZF. I never addressed the issue at the time because at the time I was concentrating on some specific ZF functions (paginator, translator etc.) rather than application as a whole. Doing a DataMapper is a perfect opportunity to answer the CRUD requests since a good DM adapter should allow for seamless data transition in any direction so I will take care of this in the next, hopefully shorter, video.
Finally, before you press the play button, you may note that I do much less explaining and going over than I did before and most of the time just typing code away. Since there is so much code to go over I do not want to make this a 5 hour long video by going over everythign I do so instead there will be a short summary video at the end of second installment where I do a very fast walkthrough and note any places where you have an option to do something different.
Key notes in the presentation:
- Separating application logic and persisent data storage read/write commands using Domain Object and Data Mapper concepts making sure that Domain Objects concentrate only on solving business problem and forget about tedious backend.
- Pickout common components from Domain Object and Data Mappers in order to make a uniform and consistent architecture avoiding any potential conflicts. This will be done using abstract classes.
- Looking at what a Domain Object should be.
- Looking at what a Data Mapper class should be.
- Making sure relational database structure is fully normalized for.
- Generating Domain Objects using Data Mappers based on search criteria (using single specific ID, all available, or a certain range); the R in CRUD.
- Implementing Data Mappers to request data required.
- Implementing Domain Objects to display data aquired.
| < Prev | Next > |
|---|
