1

I want to move my project to ASP.NET Core framework. I'm new in asp.net core so don't know how to work with UnitOfWork pattern there. When I worked with asp.net mvc, I divided solution into 3-tier architecture(DAl,BLL,WEB layers). In BLL tier I used Ninject injection, so I didn't need to add reference to DLL from my WEB layer.

public class ServiceModule : NinjectModule
{
    private string connectionString;
    public StandardKernel _kernel;
    IUnitOfWork uow;
    public ServiceModule(string connection)
    {
        connectionString = connection;
        uow = new EFUnitOfWork(connectionString);
    }
    public override void Load()
    {
        Bind<IUnitOfWork>().To<EFUnitOfWork>().WithConstructorArgument(connectionString);
    }
}

But all tutorials say in ASP.NET Core applications should use core injection in ConfigureServices(WEB layer) method like that:

services.AddTransient<IUnitOfWork, EFUnitOfWork>();

However, it's bad idea to add reference to add a reference to DAL layer from WEB.

So, what should I do?Add reference(don't think so) or edit my structure?Or maybe something else?

Camilo Terevinto
  • 31,141
  • 6
  • 88
  • 120
Vlad
  • 193
  • 2
  • 14
  • 2
    Three things: "it's bad idea to add reference to add a reference" is not true, because unless you reference it the DLL is not copied so you cannot deploy your app without manual work or some build event. Second: Unit Of Work and Entity Framework Core is a bad idea, so there's no need for that. Third: that's the .NET Core container, you can use it or not, that's up to you – Camilo Terevinto Mar 21 '18 at 14:31
  • 2
    See [Ioc/DI - Why do I have to reference all layers/assemblies in entry application?](https://stackoverflow.com/a/9503612). – NightOwl888 Mar 21 '18 at 14:44
  • @Camilo Terevinto: Can you elaborate on "Second: Unit Of Work and Entity Framework Core is a bad idea, so there's no need for that."? – RWC Jul 18 '18 at 11:10
  • @RWC It's pretty broad for a comment, but, basically, Entity Framework is already a UoW and Repository-based library, hiding it behind another UoW makes your code far more complex and doesn't actually give you anything in return. Unless of course you are planning on ditching EF in the future, at which point I wouldn't consider starting with it. Transactions, complex and reusable queries are much more complex when you have to deal with a UoW abstracting the power of Entity Framework – Camilo Terevinto Jul 18 '18 at 12:00
  • @Camilo Terevinto: I understand what you say, but I do not thing it is totally correct. Entity Framework implements the Unit of Work and Repository patterns. With Entity Framework, the DbContext is the Unit of Work and each DbSet is a repository. UoW and EF Core do not exclude eachother. Look at Microsoft own's example: https://learn.microsoft.com/en-us/aspnet/mvc/overview/older-versions/getting-started-with-ef-5-using-mvc-4/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application. – RWC Jul 20 '18 at 12:21
  • @Camilo Terevinto: Should or shouldn't you combine repositories with DbContext (unit of work)? Have a look at this answer: https://stackoverflow.com/a/28369517/760777 – RWC Jul 20 '18 at 12:22
  • @RWC I didn't say they exclude each other, I said it's useless for most projects. Each project has its complexities, there is not one true answer for this problem – Camilo Terevinto Jul 20 '18 at 12:25

1 Answers1

1

You can use an extension method and put it into your BLL Library:

namespace Microsoft.Extensions.DependencyInjection
{
    public static class BllServiceCollectionExtensions
    {
        public static IServiceCollection AddBll(this IServiceCollection services)
        { 

            services.AddTransient<IUserService, UserService>();
            services.AddTransient<ITransactionService, TransactionService>();
        }
    }
}

in you web Project you can add it to your Startup.cs like this

public void ConfigureServices(IServiceCollection services)
{
    ...
    serivices.AddBll();
    ...
}
wheeler
  • 647
  • 8
  • 17