Is there a proposed solution structure for ASP.NET MVC Production applications?

Question

In general, I do not like to save the code (BaseClasses or DataAccess Code) in the App_Code directory of an ASP.NET site. I usually pull this stuff into the MySite.BusinessLogic and MySite.DataAccess DLL, respectively.

I am wondering if I should do the same for ASP.NET MVC.

It would be better to arrange a solution for something according to

• MySite.Common - DLL - (basic functionality based on the DLL.NET System)
• MySite.DAL - DLL - (DataAccessLayer and DBML files)
• MySite.Models - DLL - (MVC models, for example, repository classes)
• MySite.Controllers - DLL (MVC controllers that use models)
• MySite is an ASP.NET MVC site.

Or am I missing something ... presumably, I will lose some of the pleasant ones (adding View, Go To Controller, added context menu items)

Answer 1

I completed only a few projects using MVC, but using the naming structure, we did the following:

• MySite.Common - DLL - (basic functionality based on the DLL.NET System)
• MySite.DAL - DLL - (DataAccessLayer & DBML files and replica models)
• MySite.Models - included this as part of the MVC web application and only models specific to always map one to one for each repository.
• MySite.Controllers - Included as part of the MVC application, but may reference the business layer
• MySite is an MVC application.

As a result, the following projects were implemented in my MVC solution:

• MVC Web App - contains controllers, view models for displaying DAL data.
• General - functionality that can be used in other applications
• DAL - contains all data related to data access, including wrapper classes
• BL - optional, if you need more logic for the business.
• Test

EDIT: My DALs always output wrapped objects (when using Linq2Sql then I map the automatically generated classes to my classes in DAL). The only classes that exist in an MVC application are containers that represent viwes and are mainly used to pass data to views.

If your mobile application uses similar views, I would not repeat using the same classes from MVC application views. There are always small differences that you will need to manage, and you should simply use the DAL classes to map to your mobile views, which follow the template for saving view classes localized in the application.

Answer 2

In most cases, the following structure works fine:

• MySite.BusinessLogic (controllers, models, repositories, ...)
• MySite.BusinessLogic.Tests (unit tests for controllers, models, repositories, ...)
• MySiteA (Views, In Stats)
• MySiteB (Views, In static)

MySiteA and MySiteB can be two options for using the same site using business logic.

In terms of performance, you should prefer fewer large assemblies than many small assemblies.

Answer 3

We are doing something a little 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. [Domain of problem] .Tests.DLL
• [Database Name] .Services.DLL (when everything above is perfect for one service project)
• [Database Name] .Services.Tests.DLL
• [Problem area]. .DLL Services (Problem Domain Business Logic)
• [Problem domain] .Services.Tests.DLL
• Web.Framework.DLL (reusable ASP.NET and MVC components)
• Web.Framework.Tests.DLL
• MySite.Web.DLL (MVC application including ViewModels)
• MySite.Web.Tests.DLL

We do this because we have several databases and data services that we connect to. And depending on the problem domain, one database can be accessed using a different set of models, but sometimes they have similar names.

Inside the services module, we will have the following structure

• \ Models
• \ Storage
• \ Services
• \etc.