I’m making a facebook app and I’m trying to follow MVC properly. But I was wondering if I had a class that was a bunch of fql queries (getting data from facebook) should I have keep these in a controller or a model?
According to Codeigniter’s user guide “Models are PHP classes that are designed to work with information in your database”. Since fql interacts with facebook’s databases and not my own, would having a class full of what is basically just SQL Select statements count as valid model?
On an MVC pattern, a class that handles the data between the database and the application would be a valid model so long as the functions within it are related to the entity that the model represents. A CI model would inherit from the base model class of the framework to allow the user to use CI’s syntax for handling data in the database. So I my answer is Yes it is a valid model but No it’s not a valid CI model in some sense.
2
If you want to be orthodox about MVC:
- The Model implements the entire domain logic, and nothing but the domain logic. For a game, this would include:
- The current state of the players, units, world, etc.
- Persistence of such state
- The rules of the game (e.g., how units can move, what happens when unit X shoots unit Y, etc.)
- The View is about presenting output to the user. In a web application context, this means templates; depending on how powerful your template system is, you may need some presentation logic outside of the templates, and you’ll need some boilerplate to bootstrap the template engine. These, too, are part of the view.
- The Controller part is about processing user input. For web applications, this means parsing requests, routing to sub-controllers, validating inputs, and dispatching them into the Model.
There is one more part to it for which I haven’t seen a clean solution in a web application yet: you need to glue those three together. In strict MVC, the three components are mostly independent; the only connections are between controller and model (controller pushes requests for state changes to the model) and between the model and the view (view reacts to state changes in the model). In a web application, however, the controller typically needs at least some control over the view: the incoming request determines which view to use, and this information has absolutely nothing to do with the domain logic, so typically, the controller is allowed to select a view. Quite often, the controller even takes care of getting data from the model and passing it to the view.
So far the theory.
In modern-day web programming practice, MVC is usually taken to mean something quite different, along the lines of:
- Models are classes that map to database entities. They usually derive from a generic base class, which implements standard CRUD operations, and extend it to implement methods that are specific to the particular entity they represent.
- Views are classes that execute some presentation logic such as filtering, formatting, and sometimes even translation, and load and apply a template.
- Controllers are classes that do pretty much everything else: getting input data from the request, performing domain logic on the models, reading data back from the model, instantiating and executing a suitable view, and sometimes even things like redirecting.