2

現在作業中のASP.NETMVC3アプリケーションがあります。私は、ビジネスロジックを含み、コントローラーによって使用されるサービスレイヤーを実装しています。サービス自体はデータアクセスにリポジトリを利用し、リポジトリはエンティティフレームワークを使用してデータベースと通信します。

つまり、上から下へは、コントローラー>サービスレイヤー>リポジトリ（各サービスレイヤーは単一の注入可能なリポジトリに依存します）>エンティティフレームワーク>単一データベースです。

UserService、EventService、PaymentServiceなどのアイテムを作成しています。

サービスレイヤーには、次のような機能があります。

  • ChargePaymentCard(int cardId, decimal amount)（PaymentServiceの一部）
  • ActivateEvent(int eventId)（EventServiceの一部）
  • SendValidationEmail(int userId)（UserServiceの一部）

また、これを使用している2番目の例として、これらのサービスの1つを利用するスケジュールされたタスクとして実行される別の単純なコンソールアプリケーションがあります。これらのサービスの複数を使用する必要がある次の2番目のWebアプリケーションもあります。

さらに、物事を分割し（単一のデータベースなど）、将来的にサービス指向アーキテクチャーに移行し、これらの一部をWebサービスに分割すること（おそらく、 -.NETアプリはいつか）。私は、SOAへの飛躍を今後の苦痛を和らげる可能性のあるステップに目を光らせてきました。

サービスごとに個別のアセンブリ（DLL）を作成する方法を開始しましたが、間違った方法で開始したのではないかと思います。私は柔軟性を持ち、物事をゆるく結びつけようとしていますが、このパスは（SOAに向けて、または一般的に）私を助けてくれますか、それとも単に複雑さを追加するだけですか？代わりに、サービスレイヤー全体を含む単一のアセンブリ/ dllを作成し、サービスを使用する必要がある場所でその単一のアセンブリを使用する必要がありますか？

私が始めているパスの意味がわからないので、これに関する助けをいただければ幸いです！

4

3 に答える 3

2

IMO - 答えは、アプリケーションの多くの要因に依存するということです。

自明ではないアプリケーションを構築していると仮定します (つまり、SOA を学ぶための大学/趣味のプロジェクトではありません)。

  • ユーザー サービス / イベント サービス / 支払いサービス -- 独自の DLL を作成し、このサービスを使用するアプリケーションが複数あり、DLL を別のアプリケーションと共有するリスクが大きすぎる場合は、WCF サービスとして公開します
    -- これらのサービスは、相互依存関係がなく、個々の領域に焦点を当てる必要があります
    -- 注: これらのサービスは、ロギング、認証、データ アクセスなどのいくつかの共通サービスを共有する場合があります。

  • 構成サービスの作成 -- このサービスは、他のすべてのサービスにわたってコールの構成を行います
    -- たとえば、注文があり、ビジネス フローが [注文] > [ユーザーの存在を確認] (ユーザー サービス) > [注文を発行] である場合event (Event Service) > Confirm Payment (Payment Service)
    -- このようなサービス呼び出しのすべての構成は、このレイヤーで処理できます
    -- ここでも、環境によっては、このサービスを独自の DLL として公開したり、公開したりすることを選択できます。それを WCF として
    -- 注: これは、他のサービスへの参照を共有する唯一のサービスであり、構成の単一ポイントになります。

このレイアウトでは、サービスを単独で操作したい場合はサービスを直接呼び出すオプションがあり、完了するためにさまざまなサービスを構成する必要があるビジネス ワークフローが必要な場合は、構成サービスを呼び出す必要があります。トランザクション。

出発点として、SOA アーキテクチャーに関する本を一読することをお勧めします。多くの概念を理解するのに役立ちます。

この回答を意味のあるものにするために、できるだけ短くしようとしました。同じことを行う方法はたくさんあります。これは可能な方法の 1 つにすぎません。

HTH。

于 2012-05-02T17:18:48.517 に答える
1

サービスごとに 1 つの DLL を持つことは、悪い考えのように思えます。Microsoft によると、パフォーマンスへの影響により、複数の小さなアセンブリよりも 1 つの大きなアセンブリを使用する必要があります (ここからこの投稿を介して)。

基本サービスまたはコア サービスを別のプロジェクトに分割し、ほとんどの (すべてではないにしても) サービスをそこに保持します。ニーズによっては、Web プロジェクトまたはコンソール アプリのコンテキストでのみ意味を持ち、他の場所では意味をなさないサービスがある場合があります。これらのサービスは「コア」サービス層の一部ではなく、適切なプロジェクトに存在する必要があります。

于 2012-05-02T16:57:21.317 に答える
0

サービスをコンシューマーから分離することをお勧めします。私たちの人々には、2つのレベルの分離があります。以前は、すべてのサービスインターフェイスを1つのVisualStudioプロジェクトにグループ化していました。すべてのサービス実装は、別のプロジェクトにグループ化されます。サービスの利用者は2つのdllを参照する必要がありますが、ソリューションの保守性と拡張性が向上します。サービスの複数の実装を持つことができます。たとえば、サービスインターフェイスは、インターフェイスプロジェクトでWebSearchのコントラクトを定義できます。また、Google検索、Bing検索、Yahoo検索などのさまざまな検索サービスプロバイダーを介して、WebSearchの複数の実装が存在する可能性があります。

于 2012-05-10T07:19:20.757 に答える