2

アプリケーションの目的:
私が作成しているアプリケーションは多くのプロセスを担当しますが、現在、価格フィーダー、これらの価格を保存する方法、およびこれらの価格をクライアント アプリケーションに送信する機能 (概念実証として) を構築しています。これらの価格は、「Security Analytics」および「Security Price Log」と呼ばれるエンティティにマッピングされます。これら 2 つのエンティティは同じプロパティを持ちますが、ログには受け取った各価格の記録が保持され、分析では各証券の最新データが保持されます。

現在、これを完了するための最も効率的で安定した方法を決定しようとしています。これの要件/オブスタブルは次のとおりです。

  • 価格は非常に頻繁に表示されます (毎秒複数の価格が表示されることがあります)
  • クライアントはリアルタイム データを必要とします
  • 価格は、入力されるたびにデータベースに永続化する必要があります

アーキテクチャ:
このアプリケーションは n 層アーキテクチャに適していると思います。含めることを考えているレイヤーは次のとおりです（これらの名前を付けてすみません）：

  • エンティティ層:モデルが構築される場所
  • 「工場」:これには、私のフィード (約 10 個あります)、データを処理するためのロジック、エンティティへのデータの変換、およびクライアントへのデータの公開を可能にするものが含まれます。
  • クライアント層:ファクトリにデータ コントラクトを公開して、クライアントがファクトリ内のリアルタイム データを使用できるようにしたいと考えています。私はいくつかの調査を行い、Pub-Sub デザイン パターンを使用して WCF Web サービスを通じてこれを完了します

したがって、そのすべての背景情報とここでのとりとめのない私の質問は次のとおりです。

  • 実行時間の長いオブジェクト コンテキストを持つことの欠点は何ですか? （私はこれを行うべきではないことを読み続けましたが、誰も明確に理由を述べたり、私にとってうまくいく代替手段を提供したりしませんでした）
  • 常に新しいコンテキストを作成している場合、以前のコンテキストに取り込んだデータは新しいコンテキストで利用できますか? クライアントにデータをプッシュして多くの新しい価格を処理しているときに、データベースから頻繁にデータをプルするのではないかと心配しています。
  • 私は現在自己追跡エンティティを使用しており、このアプリケーションの正しい選択であると考えていますが、懸念や知恵があれば、それを提供していただければ幸いです。
  • 最後に、「工場」を作成するのに最適なタイプのプロジェクトは何ですか? これは IIS サーバー上で実行され、すべてのデータ フィードを受け入れ、クライアントが (複数のフィードからの) 異なる複合データを受け入れるようにしたいと考えています。サービス コントラクトを簡単に取得できるため、WCF サービス アプリケーションに傾倒していますが、これが正しい選択であるかどうかはわかりません。

これに関してあなたが提供できるどんな助けも大歓迎です。また、これが長くなってしまったことをお詫びします。エンティティ フレームワークがどのように機能し、どこから始めるべきかについて、私はかなり迷っています。ありがとう！

編集：皆さん、ご回答ありがとうございます。今は別のことに取り掛かる必要がありますが、機会があれば今週中にレビューします。

4

3 に答える 3

3

あなたの質問は複雑すぎます。この種の質問は、あまりにもオープンエンドであり、要件をより深く分析する必要があるため、通常、満足のいく答えはありません。

サブ質問についてのいくつかの考え:

  • 長時間実行されるコンテキストは重大な問題になる可能性があります。これには多くの欠点(コンテキストごとに 1 つの共有インスタンス、コンテキストごとに 1 つの共有作業単位、スレッドセーフではない) があるため、実際に使用することを選択する前に、それらすべてについて検討してください。長時間実行されるコンテキストは、単一の作業単位として使用する場合でも使用できます。これは通常、UI ウィンドウと同じくらいコンテキストが存続するシック クライアントで発生します。
  • いいえ。あるコンテキストから取得したデータは、別のコンテキストに手動でアタッチするか、データベースから再度ロードする必要があります。それらは新しいコンテキスト インスタンスによって自動的に追跡されるわけではありませんが、次の質問のためになぜこれについて懸念するのかが明確ではありません。
  • STE には長所と短所があります。それらは非常に複雑な問題を解決できますが、同時にクライアントとサービスを緊密に結合します。また、オブジェクト グラフを転送すると、転送されるデータ量が大幅に増加する可能性があります。これは、1 つのリレーションだけを変更した場合でも、オブジェクト グラフを取得してそのグラフをサービスに戻すことが想定されているためです。私は STE の大ファンではありません。
  • Pub-Sub パターンとリアルタイム データの要件: これは、より適切なテクノロジを使用する必要があるものです。JMS を使用しました (IBM XMS や Apache NMS などの JMS プロバイダーの API を使用しない限り、.NET では直接使用できません) / 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

あまりにも多くのデータベース呼び出しを行うことを懸念している場合は、中間層および場合によってはクライアントでデータをキャッシュすることを検討する必要があるというのは、非常に単純なことのように思えます。

Entity Framework の使用を検討している場合、それは素晴らしいアイデアのように思えます。私が働いているショップでは、Microsoft の最新の .net おもちゃをすべて使用しているわけではありません。Entity Framework を手に入れると、信じられないほどデータ層がシンプルになりました。何時間にもわたる退屈でエラーが発生しやすいデータ層プログラミングを自動化します。

于 2012-04-09T18:39:42.457 に答える