MicroLite-ORM / MicroLite

MicroLite ORM framework

Home Page:microliteorm.wordpress.com

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Map private or protected properties

frankiDotNet opened this issue · comments

It is often so,that you want to load something from the database but you want to handle it only in the class. Maybe some basic calculations or a certain way for handling with nummeric enum values that don't exist.
In this case you would use a public property that works with the private or protected field. From outside the class the db field does not have to be changed directly.
For example:

public enum MyColor{
 Red = 0,
 Blue = 1,
 Green = 2
}
[Column("StatusId")] // This won't work
private Int32 ColorValue {get; set;}

public MyColor Color {
    get{  
        if(Enum.IsDefined(typeof(MyColor), ColorValue))
            return (MyColor)ColorValue;

        return MyColor.Green;
    }
    set{
        ColorValue = (Int32)value;
    }
}

I this case you are forced to make everthing public although you don't want to make it accessable directly.
I mean there could be a configuration parameter to enable private mapping or maybe protected mapping.

In your code example, you could just do this:

public enum MyColor
{
   Red = 0,
   Blue = 1,
   Green = 2
}

public class Thing
{
    [Column("StatusId")]
    public MyColor Color { get; set; }
}

Enum integer values get mapped to int values in the database, you don't need to manually convert to/from an int to the Enum value - see Data Type Mapping in the wiki.

Yes I understand, but that was only a abstract example, there are often cases where you want to hide the exact datafield in private scope to let manipulate only part of it or just not give the access to it. Let say you have a bitmask saved in an integer field. In code you would check this by boolean properties that inner access the bits.
Another case is if you save currency values in cent in your db and the user should work only with a decimal or a calculated value.
I mean there are often cases where you don't want to mirror the hole db table in to the same object structure. Databases are not always structured in the way you want them to be.

Even if you look at the example with the enum value. If an enum value is loaded that is not defined in code but a valid value, after loading it and updating it to the db, the value is overwritten with the default value. That is not what you want in this case. You would want to save the original integer value even if your code doesn't know it.

The only suggestion I have for you based upon the current capability in MicroLite is to have a data object which maps to your database and then either have a business object or view model which receives the data object via its constructor to allow you to do what you want as far as encapsulation goes.

There are some changes around mapping planned for MicroLite 7.0 which I'll be working on in the next few months which may offer you other alternatives.

Yes, that's the way I do it now, I am working with a wrapper class. Thought there could be an easier way. Thanks for the reply. Do you have some kind of road map for the version 7? Curious to see what's on the way.

Have a look at the blog, I posted something a while ago, there's also the milestone in the issues page