MVC::Normalized_Database(?);

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.

Umm.... Typically I use:

PHP Code:

---

$dbase = & new mySQLAccess(..., ..., ..., ...);
...
# and pass $dbase ... 


---

Well, why not create an instance of a File Handler class as well and pass this along to the MODEL as with $dbase ?

Does that make sence ? :)

--EDIT--

WhatsaControllerAnyway

http://c2.com/cgi/wiki?WhatsaControllerAnyway

May help to shed some light on the matter ?

Quote:

---

Originally Posted by Dr Livingston

Wouldn't think so personally, I'm one of those who think that Daos belong solely with the MODEL Layer.

About the point of requiring more that one Dao, ie Database and LDAP then I presume then you'd have 2 MODELs no ? Much like 2 VIEWs if you have Media = 'screen' and later Media = 'print' ?

The CONTROLLER would then select the appropriate MODEL to use I think ?

---

Or (perhaps) better yet:

Have the controller act as an observer such that you can register which models it will fire and in what sequence, and the models can call back to the controller to pass data to be used by a view....

In that fashion the controller doesn't "determine" the model call per se, it simply follows a given event sequence for a given request.

Just a random thought...I'll have to think about it a bit more, but for now, back to refactoring PL/SQL code :)

Cheers,
Keith.

Off Topic:

Quote:

---

Originally Posted by Taoism

Just a random thought...I'll have to think about it a bit more, but for now, back to refactoring PL/SQL code :)

---

Hey...that's what I am doing at this very moment ;)
Do we all just get to code in PHP for fun :D

Quote:

---

Originally Posted by Taoism

Or (perhaps) better yet:

Have the controller act as an observer such that you can register which models it will fire and in what sequence, and the models can call back to the controller to pass data to be used by a view....

In that fashion the controller doesn't "determine" the model call per se, it simply follows a given event sequence for a given request.

---

Would you mind explaining this further?

Thanks!
-texdc

From what I know of the Observer Pattern, it is a method of calling one class or functionality based on another classes or other functionality being updated no ?

So in principle you'd be calling the MODELs as required though not from the CONTROLLER as such but from another source ?

Umm... I understand the theory though implementing it into script is something more :D

Although I'd be interested in seeing how it all works out as well ?

:)

Quote:

---

Originally Posted by sweatje

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?:

PHP Code:

---

class UserController extends Controller {
    var $dbDao;
    var $sessDao;
    var $cacheDao;
    // etc...

    var $model;
    var $view;

    function UserController(&$dbc, $cache_dir) {
        $this->dbDao =& new myUserDao($dbc);  // mySQL
        $this->sessDao =& new sessUserDao();  // $_SESSION
        $this->cacheDao =& new cacheUserDao($cache_dir);  // file/cache
    }

    function getUserByID($id) {
        $ds1 =& $this->dbDao->getID($id);
        $ds2 =& $this->sessDao->getID($id);  // ?? not sure here ??
        $ds3 =& $this->cacheDao->check($id);  // ?? not sure either ??

        $data =& $ds1->getRow();
        $data['online'] =& $ds2->isConnected();
        $data['cache'] =& $ds3->isCurrent();
        $this->model =& new UserModel($data);
    }

    // ...

    function getListView() {
        $this->view =& new HTMLUserView($this->model);
        return $this->view->getList();
    }

    // ...

} 


---

I'm not too sure about most of this, so it's really just a guess. I'm getting tired, too. Lack of sleep seems analogous to lack of understanding! :o

Peace,
-texdc

Quote:

---

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 :)

Quote:

---

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 ?

:)

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

Quote:

---

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.

---

How do you implement such a Lazy Load? If this is the way to go...

Quote:

---

Originally Posted by Captain Proton again

PHP Code:

---

$db = new DatabaseConnection(...);
$dao = new UserDAO($db);
$user = $dao->find($userID); 


---

---

...then how does $user access the $dao in case it does need to load images? I did try to google for it, but I get only Java results about Virtual Proxies which is more than a just little over my head.

A possible solution is this:

PHP Code:

---

class User
{
    var $dao;
    var $images = null;
    
    function User(&$dao)
    {
        $this->dao =& $dao;
    }
    
    function getImages()
    {
        if ($this->images == null)
        {
            $this->images = $this->dao->loadImages($this);
        }
        
        return $this->images;
    }
} 


---

[Off Topic]

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.

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

http://www.holub.com/publications/ot..._patterns.html

Quote:

---

Originally Posted by Captain Proton

A possible solution is this

---

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

Quote:

---

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' ;-)

I simply could have put the PDF as an attachment myself but that defeats the purpose of site subscription I suppose ?

Plus IMO gives Site Point a bad name at the end of the day, that and I could be banned :D

Can't have that now, can we ? :)

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

Quote:

---

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.

Quote:

---

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.

This PHP code is actually correct:

PHP Code:

---

// Controller 
function getUser($id) { 
$this->model->getUser($id); 
// ... 

// Model 
function getUser($id) { 
$this->dao->getUser($id); 
// ... 

// DAO 
function getUser($id); 
// ... 


---

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.

Quote:

---

Originally Posted by texdc

My host only offers MySQL, and that without BDB or InnoDB type tables. So, I'm stuck doing my joins in PHP.

---

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.

Quote:

---

Originally Posted by texdc

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

---

Quote:

---

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.

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

Quote:

---

Originally Posted by Tony Marston

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.

This is a pretty old thread, too. I think discussion of MVC has become more refined here in the past year since this thread was last active.

Quote:

---

Originally Posted by kuato

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.

Quote:

---

Originally Posted by Version0-00e

... in other words there is more than one way to skin a cat.

---

I quite agree. I have never said that my way is the only way, just that I have found a different way. Too often I am criticised for being different.

Quote:

---

You must not do it *that* way, you must do it *this* way

---

or

Quote:

---

Better people than you have already designed the perfect solution, so what makes you think that you can do better?

---

Just because I dare challenge their arguments and knock them down one by one I am accused of being arrogant, but is not their attitude just as arrogant?