ぐるぐる回っている感じです。正しいリポジトリ パターンがLINQ to SQLを使用しているものについて、私は決心できないようです。Rob Conery の MVC Storefrontに精通している場合は、彼の実装が LINQ で生成されたモデルを別のクラスでラップし、LINQ で生成されたモデルを単にデータ転送オブジェクト(DTO) として扱っていることがわかります。次のようになります。
//Custom wrapper class.
namespace Data
{
public class Customer
{
public int Id {get;set;}
public string Name {get;set;}
public IList<Address> Addresses {get;set;}
}
}
//Linq-Generated Class - severly abbreviated
namespace SqlRepository
{
public class Customer
{
public int Id {get;set;}
public string Name {get;set;}
public EntitySet<Address> {get;set;}
}
}
//Customer Repository
namespace SqlRepository
{
public class UserRepository : IUserRepository
{
private _db = new DB(); //This is the Linq-To-Sql datacontext
public IQueryable GetCusomters()
{
return
from c in _db.Customers
select new Customer // This is the wrapper class not the gen'd one
{
Id = c.Id,
Name = c.Name,
Addresses = new LazyList(c.Addresses)
};
}
Mike Hadlowが IRepository<T> のバージョンでLINQ to SQL を使用した IRepository パターンの使用で提案している方法とは対照的に、この方法 (ラッパー クラスを使用) の利点は何ですか?リポジトリ？
ビジネス ロジックはどこで適用およびチェックする必要がありますか? これは、保存/更新時にリポジトリによってすべて一緒に呼び出される別のレイヤーにありますか、それともラッパークラスに組み込まれていますか?