Microsoft による ASP.NET (2.0) アプリ用のDAL/BLL 設計の提案があります。私はいくつかの代替案を知っており、SO で関連する質問を読みました。しかし、この提案された解決策が今日実装する価値があるかどうか疑問に思っています。あなたが知っている特定の欠点はありますか?
さまざまなアプリケーションやスクリプトから顧客や従業員のデータなどにアクセスするために、社内で使用する DAL/BLL コンポーネントを開発したいと考えています。ただし、そのようなものの構築を開始する前に、このソリューションが「優れている」ことを確認したいと思います。例として、BLLは何もカプセル化する代わりにデータテーブルを渡します。ロジックを含む分離されたビジネス オブジェクトはありません。これは基本的に、CRUD 操作を少し緩和し、コントロールのデータ バインディングを可能にする単なるダム レイヤーです。
この分野で経験のある人が、このアプローチの長所と短所を指摘してもらえますか?
DATATABLESを使用しないことを強くお勧めします。フレームワーク全体がList<>またはQueryable<>に渡すことができる通常のオブジェクトで機能するドメイン駆動設計の実装を調べてください。DataTablesはゴミであり、.NETに含めるべきではありません。
I would also recommend looking into using a Dependency Injection / Inversion of Control framework such Microsoft Unity or StructureMap to create loosely coupled code.
長所:
- シンプルなアプローチであり、データ マッピングの一部はデータ テーブルを使用して行われます。
- Select、Add、Update、および Delete クエリを実行するための便利な機能を提供します。
- テーブルがほとんどない非常にシンプルなデザインに適している可能性があります。
- 非自己参照 ER デギンまたは ER に適しており、ルックアップ テーブルと単純/少数の結合がほとんどない
- 単純なデータ ストアが必要な場合に適しています。すなわち。複雑な OO のアイデアを「ビジネス オブジェクト」に適用する必要がある場合、このパターンは物事をより困難にします。
短所:
- 大規模な OO モデルはこのパターンでは苦労します
- 多くのテーブル、複雑な関係、または OO オブジェクト要件を伴う複雑な ER 設計は、このパターンに適合しません。データテーブルは、LINQ のようなコード内オブジェクトのクエリにはあまり役立ちません。
- ほとんどのクエリは、SQL で手動で記述する必要があります (これには結合が含まれます)。はい、クエリ デザイナーを使用できますが、これはあまり役に立ちません。
- このアプローチには多くのコードの重複があります。たとえば、BLL クラスに多数の CRUD メソッドを記述します (これもゼロから記述する必要があります)。
結論： それは本当にあなたの要件に依存します。実装が小さい/単純な場合、これは良い考えかもしれません。しかし、このアプローチでは小さなアイデアを発展させるのは難しいでしょう。オブジェクト指向のアプローチを増やすと、後でリファクタリング/拡張するための準備が整います。このパターンも古い/時代遅れです。IQueryable/LINQ をクエリするオブジェクトはより一般的であり、まもなくより広い標準になります。このワゴンに飛び乗ることをお勧めします。長期的には、個人の成長にも良いでしょう。:D
いくつかのリンク: