Next Step

Well I guess the next thing to do is to allow an object to relate to another object. For work I use tags for objects (as I discussed earlier) so that's going to be my starting point.

So I have two objects. User and Tag.

A single User record can have an unlimited number of tags.
A single tag record can have only one user. But a Tag object can have an unlimited number of users.

So we have a many to many relationship, with a table joining them. The table already exists (tag_user) so I need to specify that.

When I get a user, it should get all of his tags as well, like wise when getting a tag it should get all the users. except that might not always be a good idea. What if I have 10,000 users with the tag 'Public' I might want to get that tag without getting all the users who have that tag. alsoIf i'm getting a list of users and they all have the 'Public' tag, it shouldn't the tag shouldn't pull that list of 10,000 for each user in my list. It should only pull it once, and thats only if I ever request it.

So I need to do some lazy loading. Say it only gets the related object if it's requested. So if I get a list of users, it'll just fill out that list. If I access the tags on one of the users, then it'll go and fetch his tags.

So first things first:

Create Many to Many relationship, if you access the related object, then it goes and gets it.

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.