Generics List or Custom List

I've been thinking about whether the DBObject should use generics for returning lists or use a custom list object. I think from a coding perspective generics would seem like the easier choice. The DBObject user could just return List and presto you have a list of users! The down side is that you can't add custom functions to the List object. Using the custom list we can create UserList: CollectionBase This would give us a list of user objects that we can add our own methods to.

Why do I think custom methods on the list are important? To prevent unnecessary calls to the Database. With UserList I could get all the users in a project, and then filter out just what I need for each control. Example:

UserList users = users.ByProject(5);
DropDownList active.DataSource = users.Active();
Repeater r_Newest = users.Newest(10);

So instead of making two Database calls for Active users and Newest users, I made one database call and just filtered the data I was looking for. I think this is very important to have as the applications scales.
On the other hand I could do something like make the DBObject keep a cache of it's own data. That just feels like a problem waiting to happen. The only way I can conceive of that is to have an Object Factory

For now I'm just going to stick with the custom lists

.Select()

What I would like to be able to do is something like: UserList = User.Select( AND( LIKE( User.Email, "%gmail.com" ), EQUALS( User.Active, true ) ) ) That way it would be easy to construct whatever select statement is necessary. (I haven't taking multiple tables into account yet.)

I've been thinking about how to actually program this. One thing I found out was that I can't (or I haven't found a way) to send the property of an object without doing a much of extra steps. But what I can do is send the object and the name of the property. So it becomes EQUALS( User, "Active", true )
The other down side is that those functions ( ADD, LIKE, EQUALS ) need to be part of an object... Unless they are Objects themselves. I'm not too found of having the call be something like UserList = User.Select( Selector.AND( Selector.LIKE( User, "Email", "%gmail.com" ), Selector.EQUALS( User, "Active", true ) ) ) I found it annoying to have to have the object name in front of each.

If I made them objects on the other hand, I wouldn't have that problem...

Internal

After writing

PropertyInfo[] obj_properities = this.GetType().GetProperties();
foreach (PropertyInfo prop in obj_properities)
{
    //Is this the Properity we are looking for?
    if (prop.Name == properity)
    {
        //Get the Attributes on the Properity
        object[] prop_attributes = prop.GetCustomAttributes(true);
        foreach (object attribute in prop_attributes)
        {
            //Is this the Column Name?
            if (attribute is DBColumn)
            {
                //Do Something
                break;
            }
        }
    }
}

For the millionth time (or more like 3rd or 4th) I thought it would be nice if the object could provide this information for me. The problem was that I need my Selector object to be able to access this information as well (and I don't want the Selector Object to inherit from DBObject). So I Created another object with some of the information I use more often called Internal (I don't like the name but couldn't think of what else to call it.)

The Problem with this was that I didn't want everyone to be able to call these internal methods. So I created an InternalAttribute, and the Internal object checks that the caller has the InternalAttribue before it'll return any information. This isn't a perfect solution (I'd rather the methods never show up at all) but it seems to work so far.

DBObject

I haven't posted in a while (a year!) I'm working on a .Net project to create a set of MySql Objects. I'm basing this design off of python's SQLObject.

The idea is to create an Object that inherits from DBObject, then set attributes to denote the table and the columns.

Example:

[DBTable("user")]
public class User : DBObject {
   [DBColumn("first_name")]
   public string FirstName
   {
       get { return (string)List["first_name"]; }
       set
       {
           List["first_name"] = value;
           _dirty = true;
       }
   }
}

DBObject would provide some automatic functions like .ByID which will return an object by it's key. Example: User myuser = User.ByID(1);
And .Update() Which will update all the Properties with an Attribute of DBColumn. But it only updates if the object has been marked as dirty (_dirty=true;)

I also want to add a .Select() that allows you to create your own queries. Since you define the object you can define whatever logic the object should have. This helps keep ASP.NET in M.V.C.