repository pattern linq to sql (stored procedure)

Question

i am looking for repository pattern sample that i can learn from it and i have read lot of blogs and seems like everyone has their own opinions towards -implementing repository pattern-

any help?

Thanks,

Answer 1

Here it's

Answer 2

The repository pattern and Linq to Sql won't match. Sorry.

IMHO, pretty much all I-hide-data-storage-from-u patterns are broken in one way or another. Either you have leaky abstractions or they require LOTS of redundant code.

Imagine this... You have an IRepository which uses Linq to Sql to generate a Foo type that matches a Foo database table. Awesome! Everything worked out better than I expected.

Except the Foo table is linked to the Bar table. So now when you return all Foos via the IRepository interface for Foo, you have to keep your DataContext alive so that if somebody goes foreach(var bar in Foo.Bars) they'll get what they expect.

But how do you manage that DataContext? Do you keep one for all instances of IRepository or one per instance? What happens when a Bar is created, a new Foo is added to it, and saved to the IRepository? You've added a Foo without the Foo repository! And it gets worse, with side effects from not using the L2S pattern correctly come creeping out of your IRepository.

So you try to scope your L2S types within your IRepository implementations, duplicating all your data within new types that you coded by hand. But then how do you handle one-to-many and many-to-many relationships? Load it all into memory, or load a piece by piece, ensuring you lose any way to make efficient queries to the database?

The whole frigging thing is depressing. It would be wonderful to be able to hide the fact that you're not actually storing your data in a database, but unless you're lucky (i.e., your design is simple), you're not going to be able to get away with it.