Fighting Your Tooling Sucks

</p>

Here’s a comment from Phil’s testability post:

“I have been working on a project trying to apply these principles and it seems that using the Entity Framework or Linq to Sql, it is hard to have a loose coupling between the UI and the data layer.
This would require the UI to talk only to interfaces so that the data layer’s implementation can be changed easily.
The designers are very nice, but they don’t generate these interfaces, so I had to extract them from the generated classes and make the partial class declarations inherit from these interfaces; this almost looks like a haack.
The interfaces then have to be kept in sync with the generated classes manually.
The good thing I realized in this process is that this way, I can overcome the limitation of the designers to put custom attributes on the entities properties (for validation for example), by applying these attributes to the interface’s property declaration.
Or is there a better way to do this? ”

He’s another user fighting his tools..

And all he wanted to do was decouple his UI from Data Access.

Its too bad that that the tooling took him down the wide/easy road of drag and drop and then left him high and dry when he wanted to do something basic with his design (decoupling).

One might argue that it’s not Visual Studio’s fault that he isn’t sure how to decouple this stuff, but it doesn’t have to be that way.  In my opinion, the tooling should promote good practices (such as decoupling).