Model

The domain-specific representation of the information on which the application operates. Domain logic adds meaning to raw data (e.g., calculating if today is the user's birthday, or the totals, taxes, and shipping charges for shopping cart items).

Many applications use a persistent storage mechanism (such as a database) to store data. MVC does not specifically mention the data access layer because it is understood to be underneath or encapsulated by the Model.

The model is a class or set of classes (package) where :

    • All business rules are located

    • DB storage / retrieval is commanded

Having an independent model help avoids code repetition

One of the main purpose of F3 is to keep a robust architecture, enforcing good coding practices for easy maintenance and scalability. To keep a clean model some rules should be followed.

What's not in the model?

    • Environment vars, request, etc

    • Running time info, session

    • Presentation instructions, $template, echo

    • Language / labels

What's in the model

    • DAO instructions

    • Non-DAO Data access instructions (getData, getRow, getValue)

    • Data transformation, calculations

    • Business rules

Can the model interact with the template or read the $_POST var

The model have no access to the template, the view or the controller code, other variables like $_POST, $_GET, $_REQUEST are global PHP vars so they are accessible but SHOULD NOT be accessed from the model as this is a bad practice and will affect code re usability.

Extending CRUD_model

Tequila offers minimal coding by providing inheritance, while we didn't want to make a single record (VO) or a Data access object (DAO) the mode, we provide the option to inherit crud model to manipulate the common CRUD page scenario.

You should only use this inheritance in this cases, as your model grows in complexity you might consider keeping your DAO/VO and use a model class that doesn't extend CRUD_model.

Complex models

Many modern frameworks have come to an hyper simplification of concepts where the Model seems to represent a single row in a database table, this unfortunately is rarely the case in most applications.

As developers make real world applications, trying to follow that simplicity leads code to get confusing and dirty, as the model class has to handle different roles.

This simple advice doesn't pretend to be an exhaustive guide they are just a set of simple guidelines on how to code your model and divide your code:

    1. Try keeping all your SQL code in DAO classes

    2. Try to keep all your business rules in the model class, not in the DAO

    3. When a function includes SQL and logic, split in 2 and follow the previous rules

    4. When it's unclear where to add the DAO methods (which DAO)

      1. Follow by returned type, i.e. employess->getbycompany() - return employee

      2. Follow by common access to the function, i.e. company->getemployees()

    5. It's valid to access other models from the Model or from any of the objects, with moderation, still the logic should remain in a single class.

    6. Consider creating a single facade to access catalog data, common data structure, lang, preferences, etc. that will be accessed from many pages.

    7. If you discover that your model must access a big amount of model classes, consider turning it into a facade/interface for your model, remove CRUD_model inheritance if it exist and code a clean model class that access all the model classes you need

    8. If your code seems to represent i.e. an individual object, the individual object manager, the general manager, and it's accessing other model (or something similar). Split your class in as many roles as you can identify, i.e.

      1. Resource manager -> get/find/save/delete,

      2. Resource -> VO or object with resource methods, -> isavailable, reserve, etc.

      3. Facade -> Exposes methods to the Controller and View and access any required model, can also implement some kind of caching or lazy loading to improve efficiency

      4. Pay attention to object composition.

Remember that each class it's an individual expert and models an specific entity in a system, VO's and DAO's are created to separate the object properties from the object manipulation and to simplify passing structured data around the system.