web-dev-qa-db-ja.com

アーキテクチャ的に言えば、MicrosoftのEntity Frameworkなどのデータベース抽象化レイヤーは、個別のデータアクセスレイヤーの必要性を無効にしますか？

それがあった方法

何年もの間、私はソフトウェアソリューションを次のように整理してきました。

  • データにアクセスするビジネスを抽象化するデータアクセス層（DAL）
  • ビジネスルールをデータセットに適用したり、認証を処理したりするためのビジネスロジックレイヤー（BLL）.
  • ユーティリティ（Util）は、私が時間をかけて構築した一般的なユーティリティメソッドのライブラリです。
  • もちろん、Web、デスクトップ、モバイルなどのプレゼンテーション層。

今のやり方

過去4年間、私はMicrosoftのEntity Framework（私は主に.NET開発者です）を使用しており、Entity Frameworkはすでに私のDALが使用していた仕事：データベースに対してCRUDを実行するビジネスを抽象化します。

そのため、私は通常、次のようなメソッドのコレクションを持つDALを作成します。

public static IQueryable<SomeObject> GetObjects(){
    var db = new myDatabaseContext();
    return db.SomeObjectTable;
}

次に、BLLでは、このメソッドがそのまま使用されます。

public static List<SomeObject> GetMyObjects(int myId){
    return DAL.GetObjects.Where(ob => op.accountId == myId).ToList();
}

これはもちろん、BLLには通常、さらに数行のロジックが適用されるため、単純な例ですが、そのような限定されたスコープのDALを維持するのは少し過剰に思えます。

DALを放棄し、BLLメソッドを次のように記述するだけの方がいいのではないでしょうか。

public static List<SomeObject> GetMyObjects(int myId){
    var db = new myDatabaseContext();
    return db.SomeObjectTable.Where(ob => op.accountId == myId).ToList();
}

上記の理由により、DALを将来のプロジェクトから削除することを検討していますが、そうする前に、プロジェクトに取り掛かり、私がしなかった問題を発見する前に、ここでコミュニティに投票して、あなたの意見、見通し、意見を聞きたかったのです。 t予想します。

ご意見をお待ちしております。

更新

コンセンサスは別のDALは必要ないということのようですが、ベンダーロックインを回避するために（ここで自分で推論する）ことをお勧めします。たとえば、上記のようにEF呼び出しを抽象化するDALがある場合、私は自分のBLLを書き直す必要のない他のベンダーに切り替えます。 DALの基本的なクエリのみを書き換える必要があります。そうは言っても、これが起こるシナリオを想像するのは難しいと思います。私はすでにOracle dbのEFモデルを作成できます。MSSQLが指定されているので、MySqlも可能であると確信しています（??）。

architecturedata-structuresentity-frameworkseparation-of-concerns
11
Matt Cashatt

これがあなたが探している答えであるかどうかはわかりませんが、ここに行きます。

物事を分離/整理するためにそれを行います。はい、EF/NHibernateはデータアクセスですが、一般的なリポジトリ設定を使用して、EF/NHibernateを独自のアセンブリに制限しています。このアセンブリには、NHibernateマッピング、セッションファクトリ、複数のデータベースを処理するためのコードなどもすべて含まれています。

ORMをサポートするためにアセンブリ全体が存在するため、これを「データアクセスレイヤー」と呼びます。

私のメインアプリは5つのデータベースを参照し、およそ4〜500のドメインオブジェクト/マッピングとさまざまなスキーマを持っていることにおそらく注意する必要があります。したがって、この設定は私たちにとって意味があります。おそらく、小さなアプリの場合は、このアセンブリをスキップしますが、私は組織化されたコードの吸盤であり、とにかくそれを行うでしょう:)

6
Simon Whitehead

私は、EFとDALをエンタープライズシステムの個別のコンポーネントと見なしています。データアクセス層は、他のサービスがデータの永続化と管理を実行するために使用する抽象化です。通常、Entity Frameworksはクエリ、更新、削除、および挿入に関連する素晴らしいAPIを構築しますが、コアでは、バックエンドデータソースへの直接接続が必要です。そのため、どのような種類のルーティングまたはファイアウォールでもEFの機能が停止するため、EFメディエーションコンポーネントを作成する必要があります。

DALとEFが適合する場所を示す高レベルの例を次に示します。

-------------    -------                                    ----------------    ------
| Service A | -> | DAL | -> { LOCAL / LAN / WAN ACCESS } -> | DAL BACK-END | -> | EF |
-------------    -------                                    ----------------    ------

私の経験では、より優れた設計は、ビジネスロジックまたはサービス実装がEFレイヤーに直接アクセスできないようにすることです。代わりに、すべての永続データを操作するための抽象化を提供して、ネットワーク経由でリクエストを送信したり、ローカルでリクエストを実行したりできるようにします。

ただし、この設計では、いくつかの漏れやすい抽象化が導入されています。したがって、ケースバイケースで検討する必要があります。

いくつかの質問：

  • データにアクセスするすべてのコンポーネントは、バックエンドデータストアへの接続を取得できますか？
  • EFでは、さまざまな種類のデータストア間でデータセットを集約できますか？たとえば、ドキュメント用にMongoDBでSQLデータベースを使用します。
2
Andrew T Finnell

最近では、データストレージを変更するかどうかという問題は、MS SQLとOracle SQLの間で交換するかどうかだけではなく、は、さまざまなNoSQLデータストレージ製品をデータリポジトリとして使用する場合があります。

そのような変更の深刻な可能性があった場合、EFコードをDAL内に隔離しておくと、将来リポジトリリクエストをNoSQLデータベースにマッピングする新しいDALを導入できるため、価値があるかもしれません。もちろん、このような変更は、当然ながらクリープするdb関連の仮定のために、BLLの大規模な書き換えに終わる可能性があります。

同様に、DAL内のEFは、おそらくBLLコードユニットテストのデータアクセスのモックをより簡単にします。

したがって、EF（または他のORMS）が必ずしもデータアクセス層の必要性を無効にするわけではないというのが私の見解です。

1
Alex White