CODEWITHSUNDEEP
c#asp.netasp.net-mvcdesign-patternsdomain-driven-design
Catalin
Catalin

Reputation: 11731

Layer ASP.NET MVC Project

I am trying to understand the concepts of a good designed project.

I am using ASP.NET MVC and i am trying to create a layered (pluggable) project.

The current project structure what i have now is this:

  1. LayeredProject - the MVC Project containing Controllers

  2. LayeredProject.EntityFramework - contains all the POCO classes used for database. (i am using Code First approach)

  3. LayeredProject.Model - this should contain all the business objects used in the project.

Saying that the project is a eCommerce website, i would structure it like this:

First of all, i am not sure that this is the right way of doing this.

And, it this is the right way of doing it, then i get a little confused because i will have a duplicate of my POCO classes in EntityFramework project and also on Model project.

Please help me understanding this

Upvotes: 2

Views: 1528

Answers (5)

JotaBe
JotaBe

Reputation: 39055

The MVC project should contain:

  • view models: models for the views, i.e. models that are very specific to render each view (these model are not the M in MVC). This models usually contain the data which must be shown or edited in the view, as well as aditional necessary information to render the view: for example, if the view must render Drop Down Lists, the view model should contain the corresponding SelectList or IEnumerable to populate the list. You can use mappers, like AutoMapper or ValueInjecter to move data from the business entities (entities coming from the Business Layer) to the view models, and viceversa. Or if appropriate, you can use directly the business entities as properties in the model view (the view model doesn't need to be flat: it can contain objects as properties)
  • views, strongly typed with the view models
  • controllers: this controllers use the Business Logic (that is the Model, the M in MVC) to control the application flow, to create and provide the model views for the views, and to react to the user actions
  • UI helper: I usually add this layer to fulfill the DRY principle. I.e. if I have to prepare a SelectList and it's going to be used in many views, I do it in this layer, and use it from all the necessary places. This can include calculations, orderings, or anything tighly related to the UI, so it doesn't fit in the Business Layer (Model). This uses the Business Layer, and provides data specific for the Views.

Those are the specific and critical parts of MVC, which includes the VC in MVC (views and controllers) The M in MVC (Model) is the business logic which can be done 'as usual'. I.e. you don't have to do anything special in your business layer to use it with MVC. You can use the technology of your choice (a traditional DAL + BLL, WCF, WS, or whatever you want).

This is something which works well for LOB applications. Of course, if you're making a toy application, you can forget this all and make something more monolythic. But I only recommedn this for very little applications with scarce maintenance needs.

These are examples of objects in several layers that allow to edit a "Pet":

  • Business Logic Layer:
    • PetService, a class which can be use to read, write, find, and modify pets (as explained above it doesn't matter how this is implemented)
  • Business Entity: it's the BLL entity for managing Pets. This could be a POCO object or a DDD entity:
    • Pet - int Id, int PetTypeId, string Name...
  • View Model: contains a Pet proerty, as well as a list of PetTypes, so that the view can render a drop down list for the PetTypeId:
    • PetViewModel - Pet ThePet, SelectList PetTypes
  • UI Helper: if the PetTypes is going to be used in more than one or two views, a PetUiHelper could provide this select list for all the views that require it:
    • PetUiHelper - GetPetTypesList()
  • Pet views: a strongly typed view for PetViewModel
    • Views\Pet\Edit.cshtml
  • PetController: uses the PetService to create the views, and their model views.
    • PetController - Edit(int id) --> returns an Edit view, woth its corresponding PetViewModel. There must be also an HttpPost Edit action which receives the user input in an specific model or the PetViewModel, or the Pet plus the Id or whatever. This depends on what you're editing.

Finally, if you know how to use DI, you can use Unity.Mvc or any of the other options to inject the Business Services in the controllers.

Upvotes: 1

amesh
amesh

Reputation: 1329

You can Design Your Project using layered structure as well using MVC. The Controller and view part should stay intact. You can divide the business logic part as many layers as you want. The model should come as a result of the number of layers you are expecting. For this keep your business logic in a separate project (not neccessary: it can be there in web project itself), refer the dlls from that project to the MVC web solution. Pass the models which are generated as a result of database querying to the web solution and with the help of controller render the view.(I have done my project using this style)

Upvotes: 1

developer747
developer747

Reputation: 15958

Most MVC apps I have worked were layered in this way

MVC Project: Had the controllers, views and models. The business logic resides in the model.

The Data Access layer (Persistence layer) : This project uses an ORM. (In your case entity frame work)

Classes that are mapped to the database tables reside in the Model and not the data access layer.

Upvotes: 0

Turnkey
Turnkey

Reputation: 9416

You probably have one too many layers in there, there should be no reason to separate the model with the business logic from the LayeredProject MVC layer itself unless you are planning to have a client app or some other separate project to access the model. In the MVC project you already have a model folder that can be used for that. However in the MVC project you should also add a "ViewModels" folder to keep models that are specifically used for the view concerns (e.g. DTO objects).

This project shows a nice simple way of keeping the things separate simply within folders in the MVC project: RacoonBlog Project. Although it uses RavenDB rather than EF the ideas are the same.

Upvotes: 0

hagensoft
hagensoft

Reputation: 1507

seems your using the Code First approach to build a data access, you can dig in this extensive article and gain more insight.

http://ofps.oreilly.com/titles/9781449320317/ch_AdvancedData.html

Upvotes: 0

Related Questions