6

I am trying to get my hands on MVC. I am from ASP.Net background.

After creating new mvc 3 application, i got Controller, Models and views under the same webapp project. In ASP.Net, we generally create separate projects for Models and Controllers (which i assume are same as Business Layer). Also i created a separate project for DAL where i will be using EF.

I am confused as is this the ideal solution structure? Should we not create separate projects for each layer? Since i created DAL as a separate project, i had to put a reference of WebApp in it because i wanted to return Model from the DAL and because of that now i am not able to add a reference of DAL to my WebApp.

Can someone please throw some light on what am i missing here? Am i not doing it right?

Asdfg
  • 11,362
  • 24
  • 98
  • 175
  • 2
    [http://stackoverflow.com/questions/2295360/asp-net-mvc-solution-project-layouts](http://stackoverflow.com/questions/2295360/asp-net-mvc-solution-project-layouts) – mrydengren Jun 17 '11 at 22:28
  • Thanks for the link. Created a sample project just like what is explained in there and it gave me clean idea. Thank you very much. – Asdfg Jun 20 '11 at 14:26

2 Answers2

6

MVC really leaves the "M" part up to the developer.

Even in their official examples you'll see variations. Your question exposes one of the most common misconceptions about MVC. You should NOT bind your domain or data models directly to views, nor should your controller methods accept them as parameters. See this post on over and under-posting.

Ideally, your controllers will call out to a DAL, and some mechanism will map those Data or Domain models to View models. It is those View models - models that exist specifically to facilitate the UI - that should exist in the WebApp "Models" folder.

So, you were definitely on the right track creating a new assembly to contain your DAL. One of the "easiest" mechanisms for mapping to a ViewModel is a simple method on each ViewModel:

public class MyWidgetFormModel()
{
   public string Name { get; set; }
   public string Price { get; set; }

   public MapFromDAL(DAL.Widget widget)
   {
      this.Name = widget.Name;
      this.Price = widget.Price;
   }
}

Update: based on your comments, here is an excellent answer about one user's project layout.

Community
  • 1
  • 1
Peter J
  • 57,680
  • 8
  • 38
  • 45
  • So if there are model classes which may be used in UI and DAL should reside in separate project? is it OK to breakdown the default structure that comes when creating mvc application? – Asdfg Jun 17 '11 at 22:16
  • For the models it's safe to move the structure around, but the Views should remain in the same spot, and Controllers shouldn't need to go anywhere. – Peter J Jun 17 '11 at 22:22
  • In the example you have given, if my Model classes are in the same project as my UI, then i will be adding DAL reference to UI. I dont want to do that. I want my controller to manage DAL operations and i want the mapping to happen in DAL. Also if i keep Controllers in the same project, i end up adding DAL reference to UI. isnt it wrong or am i not getting it right? – Asdfg Jun 17 '11 at 22:22
  • I see. Exactly what i dont want to do. I need to work on this a bit more to understand. still not fully convinced why should i let my DL know where my UI is. Just because i want controllers to call DL and i cant take controllers out of the UI project? – Asdfg Jun 17 '11 at 22:35
  • Excellent link. That will help a lot. – Asdfg Jun 17 '11 at 22:39
3

When I started with MVC i followed the Jeffrey Palermo onion architecture. You can read about it :

here : http://jeffreypalermo.com/blog/the-onion-architecture-part-1/

here : http://jeffreypalermo.com/blog/the-onion-architecture-part-2/

and here : http://jeffreypalermo.com/blog/the-onion-architecture-part-3/

It's using a IoC support for decoupling services. I think that you should consider usage of IoC containers because the MVC architecture was thought around patterns using IoC in order to decouple services (layers).

You can also dowload a working sample from http://codecampserver.codeplex.com/ using onion architecture.

It's not the only architecture you can use with MVC but it's a very good place to start and to learn about IoC and decoupling in MVC applications.

Tomasz Jaskuλa
  • 15,723
  • 5
  • 46
  • 73