Why not filter at the DB level?

cmay posted on Thursday, June 08, 2006

I was looking over the ProjectTracker's ProjectList class.

It has a filter (by name), but I was expecting it to pass the name to the SP, so that the DB could just return the valid projects, but instead it returns them all, and then loops through the collection to see if they meet the filter criteria.

Is this a "oh, yea you can do it that way, I was just trying to show an example of how to use the filter in the .net code" or is this a "yes, there is a very good reason why it was done that way" thing?

ajj3085 replied on Friday, June 09, 2006

Personally this is why I prefer using views to do selects vs. stored procedures.

I have a DAL that generates the Sql for me, so I don't need to worry about that. The DAL has objects which allow me to specify a filter, which it then translates to a Where clause for the select when I tell the find to execute.

The drawback of course is that I don't necessarly get everything by hitting the server only once, but so far the preformance is very good (as I don't bring back much data to begin with).

andy

RockfordLhotka replied on Friday, June 09, 2006

This was totally a case of "oh yeah, you can do it this way" Smile [:)]

The challenge with a sample app in a book is that it has to be small enough to fit in a chapter. That's a serious challenge!

What I'd really like to use as a demo app is some inventory tracking based on real-world experience. Then you can get into fun stuff around random, expiry-based, FIFO and LIFO bin locations and all sorts of stuff. In those cases you really might want to do the "filtering" in your object, because some of the logic is complex enough that it is hard to find a SQL developer capable of pulling it off.

Not slamming SQL developers - just observing that in these cases I've seen more horrific implementations than I care to think about - there's a boundary below which most SQL developers are fine, and above which they write 8 page monsters that run super-slow. Only a tiny minority of SQL developers are capable of writing effective SQL at that level - and finding them is hard. And even if you do find one who's that good, will they be around forever to maintain the sproc? Probably not, so at that point it is (imo) better to avoid the use of a sproc.

But it is a moot point. Such a sample app can't fit into a chapter, so I can't really use that as an example.

kdubious replied on Tuesday, June 13, 2006

OK... somebody needs to kiss ass and say it: What's it going to take to get you to work on that sample app?

That's my ONLY gripe with the book.

Don't get me wrong... I've built my entire company around the use of CSLA, and have earnings in the 100k range across the past 2 years from CSLA based products I've developed. I'm a huge fan. I couldn;t have done it without the book, and CodeSmith.

But, I spend my time cranking out widgets, and don;t often get to spend a lot of time considering best practices, reusable patterns, etc.

I'd really appreciate a best-practices real world sample app. I've got a few specific questions, and I'll post them in a new thread.

So, when's it going to be done, Rocky, huh? huh?

Kevin

xal replied on Tuesday, June 13, 2006

The question is:
Why don't WE as a community do something about it?

How about creating a middle sized project with a focus on using this technology?
How about if Rocky just picked a few of a group of n volunteers to do it under his direction?

The subject of the app would be his to decide and we'd just do the (yeah, here come's _THE_ word of the year) plumbing. ;)

Anyway, if there's ever a plan to do such a thing, count me in.

Andrés

Um... I'm excited already!

MBonner replied on Tuesday, June 13, 2006

It sounds like he's already decides the subject of the app..."What I'd really like to use as a demo app is some inventory tracking based on real-world experience. Then you can get into fun stuff around random, expiry-based, FIFO and LIFO bin locations and all sorts of stuff."

Now we just need to get this started :-)