I feel like I'm running around in circles. I can't seem to make up my mind as to what the right Repository pattern is using Linq To Sql. If you're familiar with Rob Conery's MVC Storefront you will see that his implementation wraps the Linq-Generated models with another class and treats the Linq-Generated one simply as a Data Transfer Object. It looks something like this:
//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)
};
}
What is the advantage of doing it this way (using a wrapper class), as opposed to the way Mike Hadlow suggests here in his version of IRepository where he just returns the DTO objects from the repository?
My other question is, where should business logic be enforced and checked? Is this in a seperate layer all together called by the repository on save/update, or is it built-in to the wrapper class?
Thanks for all the help.