I’m a little flabbergasted that Entity Framework does not do anything to enforce the MaxLength on string values. It just passes this responsibility down to the database and catches the resulting (unhelpful) exceptions.

I suppose that there is a justification for this, but from an notably simplistic perspective… Why should I start a transaction and waste precious DB resources, only to get some generic “String or binary data may be truncated” error message back. It would be trivial for EF to use the metadata to ensure that you cannot push a 10 character string into a field that only holds 5.

I’ll grant you that I may want to allow the domain model to store this data temporarily, since it is an acceptable use case to allow a domain model to be in an invalid state during some part of it’s “in-memory” life-cycle. But databases don’t follow this same forgiving behavior. They’re stubborn and just refuse the data with a vague message.

It seems like EF should have a check that it does on the data, prior to committing it, that returns a helpful exception message if some of the data violates the EF model’s constraints. It could even go so far as to tell you which field on which object has a disreputable value.

I know that I can implement this by altering the T4 templates, and this is a huge improvement over past options (I love T4!). But I was surprised to see that EF didn’t provide this out of the box. Not for Self Tracking entities. Not for “standard” entities.

I’ve told Richard Broida that EF is my friend. It’s still my friend. I just want my friend to be more helpful. I guess I’ll pick up the slack for now.