11

最近、新しい Web フォーム プロジェクトを開始し、ビジネス クラスを DBML 参照から分離することにしました。私のビジネス層クラスは代わりに個別のデータ層メソッドにアクセスし、DTO のコレクションを返します。したがって、データ層は次のような DTO を投影する場合があります。

(from c in dataContext.Customers
where c.Active == true 
select new DTO.Customer
{
   CustomerID = c.CustomerID,
   Name = c.CustomerName,
   ...
}).ToList()

DTO オブジェクトを構築すると作業が増えますが、これはビジネス レイヤーとデータ レイヤーを緊密に結合するためのより良いアプローチのように感じられ、データベースが存在しなくてもビジネス レイヤーをテストできることを意味します。

私の質問は、これは良い習慣ですか?、DTO を生成する方法 (おそらく SQLMetal 経由) はありますか? また、プロジェクトが進行するにつれて、他にどのような問題が発生する可能性がありますか?

4

2 に答える 2

5

それがベスト プラクティスかどうかはわかりませんが、アプリケーション内で LINQ デザイナーが生成したクラスの代わりに独自のクラスを使用することで、関心の分離を改善できると感じたので、最近ではない過去に同様のコードを作成しました。 .

データ アクセス メソッドから IList<Customer> の代わりに IQueryable<Customer> を返すことを検討することをお勧めします。IQueryable<T> は IEnumerable<T> を継承するため、アプリの残りの部分はそれをうまく処理できるはずです。本当に必要な場合は、リストに変換することもできます。

これの利点は、クエリを非常に簡単に動的に変更し、SQL Server から返されるデータの量を最小限に抑えることができることです。

たとえば、メソッド シグネチャが IQueryable<Customer> GetCustomers() の場合、GetCustomers().Where(c => c.CustomerID == 101).Single(); を呼び出して単一の顧客を取得できます。

この例では、データベースから 1 つのレコードのみが返されますが、現在、コードはすべての顧客を返すか、必要なすべての異なるものに対応するために個別のメソッド (したがって非常に反復的なコード) を記述する必要があると思います。でフィルタリングします。

于 2008-09-09T03:54:51.950 に答える
2

私の意見では、ほとんどの場合、LINQ を扱う場合、DTO オブジェクトは必要ありません。生成された LINQ クラスは簡単にテストできます。LINQ を使用すると、同一のクエリを使用してさまざまなソースからデータをクエリできます。実際のデータベースではなく、オブジェクトのリストに対してクエリをテストできます。

于 2008-09-09T03:45:02.847 に答える