首先,我对此问题的开放性质表示歉意。然而,我已经瘫痪了好几个月,尽管同意搜索,仍然无法克服这一点。构建可测试的MVC3和EF 4.1应用程序
我一直在研究MVC/EF应用程序一段时间。我想了解如何设计和构建由Entity Framework(4.1)支持的可测试MVC3应用程序。您可以在here,here和here这个主题上看到几个问题。
我不想让它复杂化,但我希望它是一个可以增长的声音,松散耦合的设计。就我的理解,下面是非常最低限度所需的组件:
MVC应用程序
这是非常薄。尽可能少的逻辑在这里。我的观点具有尽可能少的条件逻辑,我的观点模型不过是POCO,而我的控制器只是简单地处理视图模型和领域模型之间的映射,并呼叫服务。
服务层+接口(单独的程序集)
这是我所有的业务逻辑去的地方。这样做的目标是能够掌控任何瘦客户端(表单应用程序,移动应用程序,Web服务),以暴露我的应用程序的内心。服务层的接口位于另一个程序集中。
核心工具/交叉+接口(单独的组件)
这是东西,我建立这不是具体到我的应用程序,而不是框架或我使用任何第三方插件的一部分。再次,这些组件的接口位于它们自己的组件中。
存储库(EF上下文)
这是我的域模型和我的数据库之间的接口。我的服务层使用它来通过域模型检索/修改我的数据库。
域模型(EF POCOs)
EF4生成的POCOs。其中的一些可以被扩展为方便起见,以其它嵌套属性或计算的特性(如Order.Total = Order.Details.Sum(d => d.Price)
)
IoC容器
这就是用于注射我的混凝土/假依赖(服务/实用程序)到MVC应用程序&服务。构造函数注入只用于整个。
这里就是我挣扎:
1)集成测试是适当的对单元测试。例如,一些程序集是否需要混合两者,或者是主要针对MVC应用程序的集成测试以及我的服务&实用程序的单元测试?
2)难道我打扰写存储库/域模型代码的测试吗?当然就POCO而言,这不适用。但是,当我延长我的POCO和计算属性时呢?
3)用于存储库的正确模式。我知道这是非常主观的,因为每次我看到这个讨论时,似乎每个人都有不同的方法。因此,很难确定要走哪条路。例如,我是否会推出自己的存储库,或者直接使用EF(DbContext
)?
4)当我为我的服务编写测试时,是模拟我的存储库还是使用SQL Lite构建模拟数据库并对其进行测试? (见辩论here和here)。
5)这是一件全有或无关的事情,如果我做任何测试,我应该测试一切?或者,是否任何测试都比没有测试更好?如果是后者,哪里是最重要的领域(我在考虑服务层)?
6)是否有任何好的书籍,文章或示例应用程序可以帮助我解答大部分这些问题?
我认为这就够了。如果结果太开放了,让我知道,我很乐意关闭。但是,再次,我已经花了数月的时间试图独自一人解决这个问题,但没有运气。
谢谢,拉迪斯拉夫。我知道这不是一个容易回答的问题,并且我感谢你无论如何都在刺探它。为了澄清,我可能会有一些愚蠢的存储库,并将LINQ-to-entities逻辑保留在我的服务层中。所以它真的会在我的服务层中承担很多责任(业务+查询逻辑)。这是否会导致它自己的问题 - 即对此进行权衡与为我的LINQ-to-entities逻辑创建存储库并使我的服务层严格遵守业务逻辑有什么关系?再次,我知道这是主观的,我只是想确保我理解这种权衡。 –
_作为一个离题的方面说明,我想感谢你对SO社区的贡献,尤其是我的问题,因为你经常会回答我的很多问题,其中大部分似乎都需要很多时间和你的想法。它不会被忽视._ –