【发布时间】:2018-08-30 17:30:36
【问题描述】:
我想将我的项目移动到 ASP.NET Core 框架。我是 asp.net 核心的新手,所以不知道如何在那里使用 UnitOfWork 模式。当我使用 asp.net mvc 时,我将解决方案分为 3 层架构(DAl、BLL、WEB 层)。在 BLL 层我使用了 Ninject 注入,所以我不需要从我的 WEB 层添加对 DLL 的引用。
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);
}
}
但是所有教程都说在 ASP.NET Core 应用程序中应该像这样在 ConfigureServices(WEB 层)方法中使用核心注入:
services.AddTransient<IUnitOfWork, EFUnitOfWork>();
但是,添加引用以从 WEB 中添加对 DAL 层的引用是个坏主意。
那么,我该怎么办?添加参考(不要这么认为)或编辑我的结构?或者其他什么?
【问题讨论】:
-
三件事:“添加引用来添加引用是个坏主意”是不正确的,因为除非您引用它,否则不会复制 DLL,因此您无法在没有手动工作或一些构建事件的情况下部署您的应用程序.第二:工作单元和实体框架核心是一个坏主意,所以没有必要这样做。第三:就是.NET Core容器,用不用,看你自己
-
@Camilo Terevinto:您能否详细说明“第二个:工作单元和实体框架核心是一个坏主意,所以没有必要这样做。”?
-
@RWC 评论范围很广,但是,基本上,Entity Framework 已经是一个基于 UoW 和存储库的库,将它隐藏在另一个 UoW 后面会使您的代码更加复杂,实际上并没有给出你有什么回报。当然,除非您计划将来放弃 EF,否则我不会考虑从它开始。当您必须处理抽象实体框架功能的 UoW 时,事务、复杂和可重用的查询要复杂得多
-
@Camilo Terevinto:我理解你的意思,但我不认为这是完全正确的。实体框架实现了工作单元和存储库模式。对于实体框架,DbContext 是工作单元,每个 DbSet 都是一个存储库。 UoW 和 EF Core 不相互排斥。看看微软自己的例子:docs.microsoft.com/en-us/aspnet/mvc/overview/older-versions/….
标签: c# asp.net-core entity-framework-core