Question

我正在努力找出构建我的解决方案的好方法。我知道我将使用以下技术，Asp.Net Webforms和Entity Framework 4.1。我的EF模型基于现有数据库。我打算使用EF DbContext生成器来构建我的上下文和实体。这就是事情对我来说有点棘手的地方。

我希望正确分离关注点，提供更好的可测试性，并允许我将业务逻辑与DAL分开。我目前在我的解决方案中有三个项目：Web，Core和Data。我希望依赖是Web - ＆gt;核心＆lt; - 数据，完全没有Web和数据之间的依赖关系。这要求我的实体实际存在于Core中，而不是Data（我的edmx所在的位置）。目前，我的想法是将Entities.tt文件移动到Core并将inputFile更改为指向Data中的edmx以在Core中生成我的实体。但我不确定如何处理Context。它严重依赖于EF，因此我不想简单地将其转移到Core中。我考虑过连接它，创建我自己的IEntities.Context.tt并将其放入Core中。如果我的界面没有创建DbSets和DbContext，我担心的是功能丧失。

我对此一直有两个想法，1）在Core中放入一个引用System.Data.Entity，2）不要使用DbSet并将其替换为ICollection（或一些这样的通用容器）并包装DbContext作为我界面中的一个对象。

任何见解都将非常感激。谢谢。

Answer 1

您可以使用许多不同的模式，但立即想到两个：

1）添加业务/服务层 - 这将在您的数据层和表示层之间进行抽象。这是我最常使用的方法 - 使用AutoMapper和依赖注入（我喜欢Ninject）来使猴子更容易工作。您的业务层将公开其自己的数据库对象版本（不推荐），或者与您的业务模型相关的对象（更强大的方法）。

2）使用Inversion of Control模式 - 目前非常受欢迎，尽管我还没有在现实生活中给它一个bash。显然非常适合TDD /模拟等...它基本上意味着您的数据层依赖于您的业务层而不是相反。

仅供参考 - 我的“核心”或“通用”程序集对我的业务或数据层一无所知 - 它们只提供与平台无关的帮助程序和公共类 - 如果我想创建常见的MVC功能，例如，我将创建一个Company.MVC.Core汇编。

Answer 2

如果您的解决方案完全是绿地，那么我喜欢在实体框架中使用代码优先方法（原谅无耻的插件，但我在我的博客上放了关于此http://www.terric.co.uk/code-first-entity-framework-and-sql-migrations/的教程）。我喜欢它给我的控件，当我生成.edmx时我似乎无法获得。

转到结构，我通常将项目的各个层分隔成单独的程序集：域（和数据）和使用以下文件夹（名称空间）构建的WebUI：

Domain (business layer and data layer assembly)
    Data (contains my EF data context and Interface to the context)
    Entities (contains my POCO objects for the context)

WebUI (presentation layer assembly)
    Infrastructure (contains my dependency inject initialiser)

我从不DI我的实体，而是使用我的表示层中的混凝土，但是上下文我总是DI，因为我可能想要/必须使用ADO.Net（特别是对于遗留应用程序）我的域层仍将使用ADO.Net读/写我的POCO实体。这样，当我最终获得使用我的遗留应用程序实现ORM的范围时，我可以简单地DI我的域的ORM版本。

作为脚注，如果您遵循存储库模式，您可以始终将它们与DI存储库连接起来。无论哪种方式，您的POCO都应该特定于解决方案，因此基础数据结构不会经常发生显着变化，因此我从不对它们进行DI。

什么是在webforms中使用Entity Framework的适当抽象

2 个答案: