0

So I have this.

private int _SomeDataBaseField_;
public int ID
{
    get { return _SomeDataBaseField_; }
    set { _SomeDataBaseField_ = value; }
}

What I am trying to do is map the property name and the private field name in a way that I can pull the private field name using the property name only and without using any attributes or tags.

So my question is: Is there any way to deduce the private field name using only the property name? Something like

string PrivateFieldName = typeof(T).GetProperty("ID").GetPrivateFieldName();

Where PrivateFieldName would be SomeDataBaseField. I tried to use reflection but no luck.. This is as far as I got and it only shows the private field type (Int32) which is not very helpful.

foreach (PropertyInfo item in typeof(T).GetProperties())
{
    LocalVariableInfo lv = item.GetAccessors()[0].GetMethodBody().LocalVariables[0];
}

Edit:

I feel I need to explain why I need this. So I have a class that contains 1200+ properties and they all have private fields (backing fields). now I already spent countless hours creating the mysql database table for that class and now that I am using it I realized that I am going to have to manually type the field name every time I need to update one of the fields in the database. So I thought I would use the private field name as a database column and then supply the update function with the property name which would then look up some collection of <'PropertName, PrivateName'> for the corresponding private field name and use that as the database field name. This would not only save time but it would also limit the need for typing the field names over and over again whenever they need to be updated or parsed.

Thanks in advance.

Adel G.Eibesh
  • 481
  • 4
  • 6
  • not that there isn't a valid reason for this, but....why? – ethorn10 Jun 04 '16 at 01:36
  • 1
    What is the problem you're trying to solve? You cannot reliably infer anything about fields from a type's member properties - but I can't think of a problem where you'd need to do this. – Dai Jun 04 '16 at 01:37
  • Updated the post and added the reason why I need this. – Adel G.Eibesh Jun 04 '16 at 01:54
  • If this class is at the database layer, why not just make your public properties be the database field name? Or use an ORM? I think you might be over-engineering this a tad. – ethorn10 Jun 04 '16 at 02:15
  • Because unlike the backing field name the public property name is subject to change. So using the private field name makes more sense. – Adel G.Eibesh Jun 04 '16 at 02:28
  • And what I'm saying is, make this class represent the actual table with public properties matching the field names. Then you can have other classes in other layers that have whatever property names you want and they'll be backed by your database layer class properties....or use an ORM. Also, those backing field names are certainly subject to change. Database columns change names all the time... – ethorn10 Jun 04 '16 at 02:32

2 Answers2

2

Use typeof(T).GetFields instead.

A Property in C# is a logical grouping of two CLR Methods (a getter and a setter). A property does not necessarily have a single backing field - it doesn't have to have any, or it could have multiple. You shouldn't make that assumption.

Dai
  • 141,631
  • 28
  • 261
  • 374
1

Not every property is backed by a single field - all variants 0-infinity are possible, so you need to review what your goals are.

Proper way would be to parse IL of each property get/set pair and find what (if any) packing field their are using. Such approach would let you detect non-trivial properties that use more than one backing field (or none at all). GetMethodBody is starting point for such code - some info can be found in Can I use reflection to inspect the code in a method?


More practical way would be to rely on some sort of convention to find matches.

I.e. for auto-properties compiler generates predictable names (implementation-dependent) and you can find matching field as shown in Is it possible to access backing fields behind auto-implemented properties?.

For other cases there is usually some naming convention - i.e. field with same name but different case/prefix/suffix. Basic string matching would help for such cases.

Community
  • 1
  • 1
Alexei Levenkov
  • 98,904
  • 14
  • 127
  • 179