Scenario-Driven Design Violated To the Utmost

I like Framework Design Guidelines. It’s a nice guidebook on how to get everyone on your team on the same page and establish common coding practices. While re-reading it, I came across the principle of Scenario-Driven Design (sec 2.2.1) which states the following:

“Framework design should be focused around a set of common scenarios to the point where design process is scenario-driven. We recommend that framework designers first write code that the users of the framework will have to write in main scenarios, and then design the object model to support these code samples.

[…] When designing a framework, you should start with producing a scenario-driven API specification.”

If you subscribe to the Xxxx-Driven Design fashion of the day, you will recognize this advice as the core idea of your methodology. There’s nothing wrong with it. It’s a great idea: put yourself in the shoes of other developers and see how it feels to be them.

Krzysztof (coolest Scrabble name ever!) goes on to say, “There is simply no other way to design a great framework.”

JSON serialization in 2.0

The 2.0 runtime had this handy class JavaScriptSerializer. You could throw anything at it (even anonymous types in 3.5), and it would produce a JSON string out of it with a single line of code!

string json = new JavaScriptSerializer().Serialize (blah);

JSON Serialization in 3.5

Once you upgrade to the 3.5 runtime, all of a sudden you get compiler warnings that JavaScriptSerializer has been deprecated in favor of its older brother, DataContractJsonSerializer.

I’m going to lift a snip from Rick’s blog just to show the contrast:

DataContractJsonSerializer ser = 
   new DataContractJsonSerializer(typeof(Customer));

MemoryStream ms = new MemoryStream();
ser.WriteObject(ms, person);
string json = Encoding.Default.GetString(ms.ToArray());
ms.Close();

All traces of scenario-driven design are gone. This is an example of a typical overengineered Microsoft monstrocity, and we’re not even done yet. You have to go your domain model and decorate classes with [DataContract], and their members—with [DataMember]. All this pollutes your domain model with crap big time.

*sigh* It’s beyond me how someone thought this was acceptable.

I recently posted a review about the book on my blog where I describe how much I like the Framework Design Guidelines, so I can't agree with you more. This book is a must have for each (.NET) development team!

Framework Design Guidelines is a must* for anyone creating application frameworks. After reading this I had such a more in-depth understanding of how to develop better software that integrates seamlessly with the .NET environment I was being tasked with. I really felt after this book that not only was I deviating from the path slightly but that I was missing the boat completely.

As for the monstrosity that you listed above, it can only be expected. I agree that with your terming 'overengineering'...that is about the closest I can get without mention other terms that pop up when I see this kind of ...design (i guess it can be called that)