Shouldn't the MVC become MVCS

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

User avatar
VladSun
DevNet Master
Posts: 4313
Joined: Wed Jun 27, 2007 9:44 am
Location: Sofia, Bulgaria

Shouldn't the MVC become MVCS

Post by VladSun »

"S" stands for "Storage".

What I need sometimes is that I could transparently use different storage ( i.e. flat file , DB, $_SESSION, different DB engines, etc.) with every Model object. Also, I want to change between different storage type with an ease.
I see it like the relationship Controller-Storage and Model-Storage and the behavior of a Storage object should be the same as the View ones.
I can see a "hidden" use of it by using "DB drivers", although it doesn't cover all of my thoughts.

So, what do you think?
There are 10 types of people in this world, those who understand binary and those who don't
User avatar
allspiritseve
DevNet Resident
Posts: 1174
Joined: Thu Mar 06, 2008 8:23 am
Location: Ann Arbor, MI (USA)

Re: Shouldn't the MVC become MVCS

Post by allspiritseve »

Storage is generally viewed as being beneath or encapsulated by the model layer... if you wanted, you could create mappers for each storage area that implement a specific interface, and the rest of your application can use them interchangeably.
User avatar
VladSun
DevNet Master
Posts: 4313
Joined: Wed Jun 27, 2007 9:44 am
Location: Sofia, Bulgaria

Re: Shouldn't the MVC become MVCS

Post by VladSun »

In other words it's still my MVC-S suggestion ;)
There are 10 types of people in this world, those who understand binary and those who don't
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: Shouldn't the MVC become MVCS

Post by alex.barylski »

The model could wrap a data access layer, which would then act as the data store abstraction...

This is how I did it and honestly it was a PITA...especially considering switching between databases is easily solved using phrasebook and XML was never an option for a data store. Well if it was it was selected for a reason and the model is just implemented using XML functions instead of mysql_* or PDO.

MVC can be further broken down into peices I suppose...

Model/DAL
View/Template

Each layer however, introduces yet another file and MVC is usually enough to drive most people away so I dought it would ever be touted as MD-VT-C

5 files for one request is a LOT of extra maintenance which is why many will probably find MVC to suffice.
User avatar
VladSun
DevNet Master
Posts: 4313
Joined: Wed Jun 27, 2007 9:44 am
Location: Sofia, Bulgaria

Re: Shouldn't the MVC become MVCS

Post by VladSun »

Hockey wrote:5 files for one request is a LOT of extra maintenance which is why many will probably find MVC to suffice.
I could agree with "development", but not with "maintenance" ;)

The main idea is that the storage layer could be simply described as an another view (like HTML view, PDF view etc.) - the "row DB view" ... So, like an ordinary view it should behave like that.
There are 10 types of people in this world, those who understand binary and those who don't
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Re: Shouldn't the MVC become MVCS

Post by Christopher »

VladSun wrote:"S" stands for "Storage".

What I need sometimes is that I could transparently use different storage ( i.e. flat file , DB, $_SESSION, different DB engines, etc.) with every Model object. Also, I want to change between different storage type with an ease.
This should really be done by implementing an interface so any of your Data Source objects can be used interchangeably by the Model object.
VladSun wrote:I see it like the relationship Controller-Storage and Model-Storage and the behavior of a Storage object should be the same as the View ones.
Not Controller-Storage!
VladSun wrote:So, what do you think?
I think you are missing that MVC is a specific take on N-Tier that first separates the top Presentation Tier from all the tiers below it. The View and Controller are in the Presentation Layer, and the Model presents an interface to every layer below. Typically the implementation is the classic 3-Tier where the Model has a dependency on the Data Source, but not vice-versa. So the three tiers are the Presentation (V+C), Model and Data Source. But MVC is only concerned with what the major dependencies within an application -- especially the surfaces directly touched by application developers. The Data Source is internal to the Model and so not part of the pattern.
(#10850)
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Re: Shouldn't the MVC become MVCS

Post by josh »

You could have 20 million made up layers and still be following MVC
User avatar
VladSun
DevNet Master
Posts: 4313
Joined: Wed Jun 27, 2007 9:44 am
Location: Sofia, Bulgaria

Re: Shouldn't the MVC become MVCS

Post by VladSun »

Thanks, guys.
What makes me having doubts about the Storage layer is this one:
VladSun wrote:The main idea is that the storage layer could be simply described as an another view (like HTML view, PDF view etc.) - the "raw DB view" ... So, like an ordinary view it should behave like that.
* it's "raw", not "row".

Any comments on this one?
There are 10 types of people in this world, those who understand binary and those who don't
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Re: Shouldn't the MVC become MVCS

Post by Christopher »

Yes ... I am totally confused. ;)

