2

I am writing a web application using the full MVC capabilities of the Zend Framework and including a service layer, domain model and mapper. I think my understanding of the layers is correct but would like to confirm.

The upper layers are dependent on the layers below, so starting from the top:

  1. Controller - the topmost layer. Highly dependent on the View, which it instantiates, populates and renders. Dependent on Services for access to the Model.

  2. View - Unaware of the Controller. Occasionally depends on Services or Model, e.g. to populate lookup lists for a select control.

  3. Services - Provide an API to clients, such as the Controller. Highly dependent on the Model. In fact, Services often mediate between the Mapper- and Domain-parts of the Model to get work done for a client.

  4. Mapper (Model, Part A) - Has an intimate knowledge of the Domain, manipulating Domain objects to fit into a relational data store, and manipulating relational data to create fresh Domain objects.

  5. Domain Model (Model, Part B) - Contains the domain logic. Domain objects are unaware of other layers however since they need access to other domain objects, they may access mappers as 'object finders'.

Does that sound about right? What have I missed?

Improve this question

3 Answers 3

Reset to default
3

Well. It's kinda wrong-ish in few details.

There are two primary layers in MVC:

  • model layer: that deals with all of the domain business logic, rules and information
  • presentation layer: deals with interface and interactivity

The controllers are not the "topmost layer". They are part of presentation layer, and their responsibility is to handle users' requests and pass the extracted information to alter the state of model layer (through services) and (much rarer) the current view.

I would say, that Services are the the "C part" of Model. Also, I tend to prefer name "domain object" over "domain model" or "model object", because it causes additional confusions.

And the domain objects to not access data mappers. Domain objects themselves should be completely unaware of whether they are stored or not. That part is handled by services. You can find code/api example in this answer.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

Thanks teresko, I have been waiting for your input!
@teresko Where do you keep the business logic? inside the Controller?
1

Basically, I agree with your statements, but I would go a bit deeper.

The controller is your mediator between the View and your Model. So as you said, the View is unaware of the controller, but so is the Model.

Also, in your model, as you mentioned, that's also a good point to have the Service layer as en entry point of your model !

You always have to keep in minde that the Controller and View layers might be on a server, and the model on an other one. So your service acts as a facade between your business need and your business logic. It also may handle your transactions, error standardisation, etc... Transverse things actually.

For your domain part, I would extend your mapper part by dividing it into 2 distinct parts. Since it's your DAL, you may want to create class for :

  • Requesting your domain objects, wherever they come from
  • Retrieving your domain objects, from a specific location

I mean, your BL requests your DAL an object, so you ask your storage to give it to you. The storage has a set of retrievers, such as a level1 cache (regular php array), level2 cache (memcached, redis, anything), and finally your database. So I'd basically have 2 sub layers in the DAL : a storage class with its stack of stores and priorities, and an implementation for the fetch in those stores.

Don't forget to step into your layers only using factories, so that it will be easier to make unit testing by mocking your objects inside them, or add interceptors between each layer.

Regards.

Improve this answer

Comments

0

You forgot the 'M' from MVC, that is for Model. Model provides for your View, the information needed to render it, or the information you want to your client submit on it. The Controller and the View trades information via your Model. But an important detail is that Model IS NOT your Domail Model

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.