Simple model layer for a small website with tiny logic

Question

I have struggled with an MVC concept for a long time in php since I'm not a php developer. I refactored my site several times but it still looks like a cannon pointed in a mosquito. I've read many articles, posts and answears about MVC but it still makes me confused.

Let's have a simple website with articles and comments system. Everything is stored directly in a database (information about articles, paths, comments etc.). Mostly based on this I developed my own app using MVC. Here is how it works:

1. Controller retrieves data from the database about an article and related comments
2. It creates required model's objects (current article and comments)
3. ... and then passes necessary data to the View
4. View presents those data by applying particular templates for provided objects

Everything works like a charm but...

• my model's objects don't need any external logic so my domain objects are bordered to getter/setter classes -I'm wondering: do I need domain objects? It's pointless to store separated objects only for getting them from DB and displaying on a website after a while, isn't it?
• controller holds a DB connection passed to services and mappers for creating a model's object -but queries stored in mappers can be merged into services functionality

In conclusion, I wonder if it's not a better approach to replace three-part model with a single manager (per object) which will retrieve all necessary data from the database and will pass them in any way and form (i.e. associative array) to the View.

Please do note, that I'm describing a simple case (1:1:1) with tiny logic, where most data retrieved from database are only for a presentation purpose.

Answer 1

Well what you have just described is an architectural pattern for data modelling called the Data Mapper pattern.

In this pattern you separate the persistence logic to a Mapper class and leave all of the Data stuff in The Domain Model. In your scenario you mentioned there is little logic, which is fine. Logic grows as your application matures. The key point is the separation, persistence has nothing to do with logic and therefore should be moved into a different class.

The Mapper class is only concerned with persisting data (generally to whatever data store you choose), in practice you uses "Adapters", which is why in some ORMs you see a different adapter for different data stores (ie. MySQLAdapater vs PostGresAdapater... etc, implementing a abstract Adapter Interface/Base Class).

It should be noted though, in your conclusion what you describe is actually the MVC Architecture.

The Model Layer is essentially your Persistence Layer (like described above) The View Layer is where you present your data. Your Controller Layer is where your data manipulation ie On your domain object's data.

Typically a MVC request goes like... a URI gets mapped to a controller::action Action gets data, manipulates it and sends it to the view for rendering.

When MVC applications run into trouble is when your Controller accesses several different objects and needs to persist them all. The class architecture of an MVC application tends to be very heavy as the Models typically have more logic on them than in the Data Mapper pattern since MVC models have persistence tied into them (in practice).

Just as an aside, for simple projects like yours, you might want to look into simple presentation frameworks like http://www.slimframework.com/ It has no persistence layer built in, which leaves you to choose the best for your project.