I read an article on CodeProject about implementing the repository pattern with Linq To SQL.

I tried that approach because it sounded very nice. I did have some problems with performance and after a few debugging sessions (showing the SQL trace or the DataContext log) I found the problem.

By defining the virtual methods of the repository base class like this: public IEnumerable<T> FindAll(Func<T, bool> exp) the Func will not be (what I call) a delayed method, but it will be expanded immediately. I checked the log from the DataContext and it shows that the table is no longer queries using a where clause. Instead, a full table load is performed and the function is evaluated in memory.

However, the solution is very easy, although this mean you'll have to include the Linq assemblies to your testing bed:

protected T Single(System.Linq.Expressions.Expression<Func<T, bool>> exp)

{

    return Items.Single(exp);

}

The trick is to wrap your functions in a System.Linq expression. Client usage is exactly the same. The performance gain on my project was huge, If you consider that tables are no longer loaded completely into memory.

The full code for my repository base class is in the link below.

Repository.cs (4,64 kb)

I now have been working 12 years on software development and 8 years asp.net. I consider that to be a substational amount of experience. Because of this realisation, I'd like to share some things I've been learning of the years. I summarized my experiences, so check out this list:

1. If you find the problem, look for the answer.
2. If you find the answer, don't stop looking
3. If you stop looking, experiment. 
4. If you stop experimenting, make it work
5. If it works, redesign
6. If you're still not happy, you didn't understand the problem: back to square 1.

These are some mindblowingly simple steps. but they've always worked for me. They help, and not only in software! Number 1 and 2 are easy. That's (1) smart thinking and (2) google. We'll get to number 3 later on. The numbers 4 through 7 are simple development strategies you can read up on in tons of places.

I do like to elaborate on step 3. Most of my coworkers (and a lot of other people i meet) stop after #2. This usually happens after a couple of minutes or hours using google. By the way, if you know the problem, googling for an answer shouldn't last more than a couple of minutes. This is because google is very smart, but it doesn't know your problem. You're actually not googling for articles on the problem - you're googling for articles about the solution to that problem. This sounds strange because most articles talk about 'I have a problem with this and this', so the good google results should point you to an article or a thread that says 'I found the solution for this and this'. The trick here is to include words like 'solution' or 'best practice', 'I finally got it working' etc. to your search query.

Back to #3. Don't stop researching when you think you found the answer. To put it clearly: Number #3 is where the learning phase starts. Start working on a mind-map of the problem space. If you read enough articles on "How do I create custom controls?" for example, you usually cover a lot of the same subject matter, but if you deviate a little from the primary problem, you'll gain tons of slightly related knowledge. To illustrate, check out the class definition of a asp.net master page. I got there recently because I needed to know the base class of a MasterPage. That was easy to find - I also could've looked that up by pressing a help button in Visual Studio. I said 'for example' didn't I? Now as a case of routine I drilled down to the MasterPage Members, where I found out about two very nice properties named ContentPlaceHolders and ContentTemplates. I didn't know these existed, nor would I have found out about them in another way. Especially if you never think you'd need them. But I did need them. I had about a 100 lines of code in my application to find out what regions my MasterPage contains for a CMS i'm working on, but now I can simply refactor and clean up. The lesson I try to tell you is that browsing a couple of non-relevant links from you article *will* improve your knowledge. As you keep reading linked material you'll very soon connect some dots nobody else has ever thought about.