Next step.

I have two thoughts of what the next step should be. The first is the ability to return a collection of objects (maybe LINQ computable, but I'm not worried about that right now.) The other is that the object should be able to fetch it's own tags.

In my system, each object has tags associated with it. This allows objects to 'subscribe' to other objects. For example, we have a user object and a task object. The user can use tags to subscribe to a task (or many tasks). Many users can subscribe to a same task using this method. The tasks also have an optional prefix. This prefix can say things like; who owns the task, who can modify it, who can complete it, etc. (Just having the tag means you've subscribed and can thus view it.)
So when I get the object it really needs to go and fetch all if it's tags as well.

Because objects rarely have only a single tag, I should probably start with the collections. I'm going to call them lists from now on. These lists must inherit from CollectionBase class in order keep compatibility.

So I think what I want, is a DBList : CollectionBase object that can be used as the return value for static methods.

So I could do something like 

(DBList)DBObject.Where("Age", ">=", "25", typeof(DBUser), Utility.connMy);
and it will return a list of all the users whos age is 25 or older. Or

(DBList)DBObject.Where("Nake", "LIKE", "%chris%", typeof(DBUser), Utility.connMy);

I'm not opposed at all of passing the evaluator as text (">=", "LIKE", "=", "<", etc.) Where this does become a problem is when we need to specify more than a single Where clause. But I figure thats a bridge we can cross when we come to it.