What bothered me was that the Linq entity code just silently failed. No errors, no nothing. The value was 1. I set it to 2. I checked that it's now 2. I submitted changes. Nothing. SQL Profiler shows that no UPDATE command was sent to the database. No error. Nothing.
What the crap, Microsoft?
After tracking down the bug and getting a primary key added to the table, I did a diff on the old auto-generated entity code vs. the new auto-generated entity code to see how the properties changed. For comparison...
Entity property without a primary key:
public string Name { get { return this._Name; } set { if ((this._Name!= value)) { this._Name= value; } } }
Entity property with a primary key:
public string Name { get { return this._Name; } set { if ((this._Name!= value)) { this.OnNameChanging(value); this.SendPropertyChanging(); this._Name = value; this.SendPropertyChanged("Name"); this.OnNameChanged(); } } }
So the code generator knows that there's no primary key. It uses a different template for the properties in response to this fact. So why can't they take it a step further and make the property a little more informative of this knowledge?
Something like this:
public string Name { get { return this._Name; } }
Or perhaps this:
public string Name { get { return this._Name; } set { throw new SomeKindOfException("Can not update values on a read-only entity collection."); } }
Or even this would be a step in the right direction:
////// Gets or sets the Name property. /// NOTE: Entity collection is read-only, so updated property values /// will NOT be saved to the underlying data source. /// public string Name { get { return this._Name; } set { if ((this._Name!= value)) { this._Name= value; } } }
Again... What the crap, Microsoft?
No comments:
Post a Comment