Best Structure for ASP.NET MVC Solution

I tried to structure my last sizeable MVC project following a best practice approach, but didn't quite understand what I was doing.

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.

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.

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.

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.

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?

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? :)

the main guide that I use when I am setting up a project structure is to ensure that I can add some operationcontract attributes to the business logic layer, and then host it as a wcf service.

If i can do this, that means the business logic layer has isolated my data layer, and is interacting with its client only by passing simple structures and entities. the datalayer is completely hidden.

So my usual structure looks like:

Solution
    Business.Contracts (interfaces for bll layer in here)
    Business.Logic     (concrete implementations of contracts in here)
    Business.Entities  (Pocos that bll uses)
    Data.Contracts     (interfaces for dal)
    Data.Sql           (Concrete Sql implementation of contracts)
    Common.Enums       (Enums needed by all projects)
    FrontEnd           (Main mvc app)

So in this structure, my mvc project only ever deals with the business namespace and the common namespace.

When interacting with the entities however, I tend to use my own models in the mvc project to allow me to add annotations and front end specific functionality, then i provide implicit conversions for these models to be able to be used interchangeably with the business entities.

HTH