Dynamic object

DbEntry supported dynamic object too. It means we just need to define an abstract class with abstract properties. DbEntry will implement it as a real class.

For example:

public abstract class User : IDbObject
{
    public abstract string Name { get; set; }
}
We should using DynamicObject to create this object:

User u = DynamicObject.NewObject<User>();
Also, we can define constructors to the abstract class:

public abstract class User : DbObjectModel<User>
{
    public abstract string Name { get; set; }

    public User() { }
    public User(string Name) { this.Name = Name; }
}
And DynamicObject.NewObject supported it too:

User u = DynamicObject.NewObject<User>("tom");
The default constructor without arguments must exist. It used to load items from database by DbEntry. If we does not define the constructor, the complier will create the default constructor for us. If we decide to define the constructors, the default constructor is needed to define by ourselves.

DbObjectModel owns a lot of functions make our work easier, and it support Partial update too, so I recommended to make the model class inherits form it.

And if there is an abstract function called Init or Initialize, it will be implemented automatically to initialize all the fields. And the parameter's name of init function is NOT case sensitive.

The following code shows it:

public abstract class User : DbObjectModel<User>
{
    public abstract string Name { get; set; }
    public abstract int Age { get; set; }

    public abstract User Init(string name, int age);
}

User u = User.New.Init("tom", 18);
And with the functions inherits from DbObjectModel, it is very easy to use.

Why property

The field is works well, why we need property?

First, by using property, dynamic object builder could add some code to the property set function to make the partial update implements easily.

Second, if we want bind the DbObjectList as a data source to a .Net control such as DataGrid, it makes us do not need to define the columns to the control, just like DataSet.

dataGrid1.DataSource = User.FindAll();
And, sometimes, using ValueType field will cause complain from complier.

So, property is the better way to define columns, and dynamic object gives us a simple way to implemented it without junk code.

Serialization

Dynamic object builder also support serialization. We can just define the Serializable on the class:

[Serializable]
public abstract class User : IDbObject
{
    public abstract string Name { get; set; }
}
Why I mentioned serialization?

Let’s imaging we need to transfer the object from Server to Client. By server side, it created an implemented class and creates an instance of it, and serializes it to send to Client. But the implemented class is in the Server memory, this type doesn’t exist at the Client side, even if we implemented the class in Client side too, the types are not matched actually.

DbEntry handled the serialize and desterilize methods to let the dynamic object serialization works.

I was not tested the serialization of relation objects, but I think it doesn’t matter, because transfer relations object will cause all data of relations be loaded from database, and it’s not what we want. So, transfer the simple object please!

Last edited Dec 10, 2009 at 7:43 AM by lifeng, version 12

Comments

No comments yet.