我们正在设计一个包含大约100个表格和复杂业务逻辑的应用程序。 Windows Forms将用于客户端，WCF服务与服务器上的MSSQL一起使用。在基于WCF的企业应用程序中使用哪种实体框架
自定义DTO用于客户端 - 服务器通信，业务实体不分配。
使用哪个实体框架的变形（为什么）：
数据库优先方法是一项要求。
另外，是否值得实施Repository模式？看起来有点多余，因为在映射本身中有一个抽象级别，而在DTO的使用中有一个抽象级别。我目前正在倾向于为每个返回IQueryable的实体使用自动生成的可扩展存储库，只是为了有一个地方可以放置通用查询，但仍允许直接从服务层查询实体模型。
要使用哪种变体？基本上，一旦你有自定义的DTO，唯一的问题是你想控制实体代码（它们的基类）并使它们独立于EF？你想先使用代码吗？如果所有问题的答案都是否定的，那么你可以使用EntityObjects。如果你想要实体持久化无知或使用自定义基类，你应该去POCO。如果你想使用代码第一或新的DbContext API，你将需要EF 4.1。一些相关的话题：
有更多的事情在设计业务层时需要考虑的。您应该知道在WCF中使用EF时必须处理的复杂问题。您的服务将向WinForms应用程序提供数据，它将以“分离模式”与它们一起工作。一旦用户将完成他想做的所有更改，他会将数据发回服务。但问题来了 - 你必须告诉EF什么改变了。例如，如果您允许用户更改所有订单商品的订单（更改商品数量，添加新商品，删除一些商品）you must say EF exactly what has changed，添加了什么以及删除了什么。当你使用单个实体时，这很容易，但是一旦你允许用户改变对象图（特别是多对多关系），那么它就非常困难。最常见的解决方案是加载整个图形，并将输入DTO的状态合并到加载和附加的图形中。其他解决方案是使用Self tracking entities而不是EntityObjects/POCO + DTO。
当讨论存储库时，我会引用你到this answer，它指的是讨论存储库的许多其他答案，它们可能的冗余和使用它们时可能出现的错误，只是为了使代码可测试。通常，每个图层只有在对图层有实际需求的情况下才能添加 - 这是因为更好地分离了关注点。
POCO的主要优势是这些类可以为您的DTO，所以如果您已经有了自定义的DTO，那么POCO看起来有点多余。但是，还有一些其他的优点可能会对你有价值，也可能没有价值，因为你没有提到单元测试的要求。如果你打算编写单元测试，那么POCO仍然是一条路。由于您不会使用代码优先功能（免责声明：我只使用了4.0 POCO，所以我不会非常熟悉这些代码之间的细微差别，所以您可能不会注意到4.0 POCO和4.1之间的很大差异。两个，但它们似乎差不多 - 基本上我已经在4.0中使用POCO了，并且没有看到任何让我想要更新所有东西来使用4.1的东西）。
此外，根据是否打算对此图层进行单元测试，在使用实体框架时，在实现工作模式库/工作单元时仍然有价值。它用来抽象出数据访问逻辑（上下文），而不是实体本身，并且允许你在单元测试中嘲笑你的上下文。我所做的是为我的上下文复制T4模板并使用它创建界面，然后编辑上下文的T4模板并使其实现该界面并使用IObjectSet<T>而不是ObjectSet<T>。因此，而不是：
public class MyEntitiesContext
{
public ObjectSet<MyClass> MyEntities
...
}
我结束了：
public interface IMyEntitiesContext
{
public IObjectSet<MyClass> MyEntities;
}
和
public class MyEntitiesContext : IMyEntitiesContext
{
public IObjectSet<MyClass> MyEntities
...
}
所以我想它真的归结到你是否计划为此编写单元测试层。如果你不会做任何需要嘲笑你的上下文进行测试的事情，那么最简单的方法就是使用4.0 EntityObjects，因为你不打算在你的层之间传递你的实体，所以最简单的方法是实行。如果您打算使用模拟，那么您可能会想使用POCO并实施存储库/工作单元。