Im building a new web app and am trying to create the best architecture incorporating design patterns and separation of concerns. Im using a book 'professional asp.net design patterns' which might not have been such a good idea for a beginner (in this
type of design anyway)
my solution consists of the mvc project itself then an application service layer, core layer (where my domain model lives - POCO), a data layer that holds the edmx file (entity framework 5) and an infrastructure layer (each of these is in a separate project
within the solution)
The book suggests the use of View models which use automapper to map from the poco classes. My question is this, why would I have 3 separate 'model' areas ? I understand the domain models (POCO), but what is the 'model' bit in the MVC project for ? If
I have view models in my domain model solution do these replace the models in the MVC project ? Im pretty new to MVC and design patterns so I appologise if this seems like a dumb question, but its confused me and Id appreciate any clarification or help.
MVC stands for model-view-controller. MVC is a pattern for developing applications that are well architected and easy to maintain. MVC-based applications contain:
Controllers: Classes that handle incoming requests to the application, retrieve model data, and then specify view templates that return a response to the client.
Models: Classes that represent the data of the application and that use validation logic to enforce business rules for that data.
Views: Template files that your application uses to dynamically generate HTML responses.
I know what mvc stands for, my question was, why would I have 2 models ? the model in the MVC project and another view model in my domain model that maps to the POCO's. Im just confused why there would be 2.
generally the (data) model is quite plain, practically is plain mapping to the actual backend.
but when you want to use the model in actual app, you find that you need more properties to better encapsulate complex info, so you came up another model "wrapper".
at the end, its still 1 model, just that it got another "plug-in" or addon.
misuk11
Participant
1608 Points
1280 Posts
mvc architecture
Feb 27, 2013 04:25 PM|LINK
Im building a new web app and am trying to create the best architecture incorporating design patterns and separation of concerns. Im using a book 'professional asp.net design patterns' which might not have been such a good idea for a beginner (in this type of design anyway)
my solution consists of the mvc project itself then an application service layer, core layer (where my domain model lives - POCO), a data layer that holds the edmx file (entity framework 5) and an infrastructure layer (each of these is in a separate project within the solution)
The book suggests the use of View models which use automapper to map from the poco classes. My question is this, why would I have 3 separate 'model' areas ? I understand the domain models (POCO), but what is the 'model' bit in the MVC project for ? If I have view models in my domain model solution do these replace the models in the MVC project ? Im pretty new to MVC and design patterns so I appologise if this seems like a dumb question, but its confused me and Id appreciate any clarification or help.
adamturner34
Contributor
3890 Points
971 Posts
Re: mvc architecture
Feb 27, 2013 05:48 PM|LINK
MVC stands for model-view-controller. MVC is a pattern for developing applications that are well architected and easy to maintain. MVC-based applications contain:
misuk11
Participant
1608 Points
1280 Posts
Re: mvc architecture
Feb 27, 2013 06:29 PM|LINK
Hi
I know what mvc stands for, my question was, why would I have 2 models ? the model in the MVC project and another view model in my domain model that maps to the POCO's. Im just confused why there would be 2.
adamturner34
Contributor
3890 Points
971 Posts
Re: mvc architecture
Feb 27, 2013 06:39 PM|LINK
It's a combination of the seperation of concerns and loose coupling.
If you have different data/business logic, you'll need a new model or atleast you should.
Kelmen
Member
180 Points
78 Posts
Re: mvc architecture
Feb 28, 2013 05:28 AM|LINK
generally the (data) model is quite plain, practically is plain mapping to the actual backend.
but when you want to use the model in actual app, you find that you need more properties to better encapsulate complex info, so you came up another model "wrapper".
at the end, its still 1 model, just that it got another "plug-in" or addon.