由于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/