ADO.NET Entity Frameworkカスタムクラス、正しい選択?

私には今後の要件があり、EFが適切なアプローチであるかどうかは不明です。

基本的には、実装するWebサービスコントラクトを持っています。特定のクラス(DataServiceクラスのDataContentクラスを正しく直列化できるようにする)を返すメソッドがいくつかあります。クラスを構成するデータは、バックエンドデータベースに対するクエリの結果になります。

最下位レベルでは、データベースに格納されたprocsを書き込むことができます。この行は、カスタムクラスに手動でワイヤリングできるデータ行を返し、データレイヤークラスからストアドプロシージャをコールします(ストアドプロシージャをコールし、カスタムクラス)。

私はこのためにADO.NET Entity Frameworkを使用できるかどうか疑問に思っていますが、これはデータベーステーブルからEntityクラスを作成することを理解しています。私のカスタムクラスは、どのデータベーステーブルにも似ていません。格納されたprocsは、クラスを生成するために集約およびテーブル結合を実行します。

EFで可能なことから何かをここに見逃していますか?または、私はちょうど格納されたprocs /手動でデータ層のカスタムクラスを配線するより良いだろうか?

WebサービスはSharePoint 2010でホストされるため、ASP.NET 3.5に限定されています。私はそこに良いアイデアがない限り、データレイヤにアクセスするためにパターンとプラクティスを使用すると思います。

0

2 答え

.NET 3.5のみを使用できると指定した場合、EF 1.xを使用することになります。はORMコミュニティで広く受け入れられていません。 EF 4.xは大幅に改善されましたが、残念ながら.NET 4が必要です。

DAABは確かに選択肢ですが、データからサービスエンティティをマッピングする必要があります(DAABはORMではありません)

IMO EFはLINQと一緒に使用するとき、特にクエリで使用するときには、GetXXXByYYY形式の多くのSPROCを作成している(またはアドホックまたはダイナミックsp_executesqlをたくさん使って)エンティティを作成し、LINQを有効にしているORMは多くの意味を持ちます。しかし、インターフェイスが明確に定義されているPROCが数個しかない場合は、ORMが過剰です。

3
追加された
この特定のプロジェクトには現在6つの方法しかありません。将来的には成長するかもしれないが、あまり成長しないかもしれない。それぞれには対応するストアドプロシージャがあり、文字通り多数のテーブルに参加し、少し集計して行を返す。 ORMが実際にこのスケールの何かに対して過度のものであるように見えます。明確にしてくれてありがとう!
追加された 著者 James Love,
乾杯、心に留めておく。私は主にSharePointデベロッパーですので、.NET 4がもたらす恩恵を得る前にvNextまで待つ必要があります。
追加された 著者 James Love,
.NET 4を使い始めると、EF 4.1以上を手に入れる価値があります
追加された 著者 StuartLC,

アプリケーションのオブジェクトモデルがデータベースのデータモデルと著しく異なる場合は、集計とテーブル結合のための従来のADO.Net +ストアドプロシージャを使用します。私の意見では、どんなORMでもこのような場合には利益より多くの問題が生じます。

2
追加された