2011-10-24 14 views
0

私たちは、Webベースの保険システム(引用、ポリシー管理、請求管理、レート作成など)のアーキテクチャ設計段階にあります。このアプリケーションは、異なるモジュールで構成されます。私たちはASP.Net MVCとSQL Serverを使いたいと考えています。ビジネスロジック層では、WCFサービスを使用してBLLを分離するか、BLLをモデルの一部にするかはちょっと混乱します。なぜ私たちの状況にSOAが必要なのか、なぜSOAに関係しないのか、あなたの意見を高く評価します。SOAとASP.net MVC

答えて

2

あなたのサービスが何か他のもの、SOAによって消費されることを絶対に確信した場合でも、ヒットしてもYAGNIを実行する必要はありません。すべての人が、「ちょうどの場合に」単純なSOAアーチを構築し、SOAアーチではなく「productXXXを動かすサービス」になることもしばしばあります。一度それが起こると、製品を開発または保守している人々は、サービスが開発に長くかかる原因となる不要な無駄であることを認識し始めます。

+1

私の経験では、 "power product XXX"というサービスはSOAのポイントです。多くのシステムはSOAなしではじまり、維持管理が難しくなると実装します。現時点では、SOAのメリットは共通のインフラストラクチャを作成することだけではなく、アプリケーションの相互作用を実際に設計する必要があります。つまり、サービスを簡素化してリファクタリングし、 ...それは完全に大丈夫です。 –

1

MVCアプリケーションでは、ほとんどのビジネスロジックはモデル内にあり、一部はコントローラ内にあることがあります。 WCFを使用して、モデル/ビジネスドメインをサポートするデータサービスレイヤーを作成できます。保険システムとそのデータがMVCアプリ以外のものによって消費されると思うなら、あなたは間違いなくサービスオリエンテーション(すなわち、WCFサービス)をサポートする設計を行うべきです。