Shouldn't the MVC become MVCS
Moderator: General Moderators
Shouldn't the MVC become MVCS
"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?
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
- 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
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.
Re: Shouldn't the MVC become MVCS
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
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.
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.
Re: Shouldn't the MVC become MVCS
I could agree with "development", but not with "maintenance"Hockey wrote:5 files for one request is a LOT of extra maintenance which is why many will probably find MVC to suffice.
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
- 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
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:"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.
Not Controller-Storage!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.
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.VladSun wrote:So, what do you think?
(#10850)
Re: Shouldn't the MVC become MVCS
You could have 20 million made up layers and still be following MVC
Re: Shouldn't the MVC become MVCS
Thanks, guys.
What makes me having doubts about the Storage layer is this one:
Any comments on this one?
What makes me having doubts about the Storage layer is this one:
* it's "raw", not "row".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.
Any comments on this one?
There are 10 types of people in this world, those who understand binary and those who don't
- 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
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.
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)
Re: Shouldn't the MVC become MVCS
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.
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
Re: Shouldn't the MVC become MVCS
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
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
- 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
I get confused starting at the "( without using the DB layer) and passes backward..." part. Why are you adding this second Model and forward?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.
(#10850)
Re: Shouldn't the MVC become MVCS
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
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
Re: Shouldn't the MVC become MVCS
OK, I surrender
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.
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
Re: Shouldn't the MVC become MVCS
I think MVC raises too many questionsarborint 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.
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.