2010-11-30 5 views
0

odataサービスでは、dtoを使わずにクライアント側から問い合わせることができます。 odata svcを使用すると本当にdtoレイヤーが必要ですか?私がdtoを使用しないと、短所や賛否は何ですか?従来の照会メカニズムのシステムでは、dtoコレクションを返す多くの照会サービスメソッドがあります。しかし、odataサービスは私の心を混乱させます。サーバーの責任はクライアントに移ります。トランザクションスクリプトの場合、同じ混乱が続きます。私はあなたの思考についての骨董品です。Dto/TransactionScriptsとOdata Services

答えて

0

oDataで重要なのは、EDMモデルまたはPOCOモデルのみです。したがって、EDMXファイルを生成するときには、それらのファイルをビジネスオブジェクトまたはモデルレイヤとみなし、それらの名前空間に引き込むことができます。したがって、そこにはビジネスロジックは適用されません。

しかし、クライアント側では、いつでもoDataメソッドの呼び出しを集中化できます。彼らはコールバックをサポートしているので、常にビューモデルでリポジトリを呼び出してコールバックを返すことができます。このようにして、豊富なodataクエリ呼び出しでビューモデルを拡張する必要はありません。並べ替えrepositroyパターンは、私が話していることです。

これはあなたに方向性を与えます。

について:

+0

あなたは、リポジトリがクライアントサイドにあり、モデルがサーバー側にあるとします。しかしそれは変わっていないのですか?我々は "ドメイン"と呼ばれるものは、リポジトリとモデルで構成されています。しかし、なぜ私は2つの異なる物理層にそれらを分離する必要がありますか? –

+0

私の知る限り、リポジトリは単なるパターンです。これがサーバー側またはクライアント側にある必要があるというラベルはありません。私は、WCF Data Serviceアーキテクチャで、2つのファイルを持っています:.EDMXである1つのファイルと、すべてのEFモデルが存在する対応する.CSファイル、WCF Daraサービスが定義されている2つのファイル。これは、oDataを公開するためにサーバー側で必要なすべてです。クライアント側について言いたいことは、oDataクエリの呼び出しを1か所で制御するアーキテクチャです。あなたはそれをリポジトリまたは普通のクラスにすることもできます:) – kashyapa

関連する問題