Entity classes decoupled from LINQ to SQL provider for implementing the Repository pattern. How?

Question

I have looked over the Repository pattern and I recognized some ideas that I was using in the past which made me feel well.

However now I would like to write an applicat

Answer 1

I don't know if this is exactly what you want, but you may want to take a look at Rob Conery's MVC Storefront code. He uses a variant of the repository pattern with a linq provider. He maps the LINQ to Sql objects to domain objects and then returns the domain objects from the repository provider to a service layer which wraps the provider allowing him to work some logic on the data returned before it hits the business layer.

MVC Storefront Webcasts
Code

To me it sounds like you want the providers to return DTOs and then you want to map the DTOs to the domain objects in the repository/service layer. If this is the case you could map your LINQ to SQL provider to the DTOs, have it return them, then map the DTOs to domain objects in the repository/service layer. This should work just fine, but it may become tedious as you now would have 2 mapping layers.

In this case you would have: ProductService, which takes an IProductRepository. It evokes methods on the IProductRepository to get back your DTOs. It then maps the DTOs to the real business objects and returns them to the calling code.