SitePoint Sponsor

User Tag List

Page 2 of 4 FirstFirst 1234 LastLast
Results 26 to 50 of 95
  1. #26
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I want to avoid passing the model itself to the view completely to keep them ignorant and separate.
    Um, Here is a diagram of MVC dependencies:
    Code:
                     +--+
                     +--+---------+
                     | Controller |
                     +------------+
                     /            \
                    /              \
                   /                \
                  /                  \
          +--+   \/             +--+ \/
          +--+---------+        +--+---------+
          |    Model   | <----- |   View     | 
          +------------+        +------------+
    Note that these are packages (groups of classes), not classes.

    MVC applies the Dependency Inversion Principle. The controller is a high level package and thus may freely call the other two packages. The controller is dependent on the other two classes. The Model is a low level package and thus may not have dependencies on the other two packages. The View is dependent upon the model, but not the controller. (See Principles of Object Oriented Design for a list of types of dependencies.

    If you need to communicate "against the grain" then you would use the Hollywood Principle to allow communications without creating dependencies.

    For example, the model could communicate to the view that data has changed and that the view needs to be refereshed. To do this, it would issue a data changed event which the view would listen to. Since the model has no idea what kinds of objects are listening to its events, the pattern of dependencies is preserved, even though there is communication to the view originating in the model. It might be the controllers responsibility (being at the highest level) to pick the correct view to register to listen to the model.

    Traditionally, the controller is responsible for managing input. (In a PHP web app, this means that the controller classes would be the only ones with access to the $_GET, $_POST, etc arrays.

    So, input goes in the controller package, output goes in the view package, and business logic goes in the model package.

    The controller also acts as a mediator between the other two classes. Sometimes, you might want to split the controller up. You might also want to split up the model to encapsulate database access into its own package.

    Code:
                     +--+
                     +--+---------+
                     | Controller |
                     | (input)    |
                     +------------+
                            /\
                             |
                     +--+    |
                     +--+---------+
                     | Controller |
                     | (mediator) |
                     +------------+
                     /            \
                    /              \
                   /                \
                  /                  \
          +--+   \/             +--+ \/
          +--+---------+        +--+---------+
          |    Model   | <----- |   View     | 
          +------------+        +------------+
                 |
                 |
         +--+   \/
         +--+---------+
         | Database   |
         +------------+
    The advantage is flexibility: if you need to output in a different format (say XML instead of HTML), swap in a different view. If you need to support application scripting, swap in a different input controller. If you need to support a different database, swap in a different database package.

    The model, as the holder of the application (business) logic cannot be swapped out. You cannot swap out a Web Store model for a Web Log model in an application. You could swap out a MySQL implementation of a Web Store model for an Oracle implementation of a Web Store model. People develop persistence layers to avoid having to make any model swap at all when they want to make this kind of implementation change.

    Note that being at highest level, the mediating controller will probably have to change no matter what types of changes you make to your application.

  2. #27
    SitePoint Member
    Join Date
    Nov 2002
    Location
    here
    Posts
    16
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    All this discussion about (R)DBMS and where to put JOINs and other logic is a fine and good, but it does not help my present situation.

  3. #28
    SitePoint Addict
    Join Date
    Aug 2002
    Location
    Ottawa, Ontario, Canada
    Posts
    214
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by MattR
    But it's the right one.
    It depends, really, on your definition of 'business rules', but these people are wrong.
    Once again, they aren't wrong. They merely have a different perspective than you do. Applications come in many forms and to make a blanket statement that the insertion of business logic in the database is the only "right" way is not productive.

    Here is a quote from IBM:
    More background about business rules

    A major trend happening in object-oriented application development is the separation of business logic from data access and application logic: the same business logic may be used in multiple applications, and should be changeable rather than being buried and intertwined with data and application specific functions.

    Rules as a way to specify business logic has the advantage of combining automatic executability with a relatively high level of human understandability, i.e., a high conceptual level and a "declarative" (rather than only procedural) semantics. The latter enables non-programmers, especially business-domain experts such as marketing managers, to specify business rules, and to modify them relatively easily and often.
    The quote is part of an overview of their CommonRules Java library.

    Don't get me wrong. I appreciate your perspective on moving the logic/rules into the database, and indeed I do this almost all the time myself. I just don't like the idea of dismissing something like business rules being external to the database as "wrong".

    Cheers,
    Keith.

  4. #29
    SitePoint Member
    Join Date
    Nov 2002
    Location
    here
    Posts
    16
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Selkirk,

    I've seen these diagrams before and am not ignoring them. What I am concerned with is passing the actual model to the view and then the view calling:
    PHP Code:
    $this->model->delete($id); 
    Now, obviously, a view should never do that, but in PHP it is entirely possible. Therefore, I intend on passing the result object generated by the DAO, as that will have all the data that the view needs, without having access to the model's functions.

  5. #30
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Composite is aggregating objects, so if you pass a model to a view and use them together, you are using a form of the Composite design pattern
    I assume you have not read the Design Patterns book, otherwise you would not describe the Composite pattern like that. I think you're confusing it with object composition.

    [url=http://www.javaworld.com/javaworld/jw-09-2002/jw-0913-designpatterns.html[/url]

  6. #31
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by texdc
    Selkirk,
    PHP Code:
    $this->model->delete($id); 
    Now, obviously, a view should never do that, but in PHP it is entirely possible. Therefore, I intend on passing the result object generated by the DAO, as that will have all the data that the view needs, without having access to the model's functions.
    You might consider removing the offending delete function from the interface that the model presents to the view.

    right off hand, I can think of two ways to do this:

    1.) Pretend it doesn't exist. Use mental discipline to erase the possibility. Don't underestimate this approach.

    2.) Move the forbidden method onto a different class, such as a helper class that is still considered part of the model layer, but does not get exposed to the view.

  7. #32
    SitePoint Zealot
    Join Date
    Oct 2002
    Posts
    158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sweatje
    But you just described it in action in your prior statement [img]images/smilies/wink.gif[/img] Composite is aggregating objects, so if you pass a model to a view and use them together, you are using a form of the Composite design pattern [img]images/smilies/smile.gif[/img]
    haha nice.

  8. #33
    SitePoint Zealot
    Join Date
    Oct 2002
    Posts
    158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Selkirk
    1.) Pretend it doesn't exist. Use mental discipline to erase the possibility. Don't underestimate this approach.
    This was my choice in the end!

  9. #34
    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 shoebox
    haha nice.
    As Captain Proton pointed out earlier, I mis-stated that some, what you described was actually the pure OOP concept of object composition, i.e. objects using objects, where as "The" Composite Design Pattern is a more specific use of objects in a tree to model a partial hierarchy.

  10. #35
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi.

    Quote Originally Posted by MattR
    But it's the right one.
    I assume this is a troll...

    This is so old it's becoming boring. When the competition was from Cobol and C, relational databases were an easy choice. Nowadays we write applications an order of magnitude faster.

    The problem with SQL as it currently stands (until they add CREATE TYPE...) is poor encapsulation. In short schema changes cause near panic. You can mitigate this with views and triggers while the apps change, but pretty soon you give in and start building stored procedures and have the apps. talk to them. What you then effectively have is a three tier app, except that the middle tier, rather than being domain objects in a modern OO language, is written in 1970s SQL stored procedures . The procedures themselves are still highly sensitive to the schema. A bad combination for frequent changes to the business rules, disaster if those business rules get tangled.

    Another problem is that your data does not always come from relational sources. We have data from full-text engines, DBM file caches and real time search engine data. How do your stored procs. deal with that?

    If the business rules change little, the bulk of the data is relational and the datamodelling skills are available then RDBMSs are the way to go every time. You will win on performance too. If the rules change frequently (the norm in my game), you get data from different places and you have OO expertise then skip the stored proc. black hole and jump straight to the OO domain. You will in the end anyway.

    You are inadvertently demonstrating a current sickness in the industry, which is lack of communications between the DBAs and OO developers. I don't include you in this of course (you are making positive efforts to go in both directions), but blind parroting of the Pascal and Date bibles is missing an opportunity. At least Scott Ambler and the ThoughtWorks people are making an effort to cross this bridge.

    yours, Marcus.
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  11. #36
    SitePoint Zealot
    Join Date
    Oct 2002
    Posts
    158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by texdc
    Selkirk,

    I've seen these diagrams before and am not ignoring them. What I am concerned with is passing the actual model to the view and then the view calling:
    PHP Code:
    $this->model->delete($id); 
    Now, obviously, a view should never do that, but in PHP it is entirely possible. Therefore, I intend on passing the result object generated by the DAO, as that will have all the data that the view needs, without having access to the model's functions.
    So why not just pass the view to the model instead?

  12. #37
    SitePoint Member
    Join Date
    Nov 2002
    Location
    here
    Posts
    16
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by shoebox
    So why not just pass the view to the model instead?
    Well, I'd end up with the same situation. Basically, as I understand it, the Controller should 'manage' the Model & View(s) by grabbing the data from the Model that the View needs and passing that over to the View. 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.

    Hmmm...This is starting to sound like a pattern...Message, perhaps?

  13. #38
    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 texdc
    Hmmm...This is starting to sound like a pattern...Message, perhaps?
    Seems like what you want is for the Controller to have the Mediator Design Pattern to grant Views appropriate access to Models. (Althought this seems like an overly complicated abstraction to me, I fall in the camp of those just saying "I won't use any method that doesn't say "Get...()" in my view classes" is sufficient)

    I know that all of your examples show "model" as a single class, but all of my real projects invariably have many "Model" classes, and sometime views have a need to access data from several of these model classes in order to render.
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  14. #39
    SitePoint Member
    Join Date
    Nov 2002
    Location
    here
    Posts
    16
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sweatje
    I know that all of your examples show "model" as a single class, but all of my real projects invariably have many "Model" classes, and sometime views have a need to access data from several of these model classes in order to render.
    So, for instance, would you use a User model and a Group model, combining the two with the controller and then passing that to the View? Or, would you just pass both to the View?

  15. #40
    Database Jedi MattR's Avatar
    Join Date
    Jan 2001
    Location
    buried in the database shell (Washington, DC)
    Posts
    1,107
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Taoism
    Once again, they aren't wrong. They merely have a different perspective than you do. Applications come in many forms and to make a blanket statement that the insertion of business logic in the database is the only "right" way is not productive.
    Oh, come on. Blanket statements are fun!

    But, until the term "business logic" (is that different from "business rules"?) is defined we might as well be talking apples and oranges.

    Again, I'm not talking about a database -- but a relational database management system. The two are very, very different things.

    I just don't like the idea of dismissing something like business rules being external to the database as "wrong".

    Cheers,
    Keith.
    I see nothing wrong with "calling out" ideas/people/things. Again, we've never settled on what, exactly, business rules (or logic?) are, so it's difficult to say. But generally it is best to keep them in the DBMS.

  16. #41
    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)
    My models act effectively as singletons, so I do not even pass them to my View subclass, I simply create a new instance of each required model and extract the required data to render the view. I might have to change this approach if my models carried some state information independant of the persistant data store, but I have not encountered that thus far.

    To elaborate a bit, say you have a User model, with GetName and SetName methods. Normally a view would use GetName to display a greeting message. On a user preferences page, you allow the user to modify their name. The way I set up a MVC application, the user preferences page would post data to the front controller with an indication that you want to perform the "user update" action. This Action subclass (within the Controller) would perform the SetName() method based on the posted data. At the end of the action, I would redirect the user, say back to the front controller page with an indication to display the view "User Preference" page again so the user could see the results of their changes. The View class that displays "User Preference" would only call the User::GetName() method to display the value. Only the contoller accessed the User::SetName() method.

    HTH

  17. #42
    Database Jedi MattR's Avatar
    Join Date
    Jan 2001
    Location
    buried in the database shell (Washington, DC)
    Posts
    1,107
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    Hi.
    I assume this is a troll...
    Me, too.

    This is so old it's becoming boring. When the competition was from Cobol and C, relational databases were an easy choice. Nowadays we write applications an order of magnitude faster.
    RDBMSs are not about speed. There is nothing in the relational model that involves performance in any fashion. They're about logical data independence, rules, integrity, etc.

    The problem with SQL as it currently stands (until they add CREATE TYPE...) is poor encapsulation.
    There are lots of problems with SQL. IBM wanted to use it instead of Codd's R language (and I see why, but...) and so now we end up with this mess we're in now.

    In short schema changes cause near panic. You can mitigate this with views and triggers while the apps change, but pretty soon you give in and start building stored procedures and have the apps. talk to them. What you then effectively have is a three tier app, except that the middle tier, rather than being domain objects in a modern OO language, is written in 1970s SQL stored procedures . The procedures themselves are still highly sensitive to the schema. A bad combination for frequent changes to the business rules, disaster if those business rules get tangled.

    Another problem is that your data does not always come from relational sources. We have data from full-text engines, DBM file caches and real time search engine data. How do your stored procs. deal with that?
    Stick it in the DBMS then. But seriously, I'm not saying you can't have logic outside the DBMS (most DBMSs that I know don't have UI languages, etc.) -- but if the data is in the DBMS it’s better to keep the rules as close to the data as possible.

    Of course, SQL DBMSs are flawed implementations of the relational model, so I see why people have taken to storing them outside of the DBMS (because SQL sucks for a significant number of non-trivial things). I don’t disagree with products like the IBM rules system – however we all would be better off if IBM made it an integral part of their DB2 product.

    I suppose it comes down to declarative constraints are ‘better’ than procedural ones. They’re less buggy, easier to understand, faster to write/maintain, etc. That’s why I advocate stored procedures instead of external procedural code because you’re generally writing declarative code (SQL statements) and the application can’t mess it up.

    If the rules change frequently (the norm in my game),
    Then they're not really rules, are they?

    You are inadvertently demonstrating a current sickness in the industry, which is lack of communications between the DBAs and OO developers. I don't include you in this of course (you are making positive efforts to go in both directions), but blind parroting of the Pascal and Date bibles is missing an opportunity. At least Scott Ambler and the ThoughtWorks people are making an effort to cross this bridge.

    yours, Marcus.
    Sickness? I call blind devotion to OO development and ‘agile’ methodology without rationale a sickness. I call a lack of understanding of fundamentals a sickness. I call intellectual laziness a sickness.

    I work on both sides of the fence, and appreciate OO development. I have a bad taste in my mouth from Java and .NET because I have to do stupid things like myVar.ToString() before I can print it out. I think it’s silly to have to say if( foo.ComparesTo( bob.getValue() ) ) instead of if( foo == bob ). It further sickens me to see people writing PHP libraries to emulate this crack-induced insanity.

    What opportunity? Instead of re-inventing the wheel (poorly, I might add) I’d rather people understand what they are doing wrong – and this takes work and understanding of what they are fundamentally doing. And as we all know, most people are lazy and don’t want to take the time to do it. They read horrible articles on XML ‘based’ systems and think that this must be the OneTruePath and adopt it without knowing if, or why, they really should.

    But, this is all very OffTopic. Mods care to split this off and make a new topic?

  18. #43
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well, I'd end up with the same situation. Basically, as I understand it, the Controller should 'manage' the Model & View(s) by grabbing the data from the Model that the View needs and passing that over to the View. 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.
    Since 'the Model' is such an abstract concept (it is to me), not letting the View directly access the Model is even more confusing and abstract. Face it, View objects need to access model data somehow to display that data. The easiest way to give View objects access to this model data is, in an object-oriented application of course, by passing some sort of object that 'models' )) the Model data to the View object.

    "But does this not mean that the View is accessing the Model directly?" Like I said, the View needs to access the data somehow and using this method, that data is stored in an object. It's evident that there is a tight relation between the View and the Model object: the View depends on the Model object (the reverse should not be true). You might think that you can loosen this relationship between the View and Model by giving the View access to the Controller only, which would have get*() methods which access respective values from the Model. But this would lead to a lot of redundant methods wihout adding any value IMHO.

    There will always be a tight relationship between view and model: if the model's structure and logic ('m not talking about the data) changes in some way, it's likely that the view will have to be changed as well to reflect this change. Therefore I think it's no use abstracting the relation between them by introducing the Controller as some sort of intermediate object.

    Letting the View have direct access to the Model almost eliminates the need for a Controller.
    This could be the case if you would need to create a script for simply displaying data, not modifying that data in any way. I can see what you mean that there is little use for a Controller in such a case, but that's not entirely true. The View should only be worried about displaying some model data, it should not care how that data is loaded. It could be loaded from a relational database, a flat file, an XML file, a SOAP request, who cares (the View certainly shouldn't ). This is a good kind of logic to put in the Controller. The Controller should load an object representing a part of the application's Model from a data source (DB, XML, etc) and then pass that object to the View object. Is that a nice abstraction and loose coupling between data source and View or what

    If you're still having doubts about the usefullness of Controllers, I believe that their real usefullness is in manipulating the Model. In PHP apps, this almost always means that the user fills in a form, which is then validated and the data is saved to the application's model. Form Validation is well suited to the Controller, whose task is after all to react on user input (in this case by validating the form).

    Below is my view on what tasks should be the responsibility of which objects when applying MVC to PHP. Everybody seems to interpret MVC in PHP differently, and this is of course only one of those interpretations:

    - Model
    Model is an abstract concept, but in an OO app I believe it can be described as the objects resembling the data and rules of what the application is used for. In typical PHP applications model objects will generally be data objects. These data objects do not have to be responsible for persisting their data, this can be left to other objects, another 'tier' or 'layer'.

    - Controller
    I believe that in PHP applications Controllers should be the entry point to an 'action' or 'task' of an application. For example, think of editing a user', 'deleting a news item', 'viewing statistics' as distinct actions or tasks, each of them should have its Controller. The Controller's tasks for 'editing a user' would be the following:
    - loading an object representing Model data
    - altering the state of that Model object, usually by calling setPropertyX(), setPropertyY() methods
    - depending on the success of the altering of the Model's state (this could fail, because of a duplicate username for example), choose which View object should be displayed. In this case the view displayed for 'success' could be a View that says 'User added' and then redirects. The View displayed for failure would display the form for editing the user data again.
    - for the success View, pass the object that represents the model data (in this case a User object of some sort) to the View's constructor.

    - View
    View is also an abstract concept. The View is usually some sort of object that renders HTML. View objects should have a constructor that accepts some sort of model data object. The View can then call getPropertyX() and getPropertyY() methods to access data from the model object and prepare that data for display.

    Of course this is my interpretation of a pattern that nobody seems to have a solid definition for, when applied to the web. I'd be happy to hear any comments and/or questions

  19. #44
    SitePoint Member
    Join Date
    Nov 2002
    Location
    here
    Posts
    16
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Captain Proton
    Since 'the Model' is such an abstract concept (it is to me), not letting the View directly access the Model is even more confusing and abstract. Face it, View objects need to access model data somehow to display that data. The easiest way to give View objects access to this model data is, in an object-oriented application of course, by passing some sort of object that 'models' )) the Model data to the View object.
    No argument here. I think we may have a matter of semantics, due mostly to my lack of experience and understanding in this area.

    Previously, I have mentioned passing a 'query' object to the View. That should really be called a 'result' object, as the Dao sends the db an SQL query and instanciates an object that holds the response of that query from the db. (I'll be using the Eclipse lib) I suppose this 'result' object would then be the Model. In which case, the Model would be passed directly to the View. This also eliminates my concerns about the View having access to unecessary functions, as the 'result' object only has a few functions: getRow(), count(), reset(), etc.

    Now that I've written that out and think about it, I believe I may understand what to do and where everybody's been coming from. My appologies for my confusion. How does this look?:

    PHP Code:
    class Controller {
        var 
    dao;
        var 
    model;
        var 
    view;

        function 
    Controller(&$dbc$ref) {
            
    $this->dao =& new Dao($dbc);
            
    $this->model =& $this->dao->get($ref);
            
    $this->view =& new View($this->model);
        }

    Sorry if this is so simple. Everything seemed to click all of a sudden!

    Thanks!
    -texdc
    Last edited by texdc; Jul 17, 2003 at 13:15. Reason: I left out a little explanation at the bottom.

  20. #45
    SitePoint Zealot
    Join Date
    Oct 2002
    Posts
    158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by texdc
    Well, I'd end up with the same situation. The View is always dependent on the Model, but shouldn't have direct access to it.
    I dont see how you would end up in the same situation.

    PHP Code:
    $view = New View;
    $model = New Model;
    $model->render($view); 
    There is no chance of running methods belonging to the Model from the View in this scenario. Here, the View still remains dependent on the Model but does not have direct access to it.

  21. #46
    SitePoint Zealot
    Join Date
    Jun 2003
    Location
    Elsewhere
    Posts
    107
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I'm using the following construction for my current project:

    PHP Code:
    class SomePageController {
        var 
    dbc;
        var 
    user_model;
        var 
    other_model;
        var 
    view;

        function 
    SomePageController(&$dbc) {
            
    $this->dbc =& $dbc;
        }

        function 
    Show() {
     
            
    $user_query 'SELECT * FROM user_table';
            
    $this->user_model =& new UserModel$this->dbc );
            
    $user_data $this->user_model->GetData$user_query );

            
    $other_query 'SELECT * FROM other_table';
            
    $this->other_model =& new OtherModel$this->dbc );
            
    $other_data $this->other_model->GetData$other_query );

            
    $this->view =& new View();
            
    $this->view->AddData'user'$user_data );
            
    $this->view->AddData'other'$other_data );

            
    $this->view->Display'some_page' );
        }

    The application layer above the controllers decides which controller to instantiate, based on the incoming request.
    PHP Code:
    $database = new MySQLModel$db_config_data );
    $database->Connect();

    if ( 
    'some_page' == $_GET['page'] ) {
        
    $controller =& new SomePageController$database );
        
    $controller->Show();

    Of course, this is only a simplified representation.

  22. #47
    SitePoint Zealot
    Join Date
    Oct 2002
    Posts
    158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Captain Proton
    It's evident that there is a tight relation between the View and the Model object: the View depends on the Model object (the reverse should not be true).
    I would like to clarify, just in case someone misunderstands.
    When you pass a View to a Model (rather than the opposite) you are not changing the dependancy at all - only the actual inheritence scheme.


    if the model's structure and logic ('m not talking about the data) changes in some way, it's likely that the view will have to be changed as well to reflect this change.
    Indeed

    If you're still having doubts about the usefullness of Controllers, I believe that their real usefullness is in manipulating the Model.
    Or even the view perhaps. There are times when i want to manipulate the results shown in a view without doing anything to the model.

    Form Validation is well suited to the Controller, whose task is after all to react on user input (in this case by validating the form).
    I think it really depends on what pattern you use for your DataModels. Is there something significantly wrong with triggering validation errors when you use the set methods in your model? I haven't tried this yet, but I can't foresee any problems with doing it.

    - View
    View is also an abstract concept. The View is usually some sort of object that renders HTML.
    Not just HTML, any form of output; XML, Text, JPG, PNG, etc..

  23. #48
    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 Azmo
    PHP Code:
            $user_query 'SELECT * FROM user_table';
            
    $this->user_model =& new UserModel$this->dbc );
            
    $user_data $this->user_model->GetData$user_query ); 
    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?

  24. #49
    SitePoint Zealot
    Join Date
    Oct 2002
    Posts
    158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by texdc
    (I'll be using the Eclipse lib) I suppose this 'result' object would then be the Model. In which case, the Model would be passed directly to the View. This also eliminates my concerns about the View having access to unecessary functions, as the 'result' object only has a few functions: getRow(), count(), reset(), etc.
    yes it does

    My parent View class hase become a direct child of RowLoopManipulator

  25. #50
    SitePoint Zealot
    Join Date
    Oct 2002
    Posts
    158
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sweatje
    What is an SQL statement doing in a Controller? [img]images/smilies/confused.gif[/img] 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?
    Agreed.. what would be the purpose of the model otherwise?


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
  •