そうだった
長年にわたって、ソフトウェアソリューションを次のように整理してきました。
- データにアクセスするビジネスを抽象化するデータアクセス層（DAL）
- ビジネスルールをデータセットに適用したり、認証を処理したりするためのビジネスロジックレイヤー（BLL）
- ユーティリティ（Util）は、私が長年にわたって構築してきた一般的なユーティリティメソッドの単なるライブラリです。
- もちろん、Web、デスクトップ、モバイルなど何でもよいプレゼンテーション層。
今のやり方
過去4年ほどの間、私はMicrosoftのEntity Framework（私は主に.NET開発者です）を使用しており、Entity Frameworkが既に行っているという事実のために、DALがクリーンよりも厄介になっていることに気付きました私の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を削除することを検討していますが、そうする前に、プロジェクトを開始して問題を発見する前に、後知恵/先見/意見についてコミュニティに投票したいと思いました」予想する。
どんな考えでも大歓迎です。
更新
コンセンサスは、別個のDALは必要ではないが、ベンダーロックインを回避するために（ここで独自の推論を行う）ことをお勧めします。たとえば、他のベンダーに切り替えて、BLLを書き換える必要はありません。DALの基本的なクエリのみを書き換える必要があります。そうは言っても、これが起こるシナリオを想像するのは難しいと思います。私はすでにOracle dbのEFモデルを作成できます。MSSQLは与えられています。MySqlも可能だと確信しています（??）ので、余分なコードが価値のあるROIを与えるかどうかはわかりません。
GetMyObjects(int myId)よりも簡単であるため、busineslayerのUnittestsをはるかに簡単にすることができGetObjects.Where(ob => op.accountId == myId).ToList()ます。