Click here to Skip to main content
13,403,102 members (51,261 online)
Click here to Skip to main content
Add your own
alternative version


14 bookmarked
Posted 30 Oct 2007

Single Object Property Database

, 30 Oct 2007
Rate this:
Please Sign up or sign in to vote.
Object Properties Snapshot Management


It's a very common practice to use the MVC (Model-View-Controller) pattern in modern applications, especially if the application consists of a few logical parts of the independent modules which communicate among them. Very often in such kinds of applications, we meet a huge number of objects on the view layer of the pattern. It's also very common that a user can operate on objects, modify their properties, move them, delete them or add new objects. As a result, the data layer will be modified.

Recently, I was working on a similar project which necessitated showing the user thousands of objects simultaneously. Every single object can be configured separately, which modification can change the schema representation and logical work flow of the application. In these cases, it is better to try to minimize the amount of memory occupied by the application, but also not limit the user to configuring any objects or their properties on the view.


Here, I try to implement the idea of the "property snapshot" in some lines of the code. The idea is quite simple and the implementation, as well. Let's say I have an object of ObjDef type that represents some logical operation. The user schema consists of thousands of ObjDef objects. So, I create one central database that registers the object and saves its definition of properties. The object type will be considered like a key during the registration. So, even if we have a few ObjDefs, the registration will take it only once. Let's look at an example.

Using the Code

Ok, first of all, we need to prepare our ObjDef class for registering with PropertyMapper. PropertyMapper is the main class for managing property snapshots. For every property that we intend to save with a snapshot, we have to add the MapPropertyAttribute attribute. Let's define the class ObjDef.

public class ObjectDef
        int intValue  = 0;
        string strValue = "Val";
        public enum ValuesEnum: int { High, Medium, Normal, Small, Lowest };
        private ValuesEnum valuesEnum = ValuesEnum.Normal;

        public ValuesEnum Values
                return valuesEnum;
                valuesEnum  = value;

        [MapPropertyAttribute(StandardValue = 1)]
        public int IntValue
            get { return intValue; }
            set { intValue = value; }

        [MapPropertyAttribute(StandardValue = "Hello")]
        public string StrValue
            get { return strValue; }
            set { strValue = value; }


The StandartValue parameter of the attribute defines the rule for property management. The snapshot of this property will be saved only if its value is different from the StandartValue. If we don't define the StandartValue, the snapshot for that property will always be saved. The property can also be registered "manually," without use of the MapPropertyAttribute attribute. In that case, the RegisterProperty(objectType,propertyName) method has to be called. Obviously, it can be very useful in cases where you work on the objects and haven't the source code of them. Ok, now let's look at another couple lines of code.

PropertyMaper pm = new PropertyMaper();     
//   or


//create the object
ObjDef single = new ObjDef();

for (int i = 0; i < 100000; i++)
      single.IntValue = 100 + i;
      single.StrValue = i.ToString();
      single.Values = (Objects.ObjectDef.ValuesEnum)(i % 5);
      pm.SaveObjectProperties(single, "UNIQUE_" + i);                

The pm.SaveObjectProperties(..) function gets following parameters:

  • The object itself, which will be scanned for all properties marked with the MapPropertyAttribute and saved
  • The UNIQUE key identifier that we need to preserve in order to get the saved snapshot values in the moment we need

For example, to get the first snapshot in our case, we need to write:

pm.FillObjectProperties(single, "UNIQUE_" +0);

The single object will be filled with the values of properties saved in the snapshot before, with key value UNIQUE_0.

Points of Interest

As I mentioned before, the idea is quite simple and the implementation, too. This implementation operates only on the properties of the objects, which means that properties must have the read/write access parameters. If a property's return value is the reference type, it must be cloned. In consequence, it must implement the IClonable interface. This model uses reflection to examine the object and, afterwards, access its properties. This obviously creates some application speed performance overhead. It's almost two times slower with respect to the version where we create 100,000 objects and directly access their properties.

Even with these difficulties, in our particular case, we achieve our goal. This is because, even with less speed, we get more than 30% less memory usage and don't limit to the user to accessing any property of any object. I hope my solution will help someone in his work or, if not, will help to design and implement more potential ways of managing object properties in his application.


This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here


About the Author

Tigran Martirosyan
United States United States
No Biography provided

You may also be interested in...

Comments and Discussions

Questionwhy not just use Serialization? Pin
dimzon30-Oct-07 8:31
memberdimzon30-Oct-07 8:31 
AnswerRe: why not just use Serialization? [modified] Pin
Nardi30-Oct-07 9:01
memberNardi30-Oct-07 9:01 
Hi .
Yes the serialization is possible solution .
But in some cases (in our project development and testing ) we noticed that it gets us not prefered performance it terms of speed I mean of course . In out case it wasn't the prefered solution . By the way you are right the serialization is the solution for this pattern also.
Like every solution this is "context" dependent also. Like I mantioned in the article it's only particular view for resolving the problem .
My approach is usefull when you work on the project with many independent connected modules, where probably part of them are the 3d party objects or the source of the object was written by someone many times ago and he isn't here to explain to complex logic of his binaries and if these objects don't support standart .NET serialization . I think this is very common practice to met such conditions during the project development , which actually I met on my latest one. : )
Thank you !

-- modified at 6:41 Wednesday 31st October, 2007

Tigran Martirosyan

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Terms of Use | Mobile
Web04 | 2.8.1802120.2 | Last Updated 30 Oct 2007
Article Copyright 2007 by Tigran Martirosyan
Everything else Copyright © CodeProject, 1999-2018
Layout: fixed | fluid