由于EF6现在是完全可模拟的,并且内置了工作单元和存储库-我想摆脱存储库模式。

但是,如何在整个应用程序中共享单个数据上下文。我是否应该有一个在其构造函数中使用datacontext的基本服务?

public class BaseService<T>:where T:class
{
   public BaseService(DataContext myDataContext)
   {
   //....... code
   }
}


然后使用datacontext来派生服务,例如PersonService,OrderService和其他服务来查询,更新和保存数据吗?

或者,还有更好的方法?

谢谢

最佳答案

但是,如何在整个应用程序中共享单个数据上下文。我是否应该有一个在其构造函数中使用datacontext的基本服务?


像大多数事情一样,这取决于。您的设计有多复杂?您是否正在应用域驱动设计?代码优先还是Db优先?

通常,您建议的解决方案很好。随着项目变得越来越复杂,您可以在应用域驱动设计时采用BoundedContexts。因此,仅将某个上下文作为某些“ BaseService”的一部分可能不再有意义。

JotaBe提到依赖注入和上下文的生命周期,这一点很重要。您在使用依赖注入吗?我更喜欢让IoC容器关注上下文的生命周期。
例如,对于一个Web应用程序,我将生命周期绑定到每个Web请求。

任何成熟的IoC容器都应该能够支持此功能。这是Autofac的快速一线工具。

builder.RegisterType<MyDbContext>().As<IMyDbContext>().InstancePerApiRequest();


特别是对于Db-first实现,我更喜欢使用接口支持DbContext并使用该接口来控制向调用者公开的内容。

public interface IMyDbContext {
    //Only expose people, not orders for example
    DbSet<Person> People { get; set; }
}

public partial class MyDbContext : IMyDbContext {
    //the generated DbContext class satisfies the interface
}

public class PersonService {

    private readonly IMyDbContext _context;

    public PersonService(IMyDbContext context){
        _context = context;
    }
}


我发现开销很小,并且有助于将上下文范围限定在您感兴趣的实际对象上,而不是创建多个EDMX文件。当您的域变得越来越复杂时,有助于引入BoundedContexts。

这是关于受限上下文和缩小的EF模型的另一个example

关于c# - 如何在不使用存储库的情况下共享EntityFramework 6数据上下文?,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/24128033/

10-12 12:20
查看更多