背景
我即将开始用MVC 5和EF6创建一个新的应用程序，并用TDD构建它。这是我的第一个MVC应用程序，所以我决定把它作为一个学习平台来更好地理解我接触过的一系列模式和方法，但在这之前我只使用过这些模式和方法。
我从脑海中的这个开始：
- EF-型号
- 存储库
- 服务
- UI(控制器视图(
删除存储库
我将这种想法转移到了删除一层，即存储库。随着我的理解不断加深，我可以看到EF(特别是IDbSet(实现了一个存储库模式或排序，上下文本身就是一个工作单元，所以在这个级别上，将其包括在进一步的抽象中，至少对这个应用程序来说似乎毫无意义。
EF将在服务层抽象
删除回购并不意味着EF将直接暴露给控制器，因为在大多数情况下，我将使用服务向控制器暴露某些方法和业务逻辑，但不排除EF，因为我可以在服务之外使用它来做一些事情，比如构建可以在服务级别和控制器级别使用的特定查询，服务层将只是将细节从控制器映射到EF和数据关注点的更简单的方式。
这对我来说有点麻烦
服务层
我的服务在映射某些函数(getById等(的方式上感觉有点像存储库，我不确定这些函数是否是自然的，或者我对它们的理解是否还很差，我找不到更多的信息来提高我的知识。
TDD&EF
我读了很多关于EF的文章，以及你如何使用单元进行测试，你如何不应该因为IQueryable的泄漏而烦恼，以及Linq对实体和Linq对对象意味着你不会一直得到你想要的结果，但这让我非常困惑，以至于我有一个空的测试文件，我的头脑完全空白，因为我现在对这个过程思考过度了。
TDD更新之所以包含TDD标记，是因为我认为也许有人会知道他们如何在没有存储库的情况下处理这样的事情，因为这是为了抽象而抽象的。他们会不会针对它进行单元测试，并使用其他测试来测试可查询的行为，比如集成测试或端到端测试？但从我有限的理解来看，这不会是TDD，因为在这种情况下，测试不会驱动我的设计？
最后，切中要害
是：
- EF
- 服务
- UI
架构是一条很好的道路，至少在最初是这样吗？
有没有定义良好的服务层的好例子可以让我学习，它们主要是一种将具有数据含义的某些业务操作映射到持久性机制(在本例中是ORM和EF(的方法，而不需要存储库之类的持久性要求？
对于TDD的东西，可以放弃对服务方法的单元测试吗？这些服务方法基本上只是调用EF并返回数据，而只是选择较慢的集成测试(可能是在一个单独的项目中，所以它们不是主要测试流的一部分，可以在更特别的基础上运行？
经历了这样的一周，我的大脑感觉快要爆炸了。
Lol我自己肯定也经历过这样的一周。(
关于如何构建MVC项目，我也进行过类似的内部讨论，我的结论是找到对你来说最舒服的东西。
我通常做的是创建以下项目：
- 核心/域-这里有我的实体/域模型，以及任何其他可以在层之间共享的东西：接口例如，配置、设置等等
- 数据/EF-此处我有我所有依赖EF的代码：DataContext和Mappings(EntityTypeConfiguration(。理想情况下，我可以创建另一个使用的版本，比如NHibernate和MySQL，以及解决方案将保持不变
- 服务-这取决于Core和数据。我同意一开始它看起来像一个简单的门面添加到您的数据中，但一旦您开始添加功能，您就会发现这是添加"服务模型"的地方。我不是说ViewModel，因为这与Web ui非常相关。我的意思是"ServiceModel"正在创建域对象的更简单版本。真实示例：隐藏您的CreatedOn、CreatedBy属性，用于实例此外，每当控制器的某个操作增长到任何过于简单的东西，你都应该重构并移动它逻辑到服务并返回到控制器需要
- Web/UI这将是您的webApp。这将取决于核心和服务
你没有提到依赖注入，但你必须明确地看看它
对于测试，您可以使用SqlCompact提供程序来测试数据，该提供程序为每个测试重新创建数据库，而不是使用完整的SqlExpress。这意味着您的DataContext应该接受connectionString参数。；(
看到大型项目的源代码，我学到了很多，比如http://www.nopcommerce.com.你也可以看看http://sharparchitecture.net/尽管我打赌你已经看到了。
准备好在EntityFramework中做一些复杂对象图的噩梦。(
我最后的建议是：找一些具体的事情去做，深入研究。太多的抽象会让你无法开始，而开始是练习和理解的关键。