SitePoint Sponsor

User Tag List

Page 1 of 3 123 LastLast
Results 1 to 25 of 57
  1. #1
    SitePoint Wizard Sillysoft's Avatar
    Join Date
    May 2002
    Location
    United States :)
    Posts
    1,691
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Post Help on learning design patten (MVC)

    Finally taking the time to sit down and learn this. Starting with MVC just want to make sure Im getting this. Model, View, Controller; What would be some examples in a application for this? Would model be the layer that interacts with a database? Would view be the page itself and would the controller be a form that the viewer can use to manipulate the model?

    Please excuse the lack of knowledge, just need to know if Im on the right track. Also when designing a application do you go over the different design patterns and decide which is best suited for the situation? Or do you normally stick to one design pattern?

    Silly

  2. #2
    SitePoint Member
    Join Date
    Sep 2003
    Location
    Finland
    Posts
    21
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    One simple rule that I have is that the Model should never print to screen and the View should never read from the database. I think the Controller should do neither.

    So basically you are on the right track. Though between the Model and the database is often another layer, the database abstraction. For MVC learning purposes I think it's enough if you have a Model with the sql queries in it, View with the print( "html" ) in it and maybe just a controller.php with a procedural switch case that reads $_POST["action"], calls the Model class methods as needed and then forwards to an appropriate next page.

    Check out the Advanced PHP Resources list that is as a sticky article on top of this forum, it has some MVC links too.

    Regards,
    SamuliK

  3. #3
    SitePoint Member
    Join Date
    Sep 2003
    Location
    Finland
    Posts
    21
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Sillysoft
    Also when designing a application do you go over the different design patterns and decide which is best suited for the situation? Or do you normally stick to one design pattern?

    Silly
    About this: in a real life application there are bound to be several design patterns in use. Usually design patterns are designed to solve different problems, so it's natural to have more than one if you have more than one type of problems :-)

    For example a simple design pattern by Martin Fowler called Money solves a problem of how to represent money (currency) in a program. So this has nothing more to do with MVC than that they are both design patterns.

    If you mean if there could be MVC and then another, competitive method, of dividing data, presentation and logic... There could be small parts of the application that are just quick 'hacks' (in positive meaning of the word), but it makes things much easier to have the main body of the code to follow MVC the same way.

    Regards,
    SamuliK

  4. #4
    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)
    You might want to look at this thread http://www.sitepointforums.com/showthread.php?t=132437 for some article I wrote on the subject.

    HTH
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  5. #5
    SitePoint Wizard Sillysoft's Avatar
    Join Date
    May 2002
    Location
    United States :)
    Posts
    1,691
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sweatje
    You might want to look at this thread http://www.sitepointforums.com/showthread.php?t=132437 for some article I wrote on the subject.

    HTH
    Thanks reading the article now. Already have questions, what a shock! One question that comes to mind is in the article it states:

    "For models that interact with a database table, a single

    table should ideally be associated with only one

    model class. This helps you to achieve the first goal we

    listed for benefits of the MVC: maintaining your data in

    some kind of persistent data store."


    Maybe Im mis-reading it, but is it saying create a new class for each table, not database, in a database? So if I had 2 tables, table1 and table2, I would then create 2 classes, each one only interacting with that one specific table?


    Silly


  6. #6
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    ...saying create a new class for each table...
    Exactly Martin Fowler seriously recommends this approach btw.

    Absolutely nothing wrong with this at all actually

  7. #7
    SitePoint Wizard Sillysoft's Avatar
    Join Date
    May 2002
    Location
    United States :)
    Posts
    1,691
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    Exactly Martin Fowler seriously recommends this approach btw.

    Absolutely nothing wrong with this at all actually
    So if I have 30 tables in a database then I would need 30 classes? Or I need to better my db layout?

    What does

    name :: name

    Mean when used in a class? I noticed it used after a class that extends another class.

    Silly
    Last edited by Sillysoft; Nov 11, 2003 at 10:08.

  8. #8
    SitePoint Wizard Sillysoft's Avatar
    Join Date
    May 2002
    Location
    United States :)
    Posts
    1,691
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If anyone is interested and if this applies here is a diagram I found that seems to help me a lot now:

    http://matras.marbie.net/mvc.jpg

    Also another question. The article I read stated create one model per table in a database, does the same go for controller? One Controller for each model? Or should it be just one controller that should be able to handle all controls for each model/view?

    With the view, say you had a form for the user to fill out. Would that be put in the view? The end result would be passing the information to the controller which then talks to the model which then updates the view correct? But the form itself, is that put into a view class? Or is that just html in the php file?

    Silly

  9. #9
    SitePoint Enthusiast
    Join Date
    May 2003
    Location
    Poland
    Posts
    89
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Should View interact with Model ?
    In controller i create object and should I pass this object to the View or assign only data (that this object retrieves from database) to the View ?

    "For models that interact with a database table, a single
    table should ideally be associated with only one
    model class. This helps you to achieve the first goal we
    listed for benefits of the MVC: maintaining your data in
    some kind of persistent data store."
    For me it sounds nearly impossible, cause in advanced applications u need to perform JOINS on tables, so how this can be done ?

  10. #10
    SitePoint Wizard Sillysoft's Avatar
    Join Date
    May 2002
    Location
    United States :)
    Posts
    1,691
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by cagrET
    Should View interact with Model ?
    In controller i create object and should I pass this object to the View or assign only data (that this object retrieves from database) to the View ?



    For me it sounds nearly impossible, cause in advanced applications u need to perform JOINS on tables, so how this can be done ?
    But wouldnt it still work because in a JOIN you still grab from one main table right?

    Silly

  11. #11
    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)
    Quote Originally Posted by Sillysoft
    Maybe Im mis-reading it, but is it saying create a new class for each table, not database, in a database? So if I had 2 tables, table1 and table2, I would then create 2 classes, each one only interacting with that one specific table?
    It would depend on how closely related the two tables are. For example, if you had two tables, one for contacts and one for addresses, and you only allowed a contact to have a single address, it would probably be fine to have a contact model with GetAddress() and SetAddress() like methods.

    But as the tables get less related, and the business logic surrounding the table becomes increasingly more complex, it is probably better to make them into separate classes. For example Customer and Orders probably warrent separate classes.

    If you work with a database that allows views, you might consider having the Model class correlated with a single view. The view might join in additional tables, but you are probably expressing a single business process.

    HTH

  12. #12
    SitePoint Wizard Sillysoft's Avatar
    Join Date
    May 2002
    Location
    United States :)
    Posts
    1,691
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sweatje
    If you work with a database that allows views, you might consider having the Model class correlated with a single view. The view might join in additional tables, but you are probably expressing a single business process.

    HTH
    Hmm.. Are you saying you should have one view for each model? Or are you saying for all the models you have you should only have one view altogether?

    Silly

  13. #13
    SitePoint Wizard Sillysoft's Avatar
    Join Date
    May 2002
    Location
    United States :)
    Posts
    1,691
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    So the Controller is just the part that receives any data being passed by the view, prepares it based on whatever, perhaps a if/else statement or a switch, then passes the prepared data to the model which updates all views

    Silly

    Just checking to see if Im getting around the corner here

  14. #14
    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)
    Quote Originally Posted by Sillysoft
    Hmm.. Are you saying you should have one view for each model? Or are you saying for all the models you have you should only have one view altogether?
    Was just trying to say a model could be focused on a view rather than a table.

    The one table = one class is just a rule of thumb, and as Dr. Livingston mentioned, there are others who recommend this, but I think more for creating DAOs.

    I tend to create model classes around conceptual focus, not a table, in practice. This is primarily becuase most of my development is done on an Oracle database, where I do all the SQL as PL/SQL packages. Therefore data access (reads and updates) for the models is just a matter of binding any parameters and calling a function. All the SQL happens inside of the package, and can access as many or a few tables and views as required.

    HTH

  15. #15
    SitePoint Wizard Sillysoft's Avatar
    Join Date
    May 2002
    Location
    United States :)
    Posts
    1,691
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sweatje
    Was just trying to say a model could be focused on a view rather than a table.

    The one table = one class is just a rule of thumb, and as Dr. Livingston mentioned, there are others who recommend this, but I think more for creating DAOs.

    I tend to create model classes around conceptual focus, not a table, in practice. This is primarily becuase most of my development is done on an Oracle database, where I do all the SQL as PL/SQL packages. Therefore data access (reads and updates) for the models is just a matter of binding any parameters and calling a function. All the SQL happens inside of the package, and can access as many or a few tables and views as required.

    HTH
    I understood that after re-reading your post, I guess Im stuck on the view part. If I had a form the html to display that form would be the view right? If so would that be in a view class or jsut pure html in a php file?

    Silly

  16. #16
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    In the Controller Layer in regards to a FORM I first have the Controller check that the FORM has been submitted ?

    If not I set which Template the View should use within the Controller;

    PHP Code:
    .
    ...
    if(!isset(
    $_POST['BasicSubmit'])) {
    $view = new ViewLayer('NotSubmitted.htm');
    } else { 
    // validate user inputs etc etc }
    ...

    The object

    PHP Code:
    $view 
    Would now hold which View to use yes ? Ideally though this could be more complex if you need differing views, ie Screen and Print for example though that's something else altogether and a topic for discussion on another day me thinks

    In regards to Jason's view point of M Fowlers Data Transfer Object I would proberly have to agree with the point Jason made about using it primarlary with DAOs ?

  17. #17
    SitePoint Wizard Sillysoft's Avatar
    Join Date
    May 2002
    Location
    United States :)
    Posts
    1,691
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    In the Controller Layer in regards to a FORM I first have the Controller check that the FORM has been submitted ?

    If not I set which Template the View should use within the Controller;

    PHP Code:
    .
    ...
    if(!isset(
    $_POST['BasicSubmit'])) {
    $view = new ViewLayer('NotSubmitted.htm');
    } else { 
    // validate user inputs etc etc }
    ...

    The object

    PHP Code:
    $view 
    Would now hold which View to use yes ? Ideally though this could be more complex if you need differing views, ie Screen and Print for example though that's something else altogether and a topic for discussion on another day me thinks

    In regards to Jason's view point of M Fowlers Data Transfer Object I would proberly have to agree with the point Jason made about using it primarlary with DAOs ?
    Ok this is where I was confused. Is the controller something you put in a class or is it the page itself (referring to the page you view such as index.php) where you would run the if/else statement? Or could be both?

    Silly

  18. #18
    PHP manual bot bronze trophy Gaheris's Avatar
    Join Date
    Oct 2003
    Location
    Germany
    Posts
    2,195
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If I had a form the html to display that form would be the view right? If so would that be in a view class or jsut pure html in a php file?
    You seperate business logic from display logic but NOT code from display. So your View generates the display with data it can get from the model.

    At least, that's what I with my limited MVC knowledge would say.

    Edit: Sneaky edits, eh?

  19. #19
    SitePoint Wizard Sillysoft's Avatar
    Join Date
    May 2002
    Location
    United States :)
    Posts
    1,691
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    These questions mainly come from PHP Patterns from the MVC2 code Harry did:

    PHP Code:
    <?php
    require_once('lib/DataAccess.php');
    require_once(
    'lib/ProductModel.php');
    require_once(
    'lib/ProductView.php');
    require_once(
    'lib/ProductController.php');
    $dao=& new DataAccess ('localhost','','','');
    switch ( 
    $_GET['view'] ) {
        case 
    "product":
            
    $controller=& new ProductItemController($dao,$_GET);
            break;
        default:
            
    $controller=& new ProductTableController($dao,$_GET);
            break;
    }
    $view=$controller->getView();
    echo (
    "<pre>" );
    // print_r($controller);
    echo ("</pre>" );
    echo (
    $view->display());
    ?>
    This is the index.php file that brings it all together. Now if I break it down to the knowledge I have so far in MVC you would first include the files needed, then use your DAO to open the connection to the db. From there you use a controller to decide which controller class to run based on the information passed from the URL. (This is why I asked if a controller was the index.php itself and also could be a class). In the controller class it accesses the model and the view classes getting the information based on the information passed from the view. Then we display the final outcome which comes from the view class. So what is index.php? Is it the view? Or is it the controller or is it both? Or even neither?

    Silly

  20. #20
    PHP manual bot bronze trophy Gaheris's Avatar
    Join Date
    Oct 2003
    Location
    Germany
    Posts
    2,195
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well if it was a blank form then what would the model be? The html itself?
    The model? The model IMHO hasn't got anything to do with the displaying something. It does the business logic, like modifying and getting database content.

    Edit: Sneaky edits, eh?

  21. #21
    SitePoint Wizard Sillysoft's Avatar
    Join Date
    May 2002
    Location
    United States :)
    Posts
    1,691
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Gaheris
    So your View generates the display with data it can get from the model.
    Edit: Sneaky edits, eh?
    Interesting I delete one post and it deleted the other one. Oh well. No I understand the Model hasnt nothing to do with the display. I was merely looking at your post above thinking if I didnt access any data from a db then what would be my model if it was just a plain form? Which would be there is no model because there is no need to access the model as there is no controller activated from the view

    Silly

  22. #22
    PHP manual bot bronze trophy Gaheris's Avatar
    Join Date
    Oct 2003
    Location
    Germany
    Posts
    2,195
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Nothing I guess. But doesn't a View represent an entire page (mustn't be a webpage, but in this case it is)? Have you got a completly static page? Let's see what the others with the MVC knowledge have to say.

  23. #23
    SitePoint Wizard Sillysoft's Avatar
    Join Date
    May 2002
    Location
    United States :)
    Posts
    1,691
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Gaheris
    Nothing I guess. But doesn't a View represent an entire page (mustn't be a webpage, but in this case it is)? Have you got a completly static page? Let's see what the others with the MVC knowledge have to say.
    Well it wouldnt be static once the user clicks submit. From there though I would assume that this is where the view would pass on to the controller and the controller prepares the data and then pass the data to the model. The model then does the needful and all the views get updated

    Silly

  24. #24
    PHP manual bot bronze trophy Gaheris's Avatar
    Join Date
    Oct 2003
    Location
    Germany
    Posts
    2,195
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    But that would IMHO be a different Controller, wouldn't it? That's something about the MVC pattern that interests me as well, when do I need a new controller and a new model?

  25. #25
    SitePoint Wizard Sillysoft's Avatar
    Join Date
    May 2002
    Location
    United States :)
    Posts
    1,691
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Gaheris
    But that would IMHO be a different Controller, wouldn't it? That's something about the MVC pattern that interests me as well, when do I need a new controller and a new model?
    Well the example above that I gave from Harrys tutorial over at PHP Pattern uses 2 controllers right? The first controller takes the value from the url and does a switch to determine which second controller to use. Correct?

    Check this chart out:

    http://matras.marbie.net/mvc.jpg

    Silly


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
  •