Page 1 of 1

Model and Data layers

Posted: Mon Dec 22, 2008 7:51 am
by The_Anomaly
This came up when I was looking at the CakePHP framework, and came across the following image:

Image

I'm bringing this up here, because in the past I've always had the DataSource interact with the page controller. As in, instead of the model or domain logic accessing the data layer, I'd have the controller "Combine" both.

For example, I have a Video_DomainObject and Video_DataMapper with an insert(DomainObject $object) method. I then compose a video object into the insert method, and it persists it. Is this a good way of doing it? Or should the DomainObject itself have an insert() or save() method, and have it interact with the database itself?

The reason I ask is because everything I read says to keep the domain logic separate from the data layer, and it seems the above diagram is contradicting that.

Re: Model and Data layers

Posted: Mon Dec 22, 2008 9:56 am
by alex.barylski
It's important to realize that CakePHP is just one interpretation of MVC. Everyone in their dog has an idea as to how it should be implemented.

Strictly speaking, I believe it's best the controller deal with a single model interface and all business logic, data access logic, etc be encapsulated by that interface.

In reality sometimes it's easier to just use multiple data source objects and have some of the business logic in the controller, it's up to you to determine when it makes sense to invest a little more effort into the design and maybe provide a single simplified interface to deal with the model.

Consider the question: Where should my access control logic go?

In the controller or in the model?

Common knowledge would suggest that go in the model, and yet, in some instances it's equally well suited in the controller. I recently entered into a discussion about the subject of thin controllers heavy models and vis-versa but suffice to say, in my experience sometimes what is theorteically best is not always realistically best.

I frequently reuse model code...more than any thing else. So client A asks me to build a profiles listing application. Profiles is a generic form with standard fields represented by a single model.

If I were building an application for myself, access control might go in the model, because I like knowing that if that model is used in a web service, the same access control policies are applied to the caller as if that very user was logged in and making requests.

On the contrary, if I am writing code for client A, his access control policies are usually different from client B, so if I kept those access control checks in the model, I would have to manually remove those checks when I wished to reuse that model in a future project. Whereas if I kept the model light weight and added some extraneous logic to the controller layer I wouldn't have to touch the model code at all in the future, just simply drop in the code, instantiate it and use it.

Cheers,
Alex

Re: Model and Data layers

Posted: Mon Dec 22, 2008 10:48 am
by The_Anomaly
Strictly speaking, I believe it's best the controller deal with a single model interface and all business logic, data access logic, etc be encapsulated by that interface.
If this is the case, then what do you use your controller for? In my experience, I've used the controller to kind of tie it all together. i.e. instantiate the mapper, call a find() from it which returns a domain object, send the domain object to the view, etc. So, the Data, Domain, and View are all separate from one another, and are all tied together with the controller. When you say "Thin controller," how thin are you talking about?
Consider the question: Where should my access control logic go?

In the controller or in the model?

Common knowledge would suggest that go in the model, and yet, in some instances it's equally well suited in the controller. I recently entered into a discussion about the subject of thin controllers heavy models and vis-versa but suffice to say, in my experience sometimes what is theorteically best is not always realistically best.
Maybe I'm misunderstanding the question--or perhaps I haven't encountered the more advanced access control you are referring to. But in a web app I just did, you have to log in to access any part of the site. I have a Singleton pattern that wraps my Session, and I have a static method to check the login. This is called in the Front Controller, and if it returns false, we're sent to the login.

This seemed logical, as at every page I want to check if I'm logged in or not. In this case, I'm calling the static function in the controller, but the actual logic is in the Session Singleton. Now that I think about it, that would probably be considered the model.

Would this be considered access control in the model?

Re: Model and Data layers

Posted: Mon Dec 22, 2008 1:19 pm
by Christopher
The_Anomaly wrote:This came up when I was looking at the CakePHP framework, and came across the following image:

I'm bringing this up here, because in the past I've always had the DataSource interact with the page controller. As in, instead of the model or domain logic accessing the data layer, I'd have the controller "Combine" both.

For example, I have a Video_DomainObject and Video_DataMapper with an insert(DomainObject $object) method. I then compose a video object into the insert method, and it persists it. Is this a good way of doing it? Or should the DomainObject itself have an insert() or save() method, and have it interact with the database itself?

The reason I ask is because everything I read says to keep the domain logic separate from the data layer, and it seems the above diagram is contradicting that.
I am not sure how that diagram is contradicting keeping the "domain logic separate from the data layer." Typically, MVC is a 3-Tier architecture. The View and Controller are in the Presentation Layer; the Model is in the Domain Layer, which sits on top of the DataSource layer where connection to subsystems and services reside. The major goal is to have the dependencies on lower layers only. In your example the DataMapper is in the DataSource Layer and the DomainObject is in the Domain Layer.

Dogs all agree on this layering, but they obviously implement it different ways (the whole point of patterns). And you can combine layers, or things within layers, if that makes sense for your design.

Re: Model and Data layers

Posted: Mon Dec 22, 2008 4:07 pm
by alex.barylski
If this is the case, then what do you use your controller for? In my experience, I've used the controller to kind of tie it all together. i.e. instantiate the mapper, call a find() from it which returns a domain object, send the domain object to the view, etc. So, the Data, Domain, and View are all separate from one another, and are all tied together with the controller. When you say "Thin controller," how thin are you talking about
I use the controller to do things which are specific to the application architecture, namely redirection, forwarding, trivial error handling, etc.

If calling the model from a web service causes grief then something is missing or something is extraneous, it's a good rule of thumb to follow in my experience.
Maybe I'm misunderstanding the question--or perhaps I haven't encountered the more advanced access control you are referring to. But in a web app I just did, you have to log in to access any part of the site. I have a Singleton pattern that wraps my Session, and I have a static method to check the login. This is called in the Front Controller, and if it returns false, we're sent to the login.
That sounds like authentication not authorization (ie: access control)

Every application requirements are different. Some clients want really fine grained access control over business entities. So limiting that user A cannot change any details except description fields for others, whereas other clients do not have any requirement for access control.