相关疑难解决方法(0)

我研究了一些关于我可以用来对DbContext进行单元测试的技术的信息.我想在上下文中添加一些内存数据,以便我的测试可以针对它运行.我正在使用Database-First方法.

我发现最有用的两篇文章是这个和这个.该方法依赖于创建一个MyContext和FakeContext都将实现的IContext接口,允许模拟上下文.

但是,正如某些人所指出 的 那样,我试图避免使用存储库来抽象EF,因为EF 4.1已经通过DbSet和DbContext实现了存储库和工作单元模式,我真的想保留EF实现的所有功能.团队无需使用通用存储库维护它们,正如我在其他项目中所做的那样(这有点痛苦).

使用IContext会引导我走同一条路(或者不是吗？).

我考虑创建一个继承自主MyContext的FakeContext,从而利用它下面的DbContext来运行我的测试,而不需要访问数据库.我找不到类似的实现,所以我希望有人可以帮助我.

我做错了什么,或者这会导致我遇到一些我没想到的问题？

我有一个使用ASP.NET MVC,Unity和Linq to SQL的应用程序.

统一寄存器容器的类型AcmeDataContext,从继承System.Data.Linq.DataContext,具有LifetimeManager使用HttpContext.

有一个控制器工厂使用统一容器获取控制器实例.我在构造函数上设置了所有依赖项,如下所示:

// Initialize a new instance of the EmployeeController class
public EmployeeController(IEmployeeService service)

// Initializes a new instance of the EmployeeService class
public EmployeeService(IEmployeeRepository repository) : IEmployeeService

// Initialize a new instance of the EmployeeRepository class
public EmployeeRepository(AcmeDataContext dataContext) : IEmployeeRepository

每当需要构造函数时,unity容器就会解析一个连接,用于解析数据上下文,然后是存储库,然后是服务,最后是控制器.

问题是IEmployeeRepository暴露SubmitChanges方法,因为服务类没有DataContext引用.

我被告知应该从存储库外部管理工作单元,所以我似乎应该SubmitChanges从我的存储库中删除它.这是为什么？

如果这是真的,这是否意味着我必须声明一个IUnitOfWork接口并使每个服务类依赖它？我还能如何让我的服务类来管理工作单元？

我已经阅读了几十篇关于试图在业务逻辑中模拟\假EF的PRO和CON的帖子.我还没有决定做什么 - 但我知道的一件事是 - 我必须将查询与业务逻辑分开.在这篇文章中我看到拉迪斯拉夫回答说有两种好方法:

1. 让它们成为它们的位置,并使用自定义扩展方法,查询视图,映射数据库视图或自定义定义查询来定义可重用部分.
2. 将每个查询作为方法公开在某个单独的类上.该方法不得暴露IQueryable,也不得接受Expression作为参数=整个查询逻辑必须包含在方法中.但这将使您的类覆盖相关方法很像存储库(唯一可以被模拟或伪造的).此实现与存储过程使用的实现很接近.

1. 您认为哪种方法更好？
2. 是否有任何缺点将查询放在自己的位置？(可能会从EF或类似的东西中丢失一些功能)

3. 我是否必须封装最简单的查询,例如:

   using (MyDbContext entities = new MyDbContext)
   {
       User user = entities.Users.Find(userId);  // ENCAPSULATE THIS ?
   
       // Some BL Code here
   }
   

   Run Code Online (Sandbox Code Playgroud)