使用实体框架构建MVC应用程序并使用TDD构建

Question

背景

我即将开始使用MVC 5和EF6创建新应用程序并使用TDD构建它的过程。这是我的第一个MVC应用程序，所以我决定使用它作为一个学习平台，以更好地理解我已经接触过的所有模式和方法，但直到此时才使用它。

我从头开始：

• EF - 模型
• 存储库
• 服务
• UI（控制器视图）

删除存储库

我改变了这个想法，删除了一个层，存储库只是随着我的理解的增长，我可以看到EF（特别是IDbSet）实现了一个存储库模式或排序，而上下文本身就是一个工作单元，所以将它包装得更远抽象，对于这个应用程序至少看起来毫无意义，无论如何。

EF将在服务层抽象

删除Repo并不意味着EF将直接暴露给控制器，因为在大多数情况下我将使用服务向控制器公开某些方法和业务逻辑，但不排他性地排除EF，因为我可以在服务层可以用来构建可以在服务级别和控制器级别使用的特定查询，服务层只是将控制器中的细节映射到EF和数据问题的简单方法。

这对我来说有点啰嗦

服务层

我的服务感觉有点像他们映射某些功能（getById等）的方式的存储库，我不确定它们是自然的方式，或者我对它们的理解是否已经消失并且有更多的信息我找不到更好的知识。

TDD＆amp; EF

我已经阅读了大量关于EF的内容，以及如何以单位方式进行测试，如何不应该担心IQueryable的泄漏以及Linq-to-entities和Linq-to-objects的事实意味着你不会一直得到你想要的结果，但是这导致了我的地狱混乱到我有一个空的测试文件并且我的头完全空白，因为我现在已经结束思考这个过程。

---

更新TDD 包含TDD标签的原因，因为我想也许有人会知道如何在没有存储库的情况下处理这样的事情，因为这是抽象的抽象。他们不会对它进行单元测试并使用其他测试来测试可查询的行为，如集成测试或端到端测试吗？但是由于我的有限理解不会是TDD，因为在这种情况下测试不会驱动我的设计？

---

最后，到点

是：

• EF
• 服务
• UI

架构是一个很好的方法，最初起初至少？

是否有任何良好定义的服务层的良好示例，以便我可以学习，并且它们主要是将具有数据内涵的某些业务操作映射到某些持久性机制（在本例中为ORM）和EF）没有说存储库的持久性要求？

使用TDD的东西，是否可以放弃基本上只调用EF并返回数据的服务方法的单元测试，只选择较慢的集成测试（可能在单独的项目中，因此它们不是主要测试流程的一部分）并且可以在更临时的基础上运行？

有一个星期和我的脑袋感觉它即将爆炸。

Answer 1

大笑我自己肯定有这几个星期之一。 ;）

我对如何构建MVC项目进行了同样的内部讨论，我的结论就是找到对你来说最舒服的东西。

我通常做的是创建以下项目：

1. 核心/域名 - 这里我有我的实体/域模型，以及任何 可以在层之间共享的其他东西：interfaces，for 示例，配置，设置等。
2. 数据/ EF - 此处 我拥有所有与EF相关的代码：DataContext和Mappings （EntityTypeConfiguration）。理想情况下我可以创造另一个 这个使用的版本，比如NHibernate和MySQL，以及其余部分 解决方案将保持不变。
3. 服务 - 这取决于Core 和数据。我在开始时同意它看起来像一个简单的外观 您的数据，但是一旦开始添加功能，您就会找到 这是添加＆＃34; servicemodels＆＃34;的地方。我不是说 ViewModel因为这与Web-ui有关。我的意思是什么 ＆＃34; ServiceModel＆＃34;正在创建一个更简单的域对象版本。 真实示例：隐藏CreatedOn，CreatedBy属性 例。此外，每当你的一个控制器的行为增长到 任何过于简单化的东西，你都应该重构并移动它 服务的逻辑并返回控制器你真正的 需要。
4. Web / UI 这将是您的webApp。它将取决于核心和服务。

你没有提到依赖注入，但你必须明确地看它。

对于测试，您可以使用SqlCompact提供程序测试您的数据，该提供程序为每个测试重新创建数据库，而不是使用完整的SqlExpress。这意味着您的DataContext应该接受connectionString参数。 ;）

我已经学到了很多关于大项目源代码的知识，比如http://www.nopcommerce.com。你也可以看看http://sharparchitecture.net/虽然我打赌你已经看过了。

准备好在EntityFramework中制作一些复杂对象图的噩梦。 ;）

我的最终建议是：找到一些特定的事情并深入研究。过多的抽象将使你无法开始，而开始是练习和理解的关键。