The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Interesting points, sweatje. I think they're valid, and you're probably approaching things correctly. I'll have to think on this some more, as I haven't needed to access multiple types of data souces simultaneously, yet.

Do these make sense as examples of Models using multiple persistant data stores? If so, how does one approach them from the "DAO's from the Controller" approach to MVC?

The Model needs to know where to get its data from. However, I think it's the job of the Controller to know about the environment, and direct the Model to the appropriate data store. I'm still coming from the 'Model=DAO+DCO' perspective. So, I'm sure there are other ways to go about this, and my approach could be wrong. That's why I started this thread, and am still trying to get the best understanding. How about this?:

I think it's the job of the Controller to know about the environment, and direct the Model to the appropriate data store. I'm still coming from the 'Model=DAO+DCO' perspective.

Your UserController code example makes perfect sense, that's probably how I would do it. The only difference would be that I would have the check($id) methods of the DAO's be findByID($id) methods that return a UserModel object, instead of an array of data that is then passed to a UserModel object. This is to fully encapsulate the logic of loading objects from some kind of data store in the DAO.

About Model = DAO + DCO.. I believe that the 'Model' is a collection of objects of different classes that represent the data and logic of the problem domain of the application. The Model is simply a 'logical' description of the problem domain embodied into classes, there is no 'physical' aspect about it (i.e. the saving/loading of data from a data store). (am I making sense here ?). The DAO does not have much to do with the Model, it should be considered as a separate layer. I can understand why you'd think it is part of the model, because it is so tighly coupled to it. But an application's Model is independent of the way it is persisted.

Think of a desktop application, one that does not store any data to disk, the data only lives in memory while the application is running. Such an application has a model too, but no such thing as DAOs. The model of this application consists of all sorts of interconnected objects in memory.

Man, I wish someone could give me some kind of ISO-compliant definition of 'Model', we probably wouldn't be having this discussion then

The only difference would be that I would have the check($id) methods of the DAO's be findByID($id) methods that return a UserModel object, instead of an array of data that is then passed to a UserModel object.

Yer, I'd have to agree with this point; it's the way I do it, then I use an Iterator to gain access to the data held by the said object, if you see what I mean ?

Lazy Load?!

I know I have to read Fowler, but for the moment I have to ask you guys to explain this to me:

Originally Posted by Captain Proton

In the second pattern, when the getImages() method of a UserModel is called, that UserModel object checks if its images have been loaded already (this can be stored in a boolean variable like $imagesLoaded). If they have been loaded, it returns an array of ImageModel objects. If they have not been loaded, it calls a method like loadImages() on the UserDAO to load the ImageModel objects, and then returns them. This pattern is called 'Lazy Load'. This method is better performance-wise because the ImageModel objects are loaded only when they are needed.

For those of us who have yet to get our hands on a decent book on Design Patterns (ie Me) I've come across this... ?

You need to subscribe first, those this is about a 2 minute delay really and looking at the PDF I think it kind of explains all the related Patterns pretty well as the author takes in the views of the GoF.

Ok... so $dao->find($userID) does not only create the user object and set the user id (and stuff...) but also adds a reference to itself to the user object (ie $user->setDao or something). I see... Does anybody else have this triple-inside-out-brain-twist-feeling? I need to do more OOP

Originally Posted by Dr Livingston

Could be useful until you get a hold of a book anyways as I see it ?

Thanks! I am doing that right now. (2 mins later) Hehe. I'm sure the author of that website would thank you for not saying anything about his 'security measures' ;-)

WHOA! I have just stumbled across this thread, and I see that some of you are in desparate need of expert guidance.

Originally Posted by texdc

I'm attempting to write my first app using the MVC design pattern, and am having difficulty modeling my data. Now, as I understand things, there should be a DAO for each table in the database, right?

WRONG! A data access object has absolutely nothing to do with the MVC (Model-View-Controller) design pattern. It is in fact part of the 3-Tier Architecture which separates presentation (user interface) logic, business and data access logic into separate layers or tiers. Although they both separate application logic into three parts they are not the same.

Secondly, you most definitely do NOT require a separate DAO for each database table. You have a separate class for each table within the business layer, and each of these objects talks to a SINGLE object in the data access layer. The idea is that the DAO constructs SQL query strings and squirts them at the relevant database engine using that engine's APIs. So, if you want to switch to a different database engine you simply switch to another DAO without having to touch any object in the business layer.

