私の場合、DALとして機能し、すべてのCRUD操作を実行するWCFサービスがあります
新しいADO.Netデータサービスについて知りました。少し読んだだけですが、いつどこで使用するかが実際にはわかりません。
さらに追加するために、私の新しいプロジェクトはASP.Net MVCにあるので、おそらくMVCの「M」(モデル)のように動作するWCFサービスではなくADO.NETデータサービスを使用するのが賢明ですか?
私の場合、DALとして機能し、すべてのCRUD操作を実行するWCFサービスがあります
新しいADO.Netデータサービスについて知りました。少し読んだだけですが、いつどこで使用するかが実際にはわかりません。
さらに追加するために、私の新しいプロジェクトはASP.Net MVCにあるので、おそらくMVCの「M」(モデル)のように動作するWCFサービスではなくADO.NETデータサービスを使用するのが賢明ですか?
まず、私のアドバイスは、バックエンドデータモデルが何であるかを認識しないようにMVCコードを作成することです。依存関係を最初から抽象化します。
WCFを使用するかどうかの決定については、作成したデータコンポーネントを再利用するかどうかを決定することをお勧めします。データコードをSilverlight、WPF、またはその他の形式で使用する予定がある場合は、WCFを使用することをお勧めします。
また、いつでもADO.NETデータサービスをWCFコンポーネントでラップし、再利用シナリオを有効にできることを忘れないでください。両方の長所を活用しましょう!
大きな利点の1つは、ADO.NET Data Servicesを使用すると、WCFの場合のように、基本的なCRUD操作用にすべてのサービスを特別に作成する必要がないことです。ADO.NETデータサービスは基本的にこれらの操作を公開するため、より多くのコードの記述とデバッグをビジネスロジックに集中させることができます。
WCFデータサービスとIMOの大きな利点は、サービスレイヤーがCRUDのみに使用される場合です。その中にビジネスロジックはありません(そして必要ありません)。
Tadが指摘したように、再利用は利点ですが、一方で、WCF Data Servicesは、Webアプリまたは任意のコンシューマーにデータをクエリするための非常に柔軟な方法を提供します。WCFでは、ODataが提供するのと同じクエリの柔軟性をコンシューマーに提供するコードを作成する必要があります。
私は最近経験をしました。WCFを使用してサービスレイヤーを作成しましたが、多くの場合、サービス操作はリポジトリの呼び出しにのみ使用されていました。ルールはなく、クエリロジックのみでした。消費者は、結果を返すための基準に合格することができました。
要件が変更され、WCF Data Serviceを使用することで、より簡単に(保守するコードを減らして)作成できることに気付きました。