RIAサービスのドメインサービスでより複雑な操作を実装する方法について頭を悩ませています。これはすべて、Beta2のSilverlight4、VS 2010、および.NetFramework4です。
ゴール
LinqToEntitiesDomainServiceで、次のような署名を持つ操作を作成できればと思います。
public UnwieldyOperationResult PerformUnwieldyOperation( UnwieldyOperationParameters p );
この操作はパラメーターのコレクションを取り、DomainServiceCRUD機能を介して操作されるエンティティのさまざまなインスタンスとタイプを更新するかなり複雑な操作を実行するという考え方です。
問題
私が直面した当面の問題は、カスタム型をパラメーターとしてメソッドに渡すことが許可されていないように見えることです。これらの行に沿った何かが戻り値に使用されると思います。わかりやすくするために、操作パラメーターをDTOにカプセル化したいのですが、この扱いにくい操作では、Entity Framework 4.0モデルでラップしたレガシーデータベースに対応するエンティティがありません。これは、ドメインサービスのベースになっています。
ドメインサービスは、基盤となるEFモデルのエンティティであるタイプのみを処理することになっていますか？UnwieldyOperationのようなより複雑な操作を公開するように設計されていませんか？
もしそうなら、操作の署名とエンティティフレームワークの操作の両方を可能にする別のサービスを何らかの方法で構築できますか？
モデルのエンティティを処理できるドメインサービスは1つだけであることを理解しました。これにより、すべてのCRUDとUnwieldyOperationを1つのドメインサービスに詰め込むことになりましたが、私の最初のアイデアは、サービスをより小さな部分に分割することでした。
ドメインサービスでパラメーターと戻り値を操作する操作を取得する場合、次の目的は、クライアントでドメインコンテキストに既にロードされているエンティティを更新することです。
そのようなことのための効率的なメカニズムはありますか？
どうやってそれをやろうと思いますか？
私が今まで持っているもの...
要するに、これは私がこれまでに持っているものです：
既存のレガシーデータベースを、余分なパディング/コードをできるだけ少なくしたEntityFramework4.0モデルでラップしました。これは、右クリックしてデータベースから追加および生成することを意味します。
DomainServiceに単純なCRUD操作を実装し、それらを使用して簡単なデータを表示および編集しています。クライアントのViewModelsを介してロジックをカプセル化していますが、Entityクラスを直接公開していますが、これは私の問題/質問とは無関係だと思います。
UnwieldyOperationを最初に思ったほど簡単に追加できないことに気づきました...また、ドメインサービスメカニズムのいくつかの側面を誤解していて、現在の状況につながっているのではないかと思います。
行く方法は？
このような質問にこれを書き留めると、おそらく私はこの方向に進むだろうという考えが得られます。
- LegacyModelServiceは、私がすでに行ったようにCRUD操作を公開します。
- 別のサービスで扱いにくい操作を公開します。それをRIADoaminServiceにするべきですか、それとも単なるWCFにするべきですか？
- 新しいUnwieldyOperationsServiceからEntityFrameworkモデルにアクセスし、そこでデータレイヤーを操作します。
- UnwieldyOperationの結果として生じた可能性のある変更を反映するために、クライアントでLegacyModelServiceのクライアントドメインコンテキストを明示的にリロードまたは更新します。これを行うための良い方法は何でしょうか？