title: Best Structure for ASP.NET MVC Solution
body: <p>I tried to structure my last sizeable MVC project following a best practice approach, but didn't quite understand what I was doing.</p>
  
  <p>It has a Data, Business and Web (MVC) project, but the controllers contain most of the code, the Data layer uses NHibernate and has a few repositories responsible for too many things, and the Business layer is a dumping ground for anything that doesn't belong in the other two projects.  It works, but I feel it could have been setup better - the main things I'm unhappy with are the fat controllers and the repositories.</p>
  
  <p>I'm starting a new project that might grow to be a decent size, so I'm spending a bit more time trying to get my design right up front.  Having read a bit more, I'm trying to have a repository per aggregate-root, and then have a service in the Business layer for each controller in the presentation layer.</p>
  
  <p>My initial hopes were that the bulk of the code would go in the services and this coupled with the smaller repositories would keep my controllers and data layer thin.  So far though, this isn't happening.</p>
  
  <p>Everything I've read suggests that the View Models should not be returned from the Business layer, and should be populated in the presentation layer, so at the moment my service layer is mainly passing models from my data layer through to the presentation layer which then does what it needs to prepare the view models.  So I still have fat controllers, plus a thin business and data layer.</p>
  
  <p>My presentation layer also knows about both my business and data layer, but I thought part of the point of this separation was to reduce coupling?</p>
  
  <p>Have I got this all wrong?  Should I stop trying to blindly follow what I read on the internet and simply prepare view models in the business layer so I can move the bulk of my code in there?  Should I just go back to classic ASP? :)</p>