2

我在这里有点困惑。

我使用从数据库建模的实体框架创建了我的 POCO 类。

显然，我也想在客户端中使用这些类（如果我想将它们发回并重新附加，任何对它们的簿记都会很好）

我查看了为 WCF 服务引用生成的类，通过 Internet 发送似乎有点冗长，但在安全方面看起来没有任何风险。

然而，我在网上找不到任何关于这样做的信息。我会走上一条完全糟糕的道路吗？

帮助？

编辑：如果我让它们由数据库中的 EntityFramework 生成，我想它们在技术上不是 POCO 类；只是为了消除任何可能的混淆。

4

1 回答 1

2

如果不了解有关您的系统的更多详细信息，这是一个很难回答的问题，但最终在 WCF 服务合同中公开您的 EF 实体是否是正确的路径取决于您正在开发的应用程序的范围和要求。

也许问自己以下问题，希望能指导您做出决定：

  1. 您的关系模型和对象模型是否可能需要发散？这可以由许多因素驱动，但最常见的报告要求可能会强制执行您不想反映在应用程序对象模型中的数据库模式（为了性能）的特定设计。在整个应用程序层中使用 DB 生成的 EF 实体可以将您绑定到此数据库设计
  2. 您是否担心对数据库架构的更改可能需要您的客户重新生成他们的服务引用？同样，在整个应用程序层中使用 EF 实体意味着在您的 DB 模式中实现的任何更改（无论是否与客户端有关）都可能会冒泡到服务接口，可能会破坏客户端与该接口的兼容性
  3. 性能是一个问题吗？正如您所提到的，生成的类很冗长。您可能会通过电线运输不必要的行李，这可以进行优化。
  4. 您是否担心将您的数据库模式和持久性机制的实现细节暴露给您的客户？鉴于您已经从数据库生成了模型，可能有一些属性会公开有关您的模式和持久性机制的信息，这些信息从客户端的角度来看是多余的。

总而言之，在少数情况下公开 EF 实体可能是可以接受的，但通常我会设计更改并实施某种模式，将 EF 实体映射到存储库中的轻量级“持久性无知”POCO层。EF 4.0 确实提供了编写返回 POCO 的上下文的能力，但在我当前的项目中，我们使用 codegen'd 上下文，然后使用automapper将 EF 实体映射到我们的数据合约。在存储库层之外，没有任何人知道 EF 实体，我觉得这可以实现更可维护和更健壮的设计。

于 2010-11-16T08:52:27.547 回答