But one thing that is frustrating to me at this moment is that all examples given are very simple. Too simple. In all those books they apply these advanced patterns to a single db table with 3 fields. Fair enough, but even in the most basic web application with just a few tables things get much more complicated.
I'll try to explain the issue as clear as possible.
Dealing with a single table is easy. You have a class User with fields name, email, password. Methods Save, Find, Delete, Update. Now you can apply every pattern to this until the real sql is hidden so deep down you'll never have to view it again. Everybody's happy.
But let's take another example. A blog post. That has fields: Title, Bodytext, Author, Date, Category. Easy enough. But wait, designing your db you have neatly separated the Author to it's own table, as well as Categories. So when you save a blogpost from your controller, the Blogpost class is actually saving an AuthorId and a categoryId
So now your class Blogpost looks like
Code: Select all
class Blogpost {
public function save(){
// save Title, Bodytext, AuthorID, Date, CategoryId
}
}
From the controllers point of view, the easiest would be to just hand over all the posted data to the Blogpost model and let the Blogpost model figure out how to save everything in the right tables. That would mean the Blogpost class method Save instantiates an Author class and Category class, and checks if the author and category already exists, get their id's. etc etc
Or, the controller has to:
- get the author name posted.
- check the author table if that author already exists
-- if so get the corresponding authorid
-- if not, insert the author in author table, and then get the id
- check the category table if the category posted already exists
-- if so get the corresponding categoryid
-- if not, insert the category in category table, and then get the id
- finally, get all data together and insert into blogpost table.
Either one of them has to do this. But who?