我正在按照Scott Gu的一个教程来引用一个名为DbContext的类.我无法在框架4上的任何命名空间中找到它,在我看来,它已从CT4 DbContext重命名为.net4 System.Data.Linq.DataContext.我的假设是否正确？
首先,我为这个问题的开放性质道歉.然而,我已经瘫痪了几个月,尽管经过了同意搜索,仍然无法超越这个.
我一直在研究MVC/EF应用程序.我试图了解如何设计和构建由Entity Framework(4.1)支持的可测试的MVC3应用程序.你可以在这里,这里和这里看到我就这个主题提出的一些问题.
我试图不要过度复杂化,但我希望它是一种声音松散耦合的设计,可以增长.我理解它的方式,以下是几乎所有必需的组件:
MVC应用程序
这非常薄.尽可能少的逻辑在这里.我的视图尽可能少的条件逻辑,我的视图模型永远不会超过POCO,我的控制器只是处理视图模型和域模型之间的映射,并调用服务.
服务层+接口(单独的程序集)
这是我所有业务逻辑的用武之地.这样做的目的是能够在此基础上打击任何瘦客户端(表单应用程序,移动应用程序,Web服务)以暴露我的应用程序的内容.服务层的接口位于另一个程序集中.
核心实用程序/交叉
切换+接口(单独的程序集)这是我构建的不是我的应用程序特有的东西,但不是框架或我正在使用的任何第三方插件的一部分.同样,这些组件的接口也位于它们自己的程序集中.
存储库(EF上下文)
这是我的域模型和我的数据库之间的接口.我的服务层使用它来通过域模型检索/修改我的数据库.
域模型(EF POCO)
EF4生成的POCO.其中一些可以扩展以方便其他嵌套属性或计算属性(例如Order.Total = Order.Details.Sum(d => d.Price))
IoC容器
这是用于将我的具体/假依赖(服务/实用程序)注入MVC应用程序和服务的内容.构造函数注入仅在整个过程中使用.
这是我在努力的地方:
1)当集成测试适合单元测试时.例如,某些程序集是否需要两者兼容,或者主要是针对MVC应用程序的集成测试以及针对我的服务和实用程序的单元测试？
2)我是否打算针对存储库/域模型代码编写测试？当然,对于POCO,这是不适用的.但是当我扩展我的POCO w /计算属性时呢？
3)用于存储库的正确模式.我知道这是非常主观的,因为每当我看到这个讨论时,似乎每个人都有不同的方法.因此,很难弄清楚要走哪条路.例如,我可以滚动自己的存储库,还是直接使用EF(DbContext)？
4)当我为我的服务编写测试时,我是否会模拟我的存储库,或者我是否使用SQL Lite来构建模拟数据库并对其进行测试？(见这里和这里的辩论).
5)这是一个全有或全无的事情,如果我做任何测试,我应该测试一切吗？或者,是否任何测试都比没有测试更好？如果是后者,哪个更重要的领域首先击中(我在考虑服务层)？
6)是否有任何好的书籍,文章或示例应用程序可以帮助我回答大部分问题？
我认为现在已经够了.如果这最终过于开放,请告诉我,我很乐意关闭.但是,我已经花了好几个月的时间试图自己解决这个问题而没有运气.