实体框架/WCF——安全/智能地将entityObjects发送到Silverlight客户端？

发布于 2024-10-02 18:51:25 字数 306 浏览 2 评论 0原文

我在这里有点困惑。

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

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

我查看了为 WCF 服务引用生成的类，它通过互联网发送似乎有点冗长，但从安全角度来看，其中似乎没有任何风险。

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

帮助？

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

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

虫児飞 2024-10-09 18:51:25

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

也许问自己以下问题，这些问题有望指导您的决定：

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

总之，在有限的情况下，暴露 EF 实体可能是可以接受的，但通常我会设计更改并实现某种模式，将 EF 实体映射到您的 < 处的轻量级“持久性无知”POCO。 href="http://msdn.microsoft.com/en-us/library/ff649690.aspx" rel="nofollow">存储库层。 EF 4.0 确实提供了编写返回 POCO 的上下文的能力，但在我当前的项目中，我们使用 codegen'd 上下文，然后使用 automapper 将 EF 实体映射到我们的数据契约。在存储库层之外，没有任何东西知道 EF 实体，我认为这可以实现更可维护和更健壮的设计。

This is a difficult question to answer without knowing more details about your system, but ultimately whether exposing your EF entities in the WCF service contract is the right path or not is influenced by the scope and requirements of the application you are developing.

Perhaps ask yourself the following questions which will hopefully guide your decision:

Is it likely your relational model and object model will need to diverge? This can be driven by a number of factors, but most commonly reporting requirements may enforce a certain design on your database schema (for performance) that you do not want to reflect in your application object model. Using the DB generated EF entities throughout the application layers can bind you to this database design
Are you concerned that changes to your database schema may require your clients to regenerate their service references? Again, using the EF entities throughout your application tiers means any changes implemented in your DB schema (whether of concern to the client or not) may bubble up to the service interface, potentially breaking client compatability with that interface
Is performance a concern? As you mentioned, the generated classes are verbose. You are likely to be transporting unnecessary baggage across the wire, which could be optimized.
Are you concerned about exposing the implementation details of your database schema and persistence mechanism on the wire and to your clients? Given you have generated the model from the database there are likely to be properties that expose information about your schema and persistence mechanism that are redundant from a client's perspective.

In summary there may be a limited number of cases where exposing the EF entities may be acceptable but typically I would design for change and implement some sort of pattern where you map your EF entities to light-weight "persistence-ignorant" POCOs at your repository layer. EF 4.0 does provide the ability to code up a context that returns POCOs, but on my current project we use the codegen'd context and then use automapper to map the EF entities to our data contracts. Outside of the repository layer nothing is aware of the EF entities and I feel this allows for a more maintainable and robust design.

回复收藏 0 原文

~没有更多了~