c# - Entity Framework Brainmush Kerfuffle 壮观

Question

我一直在为一个处于早期阶段的大型项目研究 .NET 4 中所有新的 EF 和 WCF 内容，我认为我的大脑现在正式变成了污泥。这是自 1.1 时代以来我在 .NET 中完成的第一个大规模开发工作。像往常一样，所有事情都需要在昨天完成，所以我正在追赶。

这就是我需要敲定的东西 - 任何合理性检查或指导都将不胜感激。该项目本身可以被视为本质上是一个豪华的电子商务系统，具有多个基于 Web 和 Windows 的客户端，连接到具有实时数据的中央服务器。

在服务器端:

• 一个 WCF 服务，实现 使用 EF 连接到 SQL Server 数据存储(可能最终会 拥有数百个表和复杂数据库系统的所有其他设备)
• 用于 EF 和 WCF 必须是可扩展的 属性和类(即字段和 记录)级别，用于验证， 安全、高级审计和 其他自定义逻辑

在客户端:

• WCF 客户端
• 底层类与 服务器端，但有一些 定制不存在
• 当一个对象在 客户，最好只有修改后的 属性应该发送到 服务器
• 客户端 WCF API 详细信息将 可能最终会被出版 公开，如此敏感的服务器端 实现提示不应该 通过 API 泄​​露，除非 绝对不可避免-这 在属性中包含 EF 属性 和类(class)

一般要求:

• 网络效率很重要， 只要我们不想做到 *从第一天起就*高效 - 我可以 预见数据流量和服务器 工作量呈指数增长 几年内
• 首先开发数据库，​​所以 EF 生成的 (POCO, C#) 类 将基于它。不知何故，他们 需要使适合 客户端上的 EF 和 WCF 以及 服务器端，并有不同的层次 定制的，但看起来好像 为每个场景定制

抱歉，这太开放了，但正如我所说，我的大脑完全变成了污泥，我已经把自己搞糊涂了，以至于我被卡住了。

任何人都可以指出如何构建类来完成所有这些的大体方向吗？老实说，非常非常感谢。

Answer 1

不分先后顺序的一些提示:

• POCO 是避免数据对象中 EF 类依赖的方法。
• 考虑添加一个基于数据传输对象的中间层，以应对您传递的“仅修改的属性”(此要求将是棘手的部分)。这些 DTO 将在服务和客户端之间传递以交换修改
• 使用无状态通信模型(无 WCF session )能够非常轻松地实现负载平衡和故障转移。
• 在客户端和服务之间共享 POCO，在服务器上使用子类化来添加内部定制信息。

你最终会在服务器端至少:

• 服务契约(Contract)和 DTO 项目(共享)
• POCO 项目(共享)
• WCF 服务层项目
• 业务逻辑项目(由 WCF 层调用)