Custom Collection and Filtering Data

[Guest]

As with most web applications speed is a huge deal to me in my applications.
My customers don't really care if my app is a true 3 tier application or not,
they just want it to be faster then it was yesterday. Because of this I try
to limit my calls to the database by using a loading lookup data for a
customer and then filtering down to what I need. (I have alot of recursive
logic because of alot of tree controls).

Here is my question. Why do people build their own filter methods for
custom collections instead of filling a dataset and then filtering the
dataset and reloading the custom collection to reflect what they need to see?


It seems like MS would have made their dataset filter method very fast, much
faster then anything I could do in a true 3 tier evironment.

Like I said before, I am looking for the fastest way to do things in vb.net,
while still making my apps manageable. I am not a zelot about true 3 tier
architecture because I can do alot of things a good bit faster if I mix SQL
into my business layer and execution speed is a big deal to me.

Any comments would be helpful.
Thanks,
Shawn Ramirez

 

[Karl Seguin [MVP]]

The solution most develpoer use is the Query Object design pattern
(http://www.martinfowler.com/eaaCatalog/queryObject.html). The performance
you'll get depends on a lot of things - namely what exactly you are trying
to do and how your architecture is set up. It might be slower than a
dataset's built-in functionality (it's certainly more work for the developer
since you have to code more), but it's also more maintainable and readable.

Many developers, myself included, don't think DataSets have a place in a
medium-large application. Others, believe that they're ok in the Data Access
Layer - in which case you could use their powerful querying. The rest don't
know any different and use them as the only business layer they have. Why
not just use an OR Mapper is my question?

Thankfully, with the introduction of LINQ in 3.0, all of this will become
theoretical babble

Karl

 

[Guest]

Most of my filters are on sets with between 10 and 200 rows. Some get big
however with 1500 rows or so.

The thing is that sometimes I have to filter on 1 field sometimes I have to
filter on 2 and they may not be the same field everytime. So that
flexibilty is a big plus in my eyes.

I will look into the queryObject however. I try to keep an open mind on
this stuff.
If you don't use the DataSet do you use the DataReader to get your data in?

My big question on LINQ is will it be fast, faster then a dataset filter (or
now that I know about it, the queryObject).

Thanks for your time.

 

[Karl Seguin [MVP]]

Ya, I use datareaders to map between my domain and data layer. Again, you
can use an OR Mapper too to do it.

LINQ will work as-is on any class that implements IEnumerable. I can't say
for sure, but ya, it probably won't be as fast. That said, there's also a
new IQueriable (I think that's the name) interface that will allow for much
more specifalized and tuning. I have no doubt that filtering a class that
implements this interfaces will be really fast.

Don't forget that there will be a LINQ for datasets also. I'm sure datasets
will implement IQueriable too. It seems strange to through LINQ onto of
datasets (which already have their own query language - SQL), but I guess
the point is to make it unified...

Karl