SitePoint Sponsor

User Tag List

Page 3 of 4 FirstFirst 1234 LastLast
Results 51 to 75 of 95
  1. #51
    SitePoint Zealot Sork's Avatar
    Join Date
    Jul 2002
    Location
    Portugal
    Posts
    143
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sweatje
    What is an SQL statement doing in a Controller? IMO, SQL belongs firmly in the Model domain. What if you wanted to change your Model from storing data in a database to fetching it from a web service?
    Agree too, but we can put model logic in controller if we use maverick's controller-as-model pattern, what you think?

  2. #52
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Letting the View have direct access to the Model almost eliminates the need for a Controller. The View is always dependent on the Model, but shouldn't have direct access to it.
    This is the way I see it and as such the way I've done it; The VIEW is passed data to view via the MODEL and thus ignoring CONTROLLER all together.

    Any disadvantages/advantages I wonder ? The MODEL decides which template to use for example...

    Umm...

  3. #53
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    What is an SQL statement doing in a Controller? IMO, SQL belongs firmly in the Model domain. What if you wanted to change your Model from storing data in a database to fetching it from a web service?
    I'd have to agree with this point; The SQL actually belongs in a DAO... Which the MODEL (and only the MODEL Layer) access...


  4. #54
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Any disadvantages/advantages I wonder ? The MODEL decides which template to use for example...
    This decision should be made by the Controller, it's what it's for!

    If you have your Model classes decide what template to use, you are incorrectly layering your application. This will become evident when you try to add another presentation layer, say a SOAP interface to your model classes. You have to adjust the Model classes to choose a 'SOAP template' instead of a regular HTML template. If you had layered the app correctly, it would not be necessary to change the lower layer (model) when a new upper layer (SOAP presentation) is added. That's the purpose of layered design anyway..

    Which the MODEL (and only the MODEL Layer) access...
    In wonder how this idea is transformed into code. Do you have something like this code in your Controller layer?

    PHP Code:
    $db = new DatabaseConnection(...);
    $user = new User($db);
    $user->find($userID); 
    ? If so, compare it with the code below:

    PHP Code:
    $db = new DatabaseConnection(...);
    $dao = new UserDAO($db);
    $user $dao->find($userID); 
    In that piece of code, the Controller accesses the DAO to retrieve Model objects. I think this approach has several advantages:

    - Separation of concerns
    The Model objects are focused on providing access to model data and logic, they do not care about how their data is loaded and saved (which they shouldn't). The loading and saving of model objects is left to the DAO layer.

    - avoid redundant methods
    Methods on model objects such as find(), save() and delete() will be 'passthrough' methods that simply call the same methods on their DAO's. Why have all of these duplicate methods when they can be on the DAO only?

    - The data access layer is replacable
    The same model objects can be used with multiple layers of DAO's, thus multiple data sources. By using an XMLUserDAO class for example, you can load user objects from an xml file, and when using a SQLUserDAO you can load them from a SQL database, etc.. This way the model objects are completely independent of the data access layer (do I hear 'layering' here ? ). But when you do $obj = new MyModelClass($dbc) and the model object instanciates its own DAO, you are limited to one data source.

  5. #55
    SitePoint Zealot
    Join Date
    Jun 2003
    Location
    Elsewhere
    Posts
    107
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sweatje
    What is an SQL statement doing in a Controller? IMO, SQL belongs firmly in the Model domain. What if you wanted to change your Model from storing data in a database to fetching it from a web service?
    You're right of course.... I was having issues with the placement of queries (as they don't belong in the DAO, nor in the controller). Placing them in models offers the most flexibility all round.

  6. #56
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Nice point about the Layering btw Captain Proton

    On the point about changing for a new VIEW though, I'd basically just write out new script for the VIEW Layer all together ? ie In the MODEL Layer, I only create an instance of the VIEW and pass some variables to the VIEW Layer...

    In your post, in my case, the data going to the VIEW, regardless of it being HTML, XML or WAP for example, the data remains the same, no ?

    About the other point though, I use the 2nd option as well...

  7. #57
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    On your point near the end about using more than one Dao I create one instance of mySQL for example from the CONTROLLER and pass this through to the MODEL; The Daos are all in a folder - mysql-daos - now the class instance is created via a DEFINED variable, ie mysql-db ?

    If I need to change to PostgreSQL for example, I only need to change the DEFINED variable, ie postgre-db and then INCLUDE the required folder which holds the Daos for this specific database, if you follow ?

    Likewise then for other sources, ie XML no ?

    Umm...

  8. #58
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    On the point about changing for a new VIEW though, I'd basically just write out new script for the VIEW Layer all together
    yes If you've designed the model layer correctly, it should not have to be changed when a new type of presentation (View layer) is added.

    Quote Originally Posted by Azmo
    Placing them in models offers the most flexibility all round.
    I disagree, because I think that model objects should not have to care about how their data is loaded and saved. Queries should definitely not be placed in the Model layer, the purpose of a DAO is to encapsulate these queries. They'd even be better off inside the contoller layer than in the model layer.

    Quote Originally Posted by sweatje
    IMO, SQL belongs firmly in the Model domain. What if you wanted to change your Model from storing data in a database to fetching it from a web service?
    Just to make something clear, a model is not about the way data is stored physically (i.e. on a database server), it is about describing the structure and logic of model data according to the problem domain of an application. If you separate Model objects and DAO's like I mentioned before, changing from fetching data from a webservice instead of fetching it from an SQL database is simply a case of writing a new DAO. The model classes should not have to be changed just because the data storage mechanism is changed.

  9. #59
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I disagree, because I think that model objects should not have to care about how their data is loaded and saved. Queries should definitely not be placed in the Model layer, the purpose of a DAO is to encapsulate these queries.
    I have to agree with this point, as with the following point you've also made...

    ... If you separate Model objects and DAO's like I mentioned before, changing from fetching data from a webservice instead of fetching it from an SQL database is simply a case of writing a new DAO. ...
    On the point previously to my MODEL create an instance of the VIEW Layer's template, I'll be changing this again since your point is valid

    Okay, it'd only ever be something like 2 lines of script, but it's still having to change the MODEL Layer...

    Which kind of brings me to the idea of the much discussed Page Controller ? Idea everyone ?

  10. #60
    SitePoint Member
    Join Date
    Nov 2002
    Location
    here
    Posts
    16
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I've been rewriting my code based on the input and recommendations I've received here and have another question concerning the Model.

    In my user table I have foreign keys to the ip and authorization tables. As I understand things, the user model is not complete without the information from these related tables. We've talked about joins before, but let's extend this for the purpose of my question.

    Say I wanted to allow each user to have 2 images: a thumbnail and a signature. So, I include 2 more foreign keys in my user table: thumb_id, and sig_id. The image info is, again, broken down into 2 more tables: images and image_types. Images holds the columns for primary key, file_name, type_id, date_added, and date_modified. Image_types holds the columns for primary key, type_name, width, height, and directory. It seems apparent to me that the images should get their own model (model things in the real world).

    Now, my question is: If the user model is incomplete without all this foreign information, who instanciates the ImageModel class? The UserModel, the UserController, somewhere else, or not at all? I can handle hacking together something that will work, but I'm concerned about doing things the right way, rather than just getting it going.

    Thanks again!
    -texdc

  11. #61
    SitePoint Member
    Join Date
    Nov 2002
    Location
    here
    Posts
    16
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Just to chime in on the current state of this thread:

    SQL goes in the DAO.
    The Controller decides what DAO to use.
    The Controller decides what View to use.

    Doing things any other way seems to complicate things and reduce abstraction and reuse.

    -my $.02!
    Last edited by texdc; Jul 20, 2003 at 18:56.

  12. #62
    SitePoint Member
    Join Date
    Nov 2002
    Location
    here
    Posts
    16
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Here's a good 'intro to MVC' read:
    New Architect

  13. #63
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Now, my question is: If the user model is incomplete without all this foreign information, who instanciates the ImageModel class? The UserModel, the UserController, somewhere else, or not at all? I can handle hacking together something that will work, but I'm concerned about doing things the right way, rather than just getting it going.
    The UserDAO should instanciate ImageModel objects. There are two patterns for coding this: loading ImageModel objects onto UserModel objects on construction by the DAO, or loading them on them demand.

    In the first pattern, when the findByID($userID) method of the UserDAO is called, it executes a select query to find that user, creates a user object, sets its parameters (such as username, password, etc), then executes a query to get images, creates ImageModel objects and calls something like a setImages() method on the UserModel. Consequence of this method is that at least two queries are executed to load a UserModel, while the loaded ImageModel objects may not even be needed by the Controller.

    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.

    If in most of the cases when you use a UserModel object you also need to access its ImageModel objects, the first pattern is probably easier to use. But if in most of the cases you do not need access to the ImageModel objects of a UserModel, use the second pattern to cut down object loading times.

  14. #64
    SitePoint Member
    Join Date
    Nov 2002
    Location
    here
    Posts
    16
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Cpt. Proton:

    Thanks for clearing that up for me! Much appreciation!

  15. #65
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    SQL goes in the DAO.
    The Controller decides what DAO to use.
    The Controller decides what View to use.
    Not quite there yet ? It is the CONTROLLER that selectes the MODEL Layer and from there, it's the MODEL Layer that uses the Daos... From the MODEL Layer; not the CONTROLLER Layer.

  16. #66
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    TexDc -

    Your Link:

    ... The control.asp file serves as Controller, and as an entry point to the entire application. By providing different commands and documents, this simple script reads the document data and passes control to the appropriate View. ...
    Am I the only one who has noticed the point above ? The author states that the CONTROLLER chooses the VIEW correct ?

    Is it not the MODELs job to select the appropriate VIEW... no ?

    I would assume that it is; no wonder MVC is difficult to learn and use if there are informed statements like this one above...

    Umm...

  17. #67
    SitePoint Zealot Sork's Avatar
    Join Date
    Jul 2002
    Location
    Portugal
    Posts
    143
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    Not quite there yet ? It is the CONTROLLER that selectes the MODEL Layer and from there, it's the MODEL Layer that uses the Daos... From the MODEL Layer; not the CONTROLLER Layer.
    One says one thing the other another confusing...

  18. #68
    SitePoint Addict
    Join Date
    Aug 2002
    Location
    Ottawa, Ontario, Canada
    Posts
    214
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    TexDc -

    Your Link:



    Am I the only one who has noticed the point above ? The author states that the CONTROLLER chooses the VIEW correct ?

    Is it not the MODELs job to select the appropriate VIEW... no ?

    I would assume that it is; no wonder MVC is difficult to learn and use if there are informed statements like this one above...

    Umm...
    My perspective has always been the controller picks the model and the controller picks the view (which to me also explains why MVC is usually drawn as a triangle... If it were C -> M -> V Well... then we could draw it as a straight line

    One way I have modelled it in the past is (this is simplistic), Controller calls Model, Model does its stuff, returns data to the controller which then passes the data to the appropriate View.... The Model has no need to "know" anything about the View....

    Cheers,
    Keith.

  19. #69
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr. Livingston
    Not quite there yet ? It is the CONTROLLER that selectes the MODEL Layer and from there, it's the MODEL Layer that uses the Daos... From the MODEL Layer; not the CONTROLLER Layer.
    I guess it is a preference whether the Model layer uses the DAOs or the Controller has access to DAOs to, but like I pointed out in post #54 of this thread, the Controller instead of the Model accessing DAO's has several advantages.

    Quote Originally Posted by Taoism
    One way I have modelled it in the past is (this is simplistic), Controller calls Model, Model does its stuff, returns data to the controller which then passes the data to the appropriate View.... The Model has no need to "know" anything about the View....
    I have nothing to add

  20. #70
    SitePoint Zealot codezilla's Avatar
    Join Date
    Nov 2002
    Location
    upstairs
    Posts
    110
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    Not quite there yet ? It is the CONTROLLER that selectes the MODEL Layer and from there, it's the MODEL Layer that uses the Daos... From the MODEL Layer; not the CONTROLLER Layer.
    My understanding is that the Controller decides what Model objects are needed. It then instantiates the necessary Model object(s) using the appropriate DAO(s):

    PHP Code:
    $dao =& new UserDao();
    $user =& $dao->findForId($_GET['uid']); 
    Then the Controller can hand off the Model (i.e. the instantiated Model objects) to the View.

    Quote Originally Posted by Dr Livingston
    Is it not the MODELs job to select the appropriate VIEW... no ?
    No, that is the Controller's responsibility. In fact, that's why the concept of a Controller is so useful, it allows you to easily use different Views for the same Model. The only decisions made by the Model are business decisions (i.e. business logic). The Model/View separation is the exact same thing as the business logic/presentation separation.

  21. #71
    SitePoint Member
    Join Date
    Nov 2002
    Location
    here
    Posts
    16
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    Am I the only one who has noticed the point above ? The author states that the CONTROLLER chooses the VIEW correct ?

    Is it not the MODELs job to select the appropriate VIEW... no ?
    Umm...why would the Model choose the View? It's hard for me to think of a reason why the Controller should not handle deciding which View to use. It's the object that gets the command from the client, anyhow.

    Also, concerning DAOs and Models: It has already been stated in this thread that a DAO is NOT part of the MVC pattern. However, a DAO (Data Access Object) is directly related to the Model. As has been noted, both the method and the origin of the Model's data can change, and that is why it's a good idea to abstract the data acquisition specifics out to a DAO. Therefore the DAO and the Model are instrinsically linked, as the Model relys upon the DAO to populate itself with data.

    I recently asked a friend of mine about Models, DAOs, and MVC. He said that because Models contain data transformation logic in addition to the raw data, it could be advantageous to just pass a Data Container Object (DCO) to the View. As I have mentioned before, this is my approach. My DCO is simply a 'result' object that is generated by the DAO.

    Hence: Model = DAO + DCO; Of course, many people combine both variables(data) and functions(logic) in one object. But, as described above there are advantages for abstracting the data and the logic.

    Now, who decides which DAO to use? Seeing as the DAO is part of the Model, the Controller should decide. After all, when the Controller is instanciated, it's passed a link, or connection, to the data storage layer which has been pre-determined somewhere else in the app, perhaps a 'config' file, etc. (In the examples that have been used here $dbc is a Database Connection). The Controller should then, in a complex app, use the Strategy pattern to determine which DAO to use based on the kind of connection it received. Otherwise, you have a connection passed to a Controller, which in turn, passes that connection to the Model. Why not just keep that connection in the Controller and let it do it's job of deciding who does what with whom?

    Does any of this make sense?

    Peace,
    -texdc

  22. #72
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Codezilla -

    No, that is the Controller's responsibility. In fact, that's why the concept of a Controller is so useful, it allows you to easily use different Views for the same Model.
    Interesting way you've described it

    TexDC -

    Like the idea of a DCO; Sounds much like passing back to the CONTROLLER an array of objects no ?

    Looks like I have some more reading and studying to do yet before I get the hang of MVC...

    Umm... Okay folks, thanks for making your points of which I'll be back to this thread again - that much is a certainty anyways

  23. #73
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    To date, I have not applied the concept of DAO in my PHP programming. Based on this thread, I am trying to understand how they might apply to one of my "typical" MVC framework projects.

    Several people have pointed out the Controller should select the type of DAO to use (is there then a DAO factory to churn out concrete DAOs?)

    In my conception of a Controller, it should be directing applicaiton flow, and the Model should know where to access it's data, so this concept of the Controller deciding which DAO to use seems foriegn to me.

    For example, what if you are monitoring usage of a web site. The individual users are stored in an LDAP repository, therefore requring an LDAP flavor of a DAO to get at the data. However, page hit status (trends of pages hit over time) might be stored in a relational database, requiring a db flavor DAO to access this information.

    I might concieve of this as all wrapping into a WebUser Model that knew the right access functions to retrieve for GetName() and GetStats() methods. I guess if you have the Controller making the DAO type selection, then you would have to make two different models, perhaps WebUser and WebUserStats?

    Am I off base here?

  24. #74
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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 ?

  25. #75
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think it is fairly typical for my models to have more than one persistant data source. e.g. User has data like id, password, name in the db, and state (isLoggedIn) in the $_SESSION.

    Many of my pages are summaries of SQL aggregate queries than can take several minutes to run, I then cache the results to a file. So now I have a model that talks SQL to the DB for the RefreshData() method, but also writes to a file (which would be another DAO?) to cache the result. The GetData() method would check for the existance of the cache (file based) of fall back to the SQL query (db based).

    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?

    Thanks.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •