私は .Net 3.5 Web アプリケーションに取り組んでいます。たとえば、顧客、注文などのさまざまなモジュールがあります。Enterprise Library 4.0 (データ アクセスを使用) を使用して、同じデータ アクセス層 (DAL) を設計する必要があります。アプリケーション ブロックまたは DAAB) を使用して SQL Server 2005 に接続します。
• 「IDataService」と呼ばれるインターフェースを持ちます。「ExecuteReader()」、「ExecuteScalar()」、「ExecuteNonQuery()」、「AddParams」などのメンバーを持ちます...基本的に、このインターフェースはDAAB。
• このインターフェイスを実装する「DataService」というクラスがあります。このクラスは DAAB のラッパーとして機能し、各メソッドは DAAB の対応するメソッドを内部的に使用します。
• Customer、Data などのビジネス クラス (またはデータ コンテナー) を持ち、データベース内の対応するテーブル属性にマッピングされるプロパティを持ちます。
• CustomerDataService、OrdersDataService などの各モジュールに DAL クラスを用意します。これらの各クラスには、以下のように DataService クラスをインスタンス化するコンストラクタ コードがあります。 IDataService dataService= new DataService() また、これらの各クラスには次のようなメソッドがあります。 GetCustomerDetails() AddCustomer() RemoveCustomer() UpdateOrder など。これらのメソッドは内部で「dataService」オブジェクトを使用して、データベース ExecuteReader、ExecuteNonQuery などで操作を行います。
• 「CustomerMapper」、「OrderMapper」などの各モジュールのマッパー クラスを用意します。これらのクラスはデータソース (IDataReader など) を入力として受け取り、ジェネリック コレクション (List) にデータを入力します。これらのマッパー クラスは、対応する Dataservice クラスによって内部的に呼び出され、タイプ セーフなコレクションを呼び出し元のクライアントに返します。
• 「DBNull ケースの処理」、「ストアド プロシージャ名の保存」などのタスクを実行する DbHelper などのヘルパー クラスを用意します。
• DataService クラスは、BusinessLogic レイヤ クラスによって使用されます。つまり、CustomerBusiness、OrdersBusiness などです。
• ビジネス ロジック層は、コレクションをプレゼンテーション層に返します。
この設計は理にかなっていますか?このアプローチの利点/欠点は何ですか? このアプローチの利点は、「DataService」クラスが内部でどのように実装されているかを知る必要なく、すべての DataService クラスが常にインターフェース「IDataService」に対してプログラミングされることです。したがって、将来、DAAB を削除して、内部で別の API を使用する場合DataService クラス、クライアント コードを変更する必要はありません。また、DAAB に存在しないメソッドを IDataService インターフェイスに追加することもできます。たとえば、BatchUpdate()...
私が間違っている場合は修正してください。