2

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

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

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

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

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

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

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

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

编辑：感谢大家的回复。我现在必须转移到别的东西上，但我会在本周晚些时候有机会时回顾这些。

4

3 回答 3

3

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

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

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

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

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

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

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

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

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

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

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

   Publish changes of the array of prices that have changed.

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

于 2012-04-09T18:38:40.560 回答
0

听起来很直截了当，如果您担心进行过多的数据库调用，您将不得不考虑在中间层缓存数据，也可能在客户端缓存数据。

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

于 2012-04-09T18:39:42.457 回答