5

EF 5.0およびn層ソリューションのmsdn情報を読むと、リンクを参照してください。MSはSTEを推奨していないようです。また、POCO / DTOの方法も、難しいと述べて推奨していません。

すべての(おそらく多くはない?)アプリケーションがWCFデータサービスの使用に適しているわけではありません。それで、行く方法は何ですか?私のシナリオは、多くのクライアント(私たちだけ)、主にWinFormsを備えた現在の大規模サーバー(WebServices)アプリケーションです。現在、DataSetは、データを出荷し、SQLServerデータベースへの変更を追跡するために使用されます。

現在、WebServicesをWCFに置き換え始めており、EntityFrameworkの使用も検討しています。すでにデータベースが用意されており、再利用される多くのストアドプロシージャがあるため、最初にコードを記述したり、移行したりする必要はありません。クライアントが私たち以外であることに問題はないので、STEは良い選択のように思えましたが、EFチームが明らかに推奨していないものを使い始めたくありません。POCO / DTOは、特にクライアントとの明確な分離のための代替手段でもあります。CUDでやるべきことはまだまだあると思いますが、遠ざけることをお勧めするのは非常に難しいので、その道を進みたいかどうかはわかりません。

次に、推奨事項に従って、WCFデータサービスまたはWeb APIを使用する必要がありますが、これは、プロトコル/形式などについて柔軟である必要がある操作ベースのサービスの代替手段ではありません。

だから私の質問は、今日のベストプラクティスは何ですか?

4

1 に答える 1

3

より一般的には、より軽量のpocos / dtosに移行し、すべての永続性ロジックまたは実装をDALに保持するという考え方だと思います。自己追跡エンティティは、その実装の一部をブリードアウトし、エンティティを肥大化させます。利便性は得られますが、ダムdtoはほとんど驚きを伴わずに簡単に渡すことができるため、柔軟性が失われます。

もちろん、その反面、コンテキストを追跡するためにdalでより多くの作業を行う必要があり、dtoの入力/マッピングを処理するためにBLLとUIでより多くの作業を行う必要があります。

私は個人的に便利さよりも柔軟性を好みます、そしてそれは物事が一般的に進んでいる方法のようです。

于 2012-10-05T15:00:47.440 に答える