0

So far I was mostly writing my table-column definitions mapping so they look similar to the Linq2SQL style.

eg Linq2SQL

private Nullable<int> _MyColumn;
[Column( Name = "MyColumn", Storage = "_MyColumn", DbType = "int", CanBeNull = true )]
public Nullable<int> MyColumn { get { return _MyColumn; } set { _MyColumn= value; } }

BLToolkit

private Nullable<int> _MyColumn;
[MapField( "MyColumn", Storage = "_MyColumn" )]
public Nullable<int> MyColumn { get { return _MyColumn; } set { _MyColumn= value; } }

It's not really a problem I think, it's just that now I don't know is all this attributes really needed for BLToolkit. Do I need member field _MyValue, or attribute Storage?

Most examples on the BLToolkit wiki site just use the following style to define table columns

[MapField( "MyColumn" )]
public Nullable<int> MyColumn { get; set; }

So my question is. Do I need to use private setter within BLToolkit?

Is there any performance issues with or without it?

Mladen Macanović
  • 1,099
  • 7
  • 17
  • No you don't need to use these private setters, don't know of any performance issues, but I would think the difference will be trivial either way – David DV Sep 02 '11 at 15:53

1 Answers1

0

LINQ to SQL uses the private backing field to allow for the IPropertyNotifyChanging/INotifyPropertyChanged implementations along with the partial methods to allow you to add your own custom logic, databinding, and for the context to watch for the property changes for the update process. You don't get those when using the auto-implemented properties. There is no performance improvement using autoprops at runtime as they are just syntactic sugar over an "anonymous" private backing field that the compiler generates for you.

As for the Storage attribute, in LINQ to SQL, it is used to directly set the private backing field on database reads to bypass the property notification events. For example, if you have an interceptor to watch when INotifyPropertyChanged.PropertyChanged is raised and mark your object as dirty, if you use the public property setters when fetching the object, it will be marked as dirty, but if you use the Storage to point to the private field, it woon't be marked dirty.

All of the above is specific to LINQ to SQL and may or may not apply to the BLTooklit as I am not familiar with that.

Jim Wooley
  • 10,169
  • 1
  • 25
  • 43
  • More or less I already knew why the Linq2SQL is the Storage attribute. What I don't know is it really needed in BLToolkit. – Mladen Macanović Sep 01 '11 at 15:56
  • 1
    This thread may be of assistance: [link](http://groups.google.com/group/bltoolkit/browse_thread/thread/108cc68e68333af2) – Jim Wooley Sep 01 '11 at 17:25