MVC and Entity Framework scaffolding is powerful, but I prefer to know what actually happens before accepting generated code. The code generated to update an entity when an edit has been done looked interesting, so I decided to have a closer look at it.
When an edit is done to an entity, the data is posted as a simple collection of form elements from the web browser. Remember that when working with MVC, we’re closer to the metal than with Web Forms and we are fully exposed to the stateless nature of the web. The gigantic hidden ViewState form field is gone, leaving us in a clean, but stateless world. When the updated data is posted to the server, the server has no more info about it than available in the request. The server doesn’t know where it came from and has to find out itself where, how and what part of it to update.
Tracking changes for objects moving across tiers, being disconnected from their original data source is always tricky. I’m still looking for the silver bullet to this problem and one step in the search is to investigate what other have done. In this post, I’ll take a closer look on how the Scaffolded code of MVC handles updates to EF Entities.
The Pragmatic Programmer has a given place in my list of must read books for professional developers. The subtitle “from journeyman to master” explains the contents very well. The book is made up of short chapters with concrete advice on how to become a master software developer. The 70 numbered tips are short and look simple, but set a really high bar on the standards to strive for. Anyone following a majority of the tips would definitely be considered a master.
Have you heard about the DRY (Don’t Repeat Yourself) principle? This is the book that introduced it and has the original explanation and motivation for the concept. To be a book about software it is remarkable timeless. Most of the tips are as relevant today as they were 10 years ago when the book was written. Source control is now much more widespread than it was back then, but Tip 23: Always use source code control still applies. Believe it or not, there are projects out there without it.
Designing an interface always requires careful considerations of how it will be used. Scott Meyers elegantly catches the entire problem in one sentence in his book Effective C++:
Make interfaces easy to use correctly and hard to use incorrectly.
The people at Microsoft who were in charge for the WCF client code generation either hadn’t read that book or didn’t understand it. They have made an interface that is counter intuitive and hard to use when it comes to disposing of the WCF client.
In my previous post IDisposable and using in C# I wrote that “Always call
Dispose on objects implementing
IDisposable“. This is true, as long as the class implements IDisposable in a reasonable way. Unfortunately the WCF client doesn’t. The MSDN docs presents the problem.
using (CalculatorClient client = new CalculatorClient())
} // <-- this line might throw
"Hope this code wasn't important, because it might not happen.");
That is definitely an example of an interface that is hard to use. The hidden call to
Dispose might throw with a strange exception which sometimes even hides the real error. There is a simple solution though that makes the above code work as expected.
There are lot of code generation tools available. Microsoft Visual Studio has had code generation possibilities since I started using it in the mid 90-ties. Code generation can be a blessing for getting something up and running quickly, but also a curse when maintaining code.
Whenever a code generation tool is considered, there are two very important aspects that need to be considered:
- Is there support for regeneration when the code needs to be updated?
- Are there possibilities to make adaptions without loosing them on regeneration?
Unfortunately a lot of the tools fail on at least one of these points. The blessing that helped creating something working quickly becomes a curse during further development and maintenance.