Organization of an application for cells in dotnet for 3-level data access levels

Question

My typical .NET 4.5X web application structure has at least 3 levels: a web project (.NET web application), a project for domain / business logic (class library), and a data access project (class library). The web project refers to the business layer, and the business layer refers to the data access layer.

I like this approach because my web project does not have a link to the data access project (it must first go through the domain / business logic level). My web project should not have any access to context or repository classes.

In a three-tier .net 4.5.X application, I declare a connection string in the web.config file and specify the name DbContext as an attribute of the connection string name.

In the new Dotnet Core paradigm, every example that I see has a DbContext configured in Startup.cs as follows:

public void ConfigureServices(IServiceCollection services) { // Add framework services. services.AddMvc(); services.AddEntityFramework() .AddSqlServer() .AddDbContext<MyApplicationContext>("myconnectionstring or reference to it"); } 

By providing the launch with a specific class for use in dbcontext, I must reference the data access project where dbcontext is defined. I would prefer to refer only to the middle tier and avoid referring to DAL.

My question is: how should I streamline the structure of the solution to avoid adding a link from my web project to my data access project?

Can I use the appsettings.json property?

Can I add my Entity setting in another way?

Is there anything important that I'm missing in the kernel with a net point?

Thanks in advance.

Answer 1

I found a solution using EF6 and Dotnet Core, which I'm pretty comfortable with.

It does not use the services.AddSqlServer () calls for EF7, but uses the EF6 configuration and registers the DbContext in the Bootstrap class invoked at startup.

 public static class BootstrapConfig { public static void RegisterApplicationServices(this IServiceCollection services, IConfigurationRoot configuration) { // DbContext services.AddScoped<DbContext>(x => new ApplicationContext(configuration["Data:ApplicationContext:ConnectionString"])); } } 

It is called from Startup.cs in a WebLibrary project as

 public void ConfigureServices(IServiceCollection services) { // Add framework services. services.AddMvc(); services.RegisterApplicationServices(Configuration); } 

WebLibrary is a network-based network application with a grid point (contains controllers, this is a startup project).

Business logic is the level of service, and the middle tier is between the web application and the data access project.

Data access is where the dbContext and repository classes exist for actually executing the request.

The Model project contains POCOs and Enums, not smart objects, but containers that are used in the application.

The Bootstrap project has a link to business logic and data access projects so that it can register services and repositories for the IOC container.

Check out github repo for an example solution. One of the problems that I have for my application is this:

Despite the fact that the web library does not have a link to the data access project, I can still create an ApplicationContext instance from one of the controllers. The whole point is to separate these projects so that I can make it impossible to get the db context directly in the web project. I'm not sure if this is due to the new solution structure in Core, or if I include something that I don't know about.

Answer 2

I think you are looking for the Repository template. This is the layer between your business and DAL.

This is how I organized the last solution to avoid the user interface being aware of my DAL.