MVC, where do the classes go?

Question

My understanding of the MVC is as follows (incase it's horribly wrong, I am afterall new to it)

1. Models are the things that interface with the database
2. Views are the design/layout of the page
3. Controllers are where everything starts and are essentially the page logic

I'm using CodeIgniter but I would hazard a guess it's not just limited to that or possibly even just to PHP frameworks.

Where do I put global classes?

I may have a model for Products and I then run a query that collects 20 products from the database. Do I now make 20 models or should I have a separate class for it, if the latter, where do I put this class (other controllers will need to use it too)

Answer 1

In CakePHP there are 3 more "parts" :

1. Behaviors
2. Components
3. Helpers

Logic that are used by many models should be made as a behavior. I do not know if CodeIgniter have this logic or not, but if it doesnt, I would try to implement it as such. You can read about behaviors here.

(Components helps controller share logic and helpers help views in the same way).

Answer 2

Model is the wrong word to use when discussing what to do with products: each product is a value object (VO) (or data transfer objet/DTO, whatever fits in your mouth better). Value objects generally have the same fields that a table contains. In your case ProductVO should have the fields that are in Products table.

Model is a Data Access Object (DAO) that has methods like

findByPk --> returns a single value object
findAll --> returns a collection of value objects (0-n)
etc.

In your case you would have a ProductDAO that has something like the above methods. This ProductDAO would then return ProductVO's and collections of them.

Data Access Objects can also return Business Objects (BO) which may contain multiple VO's and additional methods that are business case specific.

Addendum: In your controller you call a ProductDAO to find the products you want. The returned ProductVO(s) are then passed to the view (as request attributes in Java). The view then loops through/displays the data from the productVO's.

Answer 3

Model is part of your application where business logic happens. Model represents real life relations and dependencies between objects, like: Employee reports to a Manager, Manager supervises many Employees, Manager can assign Task to Employee, Task sends out notification when overdue. Model CAN and most often DO interface with database, but this is not a requirement.

View is basically everything that can be displayed or help in displaying. View contains templates, template objects, handles template composition and nesting, wraps with headers and footers, and produces output in one of well known formats (X/HTML, but also XML, RSS/Atom, CSV).

Controller is a translation layer that translates user actions to model operations. In other words, it tells model what to do and returns a response. Controller methods should be as small as possible and all business processing should be done in Model, and view logic processing should take place in View.

Now, back to your question. It really depends if you need separate class for each product. In most cases, one class will suffice and 20 instances of it should be created. As products represent business logic it should belong to Model part of your application.

Answer 4

The simplest way is to:

1. Have a model class per database table. In this case it would be an object that held all the Product details.
2. Put these classes into a package/namespace, e.g., com.company.model (Java / C#)
3. Put the DAO classes into a package like com.company.model.dao
4. Your view will consume data from the session/request/controller In this case I would have a List<Product>.
5. Oh, you're using PHP. Dunno how that changes things, but I imagine it has a Collections framework like any modern language.

Answer 5

@Alexander mentions CakePHPs Behaviors, Components and Helpers. These are excellent for abstracting out common functionality. I find the Behaviors particularly useful as of course the bulk of the business logic is carried in the models. I am currently working on a project where we have behaviors like:

• Lockable
• Publishable
• Tagable
• Rateable
• Commentable

etc.

For code that transcends even the MVC framework i.e. code libraries that you use for various things that are not tied in to the particular framework you are using - in our case things like video encoding classes etc. CakePHP has the vendors folder.

Anything that effectively has nothing to do with CakePHP goes in there.

I suspect CodeIgniter doesn't have quite as flexible a structure, it's smaller and lighter than CakePHP, but a quick look at the CakePHP Manual to see how Behaviors, Components, Helpers, and the Vendors folder may be helpful.

It should be an easy matter to just include some common helper classes from your models keep nice and DRY