0

到目前为止，我主要编写表列定义映射，因此它们看起来类似于 Linq2SQL 样式。

例如 Linq2SQL

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

BL工具包

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

我认为这并不是一个真正的问题，只是现在我不知道 BLToolkit 是否真的需要所有这些属性。我需要成员字段_MyValue还是属性Storage？

BLToolkit wiki 站点上的大多数示例只是使用以下样式来定义表格列

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

所以我的问题是。我需要在 BLToolkit 中使用私有设置器吗？

有或没有它是否有任何性能问题？

4

1 回答 1

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.

于 2011-09-01T14:35:46.223 回答