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