In case any of you think that I am talking out the wrong end of my alimentary canal I should warn you that I have successfully implemented the 3-Tier architecture in two separate languages, the second being PHP, so I am speaking from direct experience, not wild theory.

I have written an article called A Development Infrastructure for PHP which describes my infrastructure in great detail. A second article called A Sample PHP Application contains information about a sample of my application which you can run online, or you can download all the source code to examine and run offline.

You may notice that this infrastructure incorporates the MVC design pattern in addition to the 3-tier architecture. This was not deliberate, it just turned out that way. I have no doubt that my implemenation of MVC will offend somebody out there, but as it works (and works quite well, thank you very much) I don't much care.

Originally Posted by texdc

Almost all of my stored queries are going to use long/complicated joins. However, if I do use a seperate DAO/model for every table, how would I set things up?

When you are retrieving data from the database it is perfectly possible to use SQL joins within the primary database class. If you forced yourself to access each database table through its own object then your database queries would not be very efficient. What you MUST do however is to channel all table updates through that table's class.

Your controller object (in the presentaion layer) talks to the model object (in the business layer) which in turn talks to the DAO (in the data access layer). Note that there is NEVER any direct communication between the presentation layer and the data access layer.

This is absolute rubbish. It is perfectly possible for your PHP code to constrct a query string which incorporates one or more JOINs as they do not require BDB or InnoDB type tables. How do I know? Because I have been doing it for two years.

Originally Posted by texdc

I want to avoid passing the model itself to the view completely to keep them ignorant and separate.

Originally Posted by shoebox

Why do you want to do this? Is it a design requirement? The reason I ask is because it seems to make things much easier when you pass a model to view, or view to model.

True, the model and the view are separate components. But why do you think that you have to pass the whole of the model to the view, or the whole of the view to the model? This is plain daft. The way that it works (at least in my development environment) is that the controller talks to the model and obtains some data and the controller then passes this data to the view. Only data is passed to the view, not the whole model. Passing the whole of the view into the model is so ridiculous I am lost for words.

For those of you who seem to think that it is 'the done thing' to put all your business rules inside the database, I can only observe that you are missing a fundamental point - business rules consist of much more than constraints of relationships. I put all my business rules, including constraints, into each entity's class. To keep it all in one place is called 'encapsulation', a term that you may have come across in your travels.

WHOA! I have just stumbled across this thread, and I see that some of you are in desparate need of expert guidance

This is absolute rubbish. It is perfectly possible for your PHP code to constrct a query string which incorporates one or more JOINs as they do not require BDB or InnoDB type tables. How do I know? Because I have been doing it for two years.

Here endeth the lesson. Don't applaud, just throw money.

Lol, you need to read some of the posts a bit more carefully. Sweatje was explaning the advantage of doing the joins at the database level(via views and stored procedures) instead of doing the join at the application level in the php script. textdc's response was referring to the fact that MySQL can't do that yet so he's stuck to doing the joins in php.

You are intelligent and have a lot of good things to say but are a little hyper and arrogant. Lose the 'my-way-or-the-highway' attitude, settle down, take a deep breath and share your ideas without trying to force them down people's throats.

You are intelligent and have a lot of good things to say but are a little hyper and arrogant. Lose the 'my-way-or-the-highway' attitude, settle down, take a deep breath and share your ideas without trying to force them down people's throats.

Do you call me 'arrogant' because I claim to be right when in fact I am wrong, or because I claim to be right and I am right? Judging by the posts in this thread there are a large number of people who are very confused about the 3-tier architecture, the MVC design pattern, and data access objects. I am just giving my opinion as someone who has actually written a working infrastructure which combines all of these. You can download my source code and judge for yourself. If you think my ideas have merit, that's fine. If you think they are useless, that's also fine. I am certainly not saying that my way is the only way, but that I have found a way that works, and it's a different way.

The MVC pattern has been discussed solidly for the last year here at this forum, and for the most part has settled down to the point that the pattern in regards to use of with PHP has been more that refined

Take note of the sticky MVC thread please, an excellent read and a lot of people have posted their intrepertations of this pattern, myself included.

And yes, you are a bit hyper and need to calm down some. I've read a lot of stuff you have on your website, and it's interesting how you go about doing things, but it's not written on stone, in other words there is more than one way to skin a cat.