2

新しいWebアプリケーションのいくつかのテクノロジを評価しています。WebAPIでEF5とKnockoutJSを使用する必要があります。IQueryableを返すときにOData機能を利用したかったのですが、現在、EFモデルをビジネスモデルに変換する方法という問題が発生しています。

私が読んだ限りでは、より複雑なDB（計算列、ストアドプロシージャなど）が必要な場合は、DBFirstアプローチを使用する必要があります。（私が間違っている場合は私を訂正してください）

DB-Firstアプローチを使用する必要があり、モデルをDBから独立させたいので、EF-Modelに追加してモデルを作成する必要があります。また、DataLayerからビジネスモデルをIQueryableとして返すと、追加のクエリをDBで直接実行する可能性がなくなりますが、代わりにASP.Netサーバーで直接実行されます。

もちろん、ODataに対して複雑なクエリを実行する予定はなく、とにかくそれらを追加のアクションとして実装しますが、低速のクライアント（スマートフォンなど）では、返されるデータを制限し、追加のフィルターを直接実行すると便利な場合があります。サーバ。

このジレンマから抜け出し、ODataを引き続き使用できるようにする方法はありますか？

よろしくピーター

4

2 に答える 2

3

コードファーストおよびEF移行を使用して、データベースを作成/アップグレードしてみてください。移行を使用すると、SQLスクリプトだけのカスタム移行を作成して、CodeFirst自体では自動的に実行できないことを実現できます。データベースファーストのアプローチも問題ありません。

複数のバックエンドを本当にサポートしたい/サポートする必要があるかどうかを自問してください。EFで可能ですが、メンテナンスが困難です。この場合、概念モデル（csdl）はすべてのデータベースで同じであると想定していますが、複数のストア固有のモデル（ssdlファイル）があります。モデルはすべてのデータベースで同じであるため、使用しているデータベースに関係なく、同じC＃タイプになります。

複数のデータベースをサポートする場合、データベースに対してSQLクエリを実行することはできません（より具体的には、あるデータベースに固有のSQLクエリを別のデータベースに対して実行すると例外が発生します）が、理想的には必要ありません。最悪の場合、SQLでコーディングするロジックを、すべてのデータベースに存在するストアドプロシージャに含めることができます。繰り返しになりますが、これがいつ必要になるかはわかりませんが（頭に浮かぶのはパフォーマンスだけです）、ODataの使用を計画しているため、Service Operationsの使用を開始しない限り、これらのクエリを実行することはできません。

概念モデルはデータベースに関係なく同じであるため、データベースに関係なく同じタイプになります。これらをDataLayerとビジネスモデルの両方に使用してみることができます（特にPOCOを使用する場合）。別の方法は、POCO/DTOを使用することです。（私はWeb APIでODataサポートを試していませんが、WCF Data Servicesではサービス自体が実際にEFタイプを使用するため、サービスに異なるタイプのセットを使用するように指示することさえできません）。

于 2013-01-28T03:21:09.073 に答える
0

変換がそれほど悪くない限り、実際にはDBファーストモデルでビジネスモデルに対してクエリを実行する機能を失うことはありません。たとえば、PersistedCustomer（DBモデル）とCustomer（ビジネスモデル）を持つODataサービスがあります。EF5を使用すると、IQueryableをIQueryableに変換するLINQを記述でき、IQueryableに対するクエリを実行でき、EFは基準を元のデータベースに対して変換し直すことができます。

于 2013-01-28T04:41:39.637 に答える