CODEWITHSUNDEEP
c#linqmapping
Laurent
Laurent

Reputation: 6215

Linq data mapping: usage of Storage property on column attribute

Can somebody please explain the difference between the following 3 possibilities for using the ColumnAttribute:

A: attribute on field

[Column(Name="ParentId")]
private int m_parentid;
public int ParentId { get { return m_parentid; } set { m_parentid = value; } }

B: attribute on property

private int m_parentid;
[Column(Name="ParentId")]
public int ParentId { get { return m_parentid; } set { m_parentid = value; } }

C: attribute on property with storage set

private int m_parentid;
[Column(Name="ParentId", Storage="m_parentid")]
public int ParentId { get { return m_parentid; } set { m_parentid = value; } }

I can understand B would be different from A and C in the case of a non-trivial getter / setter (Linq would presumably use the getter/setter in case B but not in case A or C, is that correct?)

But I don't understand how there can ever be any difference between A and C.

Upvotes: 4

Views: 2412

Answers (2)

Seema Consul
Seema Consul

Reputation: 9

For case A, I agree with Marc Gravell.

In Case B it is just like using a private data member m_ParentId is acccessible through the public property ParentID. And the property is mapped with table column parentId.

Case C will produce error at the time of db.getTable(<Class Name>). Because you are using name and storage properties together.

Upvotes: 0

Marc Gravell
Marc Gravell

Reputation: 1063619

C is useful to allow the engine to understand expression trees, for example a predicate:

var items = ctx.SomeTable.Where(x => x.ParentId == 21);

With "a" I would expect this to fail, as it doesn't really know about the property ParentId (only the field m_parentid and the database column). Specifying the "Storage" in "c" allows the db-value to be saved directly to the field rather than using the property, avoiding code that shouldn't be necessary during materialisation from the db.

Upvotes: 3

Related Questions