Is there a suggested solution structure for ASP.NET MVC Production Apps

In general, I don't like to keep code (BaseClasses or DataAccess Code) in the App_Code directory of an ASP.NET Site. I'll usually pull this stuff out into a MySite.BusinessLogic & MySite.DataAccess DLL's respectively.

I'm wondering should I be doing the same for ASP.NET MVC.

Would it be better to Organise the solution something along the lines of

• MySite.Common - DLL - (Basic Functionality built on .NET System Dlls)
• MySite.DAL - DLL - (DataAccessLayer & DBML Files)
• MySite.Models - DLL - (MVC Models e.g. Repository Classes)
• MySite.Controllers - DLL (MVC Controllers which use Models)
• MySite - ASP.NET MVC Site.

Or am I missing something... presumably, I'll lose some of the nice (Add View, Go To Controller, context menu items that have been add开发者_运维技巧ed)

I have only done a few projects using MVC but using your naming structure we did the following:

• MySite.Common - DLL - (Basic Functionality built on .NET System Dlls)
• MySite.DAL - DLL - (DataAccessLayer & DBML Files and Repostiory Models)
• MySite.Models - included this as part of the MVC web app and only had models specific to views that did not always map one to one for each repository model.
• MySite.Controllers - included as part of MVC app but could link to a Business Layer
• MySite - MVC app.

So in the end had the following projects in my MVC solution:

• MVC Web App - contains controllers, view models to map DAL data to.
• Common - functionality that could be used in other apps
• DAL - contained all the data access related data including the wrapper classes
• BL - optional depending if it required a lot of business specific logic
• Tests

EDIT: My DALs alway output wrapped objects (if using Linq2Sql then I map the autogenerated classes to my classes in the DAL directly). The only classes that exist in the MVC app are containers that represent the viwes and mainly used to pass data to the views.

If your mobile app is using similar views I wouldn't try and re-use the same classes from your MVC app views. There is always slight differences that you will need to manage and you should be able to just use the DAL classes to map to your mobile views which follows the pattern of keeping the view classes localized to the app.

In most cases the following structure works fine:

• MySite.BusinessLogic (Controllers, Models, Repositories, ...)
• MySite.BusinessLogic.Tests (unit tests for controllers, models, repositories, ...)
• MySiteA (Views, Static Content)
• MySiteB (Views, Static Content)

MySiteA and MySiteB might be two flavors of the same site reusing functionality from the business logic.

From performance perspective you should prefer fewer larger assemblies than many small assemblies.

We do things a bit different

• [Database Name].Database.DLL (DBML files for a specific database)
• [Database Name].Services.[Problem Domain].DLL (which contains models, services and repositories)
• [Database Name].Services.[Problem Domain].Tests.DLL
• [Database Name].Services.DLL (when everything above fits nicely in a single service project)
• [Database Name].Services.Tests.DLL
• [Problem Domain].Services.DLL (business logic by problem domain)
• [Problem Domain].Services.Tests.DLL
• Web.Framework.DLL (reusable ASP.NET & MVC components)
• Web.Framework.Tests.DLL
• MySite.Web.DLL (MVC application including ViewModels)
• MySite.Web.Tests.DLL

We do this because we have multiple databases and data services that we connect to. And depending on the problem domain the same database might be accessed with a different set of models but sometimes sharing similar names.

Within a Services module we'll have the following structure

• \Models
• \Repositories
• \Services
• \etc.