SitePoint Sponsor

User Tag List

Page 2 of 2 FirstFirst 12
Results 26 to 31 of 31
  1. #26
    SitePoint Enthusiast
    Join Date
    Jan 2008
    Posts
    38
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    What I don't understand is, if there is logic in the model that modifies DB, etc. Then what does the controller do?

    I have seen implementations where there is no page controller, and there is only a front controller that basically points to a proper model that handles all logic, etc.

    I thought that the controller, modifies the model, but if the model itself has logic, then why is this needed? The only reason that a controller would be needed to modify the model is if A) the model was a data structure B) Wrapped a DB table.

  2. #27
    SitePoint Enthusiast traxxas's Avatar
    Join Date
    Jan 2007
    Location
    San Diego, CA
    Posts
    67
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The controller only selects the correct model for a given request. All the real business logic happens in the model.

  3. #28
    SitePoint Enthusiast
    Join Date
    Jan 2008
    Posts
    38
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    So would it be appropriate to just do sometihng like this:

    in controller.php

    $model = load("model_user");
    $model->execute();
    $view->render();

    Is that substantial responsibility for a controller?

  4. #29
    PHP/Rails Developer Czaries's Avatar
    Join Date
    May 2004
    Location
    Central USA
    Posts
    806
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Lightbulb They BOTH contain logic!

    Quote Originally Posted by tankbott View Post
    What I don't understand is, if there is logic in the model that modifies DB, etc. Then what does the controller do?

    I have seen implementations where there is no page controller, and there is only a front controller that basically points to a proper model that handles all logic, etc.

    I thought that the controller, modifies the model, but if the model itself has logic, then why is this needed? The only reason that a controller would be needed to modify the model is if A) the model was a data structure B) Wrapped a DB table.
    Both the model and controller can contain logic. The key is that they handle different kinds of logic.

    The controller is where you place your business logic. This will be code that may take the data and do something with it, but will not really alter the data. A good example would be working with a 3rd party payment processing gateway. It gets the credit card number and info from the model and sends it to the payment gateway however it wants it (in XML, as a query string, a SOAP request, etc.). It then has the logic to handle and parse the response and passes the raw response data back to the model.

    The model layer is where you place your domain logic. This is the logic that will alter the raw data from the database so that it can be used in your controllers in a consistent manner. One example of logic that you would want to place in your model is encryption. By placing the encryption logic in the model layer, you can ensure that the data will always be encrypted and decrypted the same way no matter which controller accesses it, because they all get data from the model. The encryption will fundamentally alter the raw data itself.

    So using this setup, you can just have a controller get a model, and ask for the credit card information. The model will query the database, decrypt the credit card number and other information, and send the unencrypted data to the controller. The controller will then take that data and query the payment gateway. It will get back a response, parse it to extract the raw data, and then send that data back to the model. The model will then encrypt the data and store it, and the controller will return a success or failure response back to the user.

    This separation makes it possible for the model to be used in multiple controllers without even having to think about formatting the data you get from the model. Likewise, the model is not geared towards a specific function, but rather only has to worry about getting and setting data from it's data source.

  5. #30
    SitePoint Enthusiast
    Join Date
    Oct 2006
    Posts
    37
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The controller is where you place your business logic.
    I would say that this is more of a Page Controller. The Front Controller is what executes the example that you (tankbott) posted.

    You wouldn't write this for every page controller. Though you could of course use inheritance, whether that makes more sense I don't know. The common idea here is to not use inheritance unless it makes absolute sense (not just because it works).

  6. #31
    SitePoint Addict
    Join Date
    Feb 2006
    Posts
    281
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    A quick question!

    Do you think things like user login and shopping cart classes be classed as models and be put in the models folder?


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
  •