实体框架、WCF、客户端和对象上下文问题答案

【问题标题】：Entity Framework, WCF, Clients, and Object Context questions实体框架、WCF、客户端和对象上下文问题
【发布时间】：2012-04-09 18:04:10
【问题描述】：

申请目的：
我正在创建的应用程序将负责许多流程，但我目前正在构建一个价格馈送器，一种保存这些价格的方法，以及将这些价格发送到客户端应用程序的功能（作为概念证明）。这些价格将映射到称为“安全分析”和“安全价格日志”的实体。这两个实体具有相同的属性，但日志会记录收到的每个价格，其中分析只是保存每种证券的最新数据。

我目前正在尝试确定完成此任务的最有效和最稳定的方式。这方面的要求/障碍是：

价格出现非常频繁（有时每秒会收到多个价格）
客户需要实时数据
价格每次进来都需要持久化到数据库中

架构：
我相信这个应用程序适合 n 层架构。我正在考虑包括的层是（请原谅我对这些的命名）：

实体层：构建模型的地方
“工厂”：这将包含我的提要（大约有 10 个）、处理数据的逻辑、将数据转换为实体以及允许向客户公开数据
客户端层：我想向工厂公开数据合约，让客户端可以消费工厂内的实时数据。我做了一些研究，我将使用 Pub-Sub 设计模式通过 WCF Web 服务完成这项工作

因此，有了所有这些背景信息，我的问题就在这里漫无边际：

长期运行的对象上下文有哪些缺点？（我一直在读到我不应该这样做，但没有人明确说明原因或给出对我有用的替代方案）
如果我不断创建新的上下文，我提取到先前上下文中的数据在新上下文中是否可用？我担心当我向客户推送数据并处理许多新价格时，我会过于频繁地从数据库中提取数据。
我目前正在使用自我跟踪实体，并认为它们是此应用程序的正确选择，但如果有人有任何疑虑或智慧可以提供，我将不胜感激。
最后，创建我的“工厂”的最佳项目类型是什么？它将在 IIS 服务器上运行，我希望它接受我的所有数据馈送，并让客户端接受不同的复合（来自多个馈送）数据。我倾向于使用 WCF 服务应用程序，因为它可以让我轻松派生服务合同，但我不确定这是否是正确的选择。

感谢您对此提供的任何帮助。另外，我为这篇文章的长度道歉，我对实体框架的工作方式以及我应该从哪里开始感到非常迷茫。谢谢！

编辑：感谢大家的回复。我现在必须做些别的事情，但我会在本周晚些时候有机会时复习这些内容。

【问题讨论】：

我对此持开放态度，但我们已经开始在 .Net/C# 中工作。你有什么资源可以让我做一些研究吗？
@paulsm4：我看到了你的说法背后的一些背景，但没有解释它，它只是在咆哮开始火焰战争。

标签： c# wcf entity-framework self-tracking-entities objectcontext

【解决方案1】：

你的问题太复杂了。这类问题通常没有令人满意的答案，因为它太开放了，而且还需要对您的需求进行更深入的分析。

关于您的子问题的一些想法：

长时间运行的上下文可能是严重的问题。它有一个lot of disadvantages（每个上下文单个共享实例，每个上下文单个共享工作单元，不是线程安全的），因此请确保在真正选择使用它之前考虑所有这些。如果您将长时间运行的上下文用作单个工作单元，则仍然可以使用它 - 这通常发生在您的上下文与您的 UI 窗口一样长的胖客户端中。
没有。从一个上下文中提取的数据必须手动附加到另一个上下文或再次从数据库加载。它们不会被新的上下文实例自动跟踪，但由于您的下一个问题，尚不清楚您为什么对此感到担忧。
STE 有自己的pros and cons。他们可以solve quite complex problems，但同时他们将您的客户和服务紧密结合在一起。当您传输对象图时，它们还可以显着增加传输的数据量，因为假设的场景是获取对象图并将该图返回服务，即使您只更改了单个关系。 I'm not big fan of STEs。
Pub-Sub 模式和您的实时数据要求：这是应该使用一些更合适的技术的地方。我以前使用过 JMS（在 .NET 中不直接可用，除非您使用来自某些 JMS 提供商（如 IBM XMS 或 Apache NMS）的 API）/Tibco EMS 和 Tibco Randezvous，如果我将 WCF 中可用的 Pub-Sub 模式与真正的 Pub-Sub 基础架构进行比较， WCF 实现就像一个坏笑话。太复杂、太慢并且有很多陷阱，因为它缺少消息中间件。如果您的应用程序对业务至关重要，您有良好的预算（或使用某些消息传递解决方案的现有企业基础设施）并且您的实时数据要求很严格，您应该研究这些可能性。我还没有尝试过，但 RabbitMQ 也应该提供 Pub-Sub 基础架构。

【讨论】：

我们正在使用 RabbitMQ 将价格推送到此应用程序（来自 c++ 提要），因此这可能是一种选择。我喜欢 WCF Web 服务，以方便不同客户端（excel、silverlight、控制台）之间的连接，但我会研究您建议的选项。谢谢

【解决方案2】：

您使用发布/订阅模型的想法很好。但是，您不需要不断提取数据。

您的所有客户都成为听众。新价格出现时的推送事件包括事件参数模型中的价格变化。不确定您是否需要“工厂”模型。

对于实体框架，短期上下文总是最好的选择。虽然您可以在短时间内创建许多，但框架会从连接池中检索它们。

每个上下文都有一个与数据库的连接，该连接始终被视为稀有资源。您应该在最短的时间内挖掘稀有资源。

当您创建一个新的上下文并传递一个对象时，您只需发出一个 Attach 来将该对象重新绑定到上下文。它实际上绑定到对象所在的相应表。

您的 WCF 服务是最好和最高效的方式。但是，您基本上是在编写服务而不是工厂。

对于您的客户：在启动时调用 serviceContext.GetInitialPrices ，您将获得当时的所有价格。订阅以获取价格变化

为您服务：每当价格变化的来源袭击您时：创建上下文附上每条价格记录在上下文中调用 SaveChanges

   Publish changes of the array of prices that have changed.

然后你更大的问题是决定你将使用什么来发布/订阅。

【讨论】：

感谢您的洞察力。在一个测试项目中，我使用 WCF Web 服务来设置发布/订阅模式。开始工作很痛苦，但是一旦我克服了障碍，它就很容易使用。存在限制，我同意 Ladislav 的观点，即存在许多陷阱，那么您对替代方案有什么建议吗？

【解决方案3】：

这听起来很直接，如果您担心进行过多的数据库调用，则必须考虑在中间层缓存数据，也可能在客户端缓存数据。

如果您正在考虑使用实体框架，那听起来是个好主意。在我工作的商店里，我们并没有使用微软所有最新的 .net 玩具。一旦我接触到实体框架，我简直不敢相信我的数据层变得多么简单。它将为您自动完成数小时繁琐且容易出错的数据层编程。

【讨论】：