0

を使用した結果はどの程度再利用可能EFですか?

現在、私stored proceduresは 100% のデータ アクセスに使用しています。最新のプロジェクトで別の方法を検討する主な理由は、保守性のためです。テーブルに属性を追加するということは、何十ものストアド プロシージャを手動で変更することを意味します。私の理解が正しければ、モデル内のエンティティに属性を追加して、メソッドの更新を依頼EFできるはずです。驚くばかり。EFEFCRUD

しかし、私を妨げていることが 1 つあります。それは、再利用性です。特定のデータベースの SP を一度作成すれば、それで完了できるのが気に入っています。すべてがそのデータベースを使用する 12 個のアプリケーションを作成でき、正しい SP を呼び出すのと同じくらい簡単にそのデータを取得できます。

  • よりEF中心のアプローチに切り替えた場合、同じことが当てはまりますか?

  • 既存の EF データ モデルをインポートして、問題なく動作させることはできますか?

  • データ モデルを 1 回変更すると、その変更がすべてのアプリケーションに反映されるようにすることはできますか?

4

3 に答える 3

2

広告 1。リポジトリパターンに従えば、複雑な EF クエリを簡単に再利用できます。リポジトリはデータ アクセスをカプセル化する場所であり、そうです、リポジトリは異なるモジュール/アプリケーション間で簡単に再利用できます。

(リポジトリなしでコードを再利用できないわけではありません! リポジトリは、データ アクセス レイヤーでそれを行うための一般的な方法です)

Ad2。「既存の EF モデルをインポートする」とはどういう意味かわかりませんが (どこにインポートしますか?)、通常、EF モデルは簡単で再利用できます。

Ad3。モデルを別のアセンブリに入れるだけです。

于 2013-09-16T19:55:06.880 に答える
1

を使用する本当の利点EFは、ストアド プロシージャから解放されることです。すべてのデータ アクセスにストアド プロシージャを使用する場合の問題は、ビジネス ロジックをデータ層に配置しなければならないことです。

データ アクセス レイヤーにビジネス ロジックを含める必要がありますか? を確認してください。すべての場合に当てはまるわけではありませんが、通常、ビジネス ロジックをビジネス レイヤーに保持すると、懸念事項をより適切に分離できます。

EFいくつかのアプリケーションのデータ レイヤーとして使用するプロジェクトがあります。これにより、一度変更するだけで、他のすべてのプロジェクトにメリットがもたらされます。確かに、これらの他のプロジェクトでサポート コードを変更する必要がある場合もありますが、ストアド プロシージャ モデルでも同じ問題が発生します。

于 2013-09-16T20:41:34.907 に答える
0

N 層設計では、エンティティ フレームワークを使用してデータにアクセスする方法を理解するクラス (クラス ライブラリ内) を作成するだけで、この問題を解決できます。その後、データにアクセスするアプリケーションはクラス ライブラリを使用し、app.config または web.config で接続文字列を構成すれば完了です。

于 2013-09-16T19:54:14.120 に答える