Hey I didn’t notice the date on it; I came in via reddit. I should have worded the reply differently, but it was those headings.
Lessons for me. And thanks for publishing.

One could argue that exposing IQueryable lets better programmers write concise code since you can now compose your logic.
a) some-query-getting-customers.Select(a -> a.Id) //If you just wanted the IDs, quite common
b) query.Where(other-conditions) //If we already have a query and you just wanted to filter some more.

Or consider Sorting and Paging. The post you linked to (from Justin) introduced new patterns for functionality that is already built-in. And never mind that those new classes (Sortable, Pageable etc) wrapped the IQueryable within it. Sometimes people do this because they fear it just wouldn’t be “N-Tier enough” if the Queryable got out of the middle tier. It doesn’t really matter though.

I don’t care about code quality, standards or best practices. I am happy if it works, happier if it is also concise.

Thanks.

I’m not solving an imaginary problem here. Check out the Reddit conversation from today.

It’s very simple. One year after writing this post, folks *still* don’t realize that a call like this:

var q = context.Users.AsQueryable();
var e = q.AsEnumerable();
e.First();

will select and return ALL of the user records in your database.

That’s not a “contrived” rule. That’s a serious problem that needs to be documented and addressed.

Also, I appreciate your three rules (the first of which is to avoid rules), but I find them to be a bit presumptuous. You don’t have me as pegged as well as you think you do.

Cheers,
E

Once upon a time, I used to believe in these patterns and ideals. I used to make similar rules for myself and others (Don’t do this, don’t return that, this should always do that etc). I wisened up after that. For all the pain, my rules had achieved very, very little.

When I look back, I laugh at all the juvenile bullshit I spewed out.

Here is my advice:
1. Don’t worry about rules which solve an imaginary problem.

2. Learn some other programming languages: Such as Python, Ruby or LISP/Clojure. Most people who obsess over trivial details know only Java or C#, and rarely stray out of their Windows IDEs.

3. Use Linux for a bit, even if you don’t use it for your job. Read up on computing history, the culture, the Jargon File, the AI Koans, ESR’s books, SICP; there’s a whole lot of good stuff out there.

Nothing will happen to your dog. Or your wife.

Gosh! Ppl telling you how to “fix” your blog.

I love the humorous inserts and out-of-context analogies. It’s great!

Thanks Evan.

The structure seems a bit intimidating, but when you break it you realise there isn’t much more than another layer beyond the familiar Repository.

I like the concept and see the extensibility, but again you’re stuck only with the methods that you pipes expose, which as you state gives you the ability to control what’s exposed.

That’s good when you don’t need to juggle with the database too much. But what happens when you need to execute some serious sorting, filtering, etc? You’d end up writing way too many methods, don’t you think? Imagine the long run maintenance… methods.. methods.. methods.. Had you exposed the results directly from the repo you’d have it all ready to be manipulated by the consumer.

I understand that the consumer would be required to know how to handle the IQueryable.

I guess either way there’s no magic one-size-fit-all answer.

Bottom line – if you know the consumer (a colleague who uses your library, or even yourself) then exposing IQueryable is just fine (you can torture those who misuse it!). If you’re selling the library to third parties (no torture here) then you may want to consider a less “open” approach.

My 2c..
D.