Saying that the storage layer is the same as a "raw data view" does not compute. The "storage" that you describe are Data Sources that would be in a layer below the Domain (which would add business logic to the data). The View presents the Domain to the user.
(#10850)
User avatar
VladSun
DevNet Master
Posts: 4313
Joined: Wed Jun 27, 2007 9:44 am
Location: Sofia, Bulgaria

Re: Shouldn't the MVC become MVCS

Post by VladSun »

You should be confused if you follow the classic MVC ;)
Ok...
Classic MVC:
- by using a View (i.e. that's the part which interacts with the user) the Controller receives an event, then process it and pass it to the according Model. The Model does his job using the DB layer (i.e. the DataSource) and passes backward to the view (by or without using the Controller) the respond data. The View updates itself and waits for another user input.

Lets have the DB layer as a View:
- by using a View (i.e. that's the part which interacts with the user) the Controller receives an event, then process it pass it to the according Model. The Model does some part of his job ( without using the DB layer) and passes backward to the DB view (by or without using the Controller) the respond data. The DB View updates itself and autogenerate a new event which the Controller process it and pass it to the same Model. The Model does his job using the supplied data (as it hase been sent by the user) and passes backward to the view (by or without using the Controller) the respond data. The View updates itself and waits for another user input.
There are 10 types of people in this world, those who understand binary and those who don't
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Re: Shouldn't the MVC become MVCS

Post by josh »

You can use data mappers to move data between your storage layer and domain layer. I think word associations are getting in the way of seeing the clear picture here, the view is the presentation layer, if you're presenting data to an entity outside of your application that is a presentation layer, if you're persisting model data that is a storage layer ( which is usually mapped to the domain layer through data mapper or other patterns ). To ask if something is a model just ask yourself is a noun, to find out if it needs a storage layer ask yourself if that noun has properties that need to be persisted, if data needs to be persisted then that functionality should be encapsulated within or within a layer within your model

In your example it sounds like the controller would have to know how to use the storage layer's API. Then again maybe I'm just confused about what you're exactly proposing as well
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Re: Shouldn't the MVC become MVCS

Post by Christopher »

VladSun wrote:- by using a View (i.e. that's the part which interacts with the user) the Controller receives an event, then process it pass it to the according Model. The Model does some part of his job ( without using the DB layer) and passes backward to the DB view (by or without using the Controller) the respond data. The DB View updates itself and autogenerate a new event which the Controller process it and pass it to the same Model. The Model does his job using the supplied data (as it hase been sent by the user) and passes backward to the view (by or without using the Controller) the respond data. The View updates itself and waits for another user input.
I get confused starting at the "( without using the DB layer) and passes backward..." part. Why are you adding this second Model and forward?
(#10850)
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Re: Shouldn't the MVC become MVCS

Post by josh »

Agreed,

its generally accepted in MVC to have a view add a stack of actions for the dispatcher to execute, basically instead of your view directly talking to the storage your view queues an action, which then gets dispatched thats the whole point of a controller, to encapsulate your API and not call arbitrary layers directly.
Also generally your models aren't going to pass data to the view, the models themselves are passed to the view as objects and the view renders them
User avatar
VladSun
DevNet Master
Posts: 4313
Joined: Wed Jun 27, 2007 9:44 am
Location: Sofia, Bulgaria

Re: Shouldn't the MVC become MVCS

Post by VladSun »

OK, I surrender :lol:
It all started because of the many similarities between the View and the Storage layer.
I'll try to implement a prototype some day, but for now it's not clear enough even for me, haha :)

Thanks again guys.
There are 10 types of people in this world, those who understand binary and those who don't
webaddict
Forum Commoner
Posts: 60
Joined: Wed Mar 14, 2007 6:55 am
Location: The Netherlands

Re: Shouldn't the MVC become MVCS

Post by webaddict »

arborint wrote:I think you are missing that MVC is a specific take on N-Tier that first separates the top Presentation Tier from all the tiers below it.
I think MVC raises too many questions :) It really isn't all that hard to comprehend, assuming you already know the Single Responsibility Principle. Basically SRP tells us that any object should have but one reason to change, never more than one. So, taking a User as an example and breaking SRP, one could start with:

User::render( ); // for displaying purposes.
User::save( ); // for persisting into a Mysql database.
User::login( ); // querying the database.
User::setPassword( ); // for changing the password.

Now, think it through. Which reasons can there be to change the object? The displaying may vary (xml, html). Persisting might vary too (say I want to use a better database, such as Postgresql), logging in might change. Setting the password however isn't something expected to change. Now think about the principle: "encapsulate what varies". What've you got left? Yes, something that renders, something that controls, ( something that contains the bussinesslogic and something that persists).

MVC, it really is just following good practices. That's it.
Post Reply