Search

In my previous post I discussed creating the database and tables for the Silverlight HVP configuration data.  All that was great, and worked just dandy until it was time to get the data from the database server to the application running on the client.

“But,” I thought, “How hard can it be?”  I’ve done a few mini-tutorials… should be straight-forward… And it was… sorta.

At the end of Test Driven Body Snatchers I promised to follow up with a walkthrough of real-world Test Driven Development. What gets into me? Well, a promise is a promise.

It seems reasonable to many developers to create unit tests for their code; but the presumed high cost of doing so implies for waiting for a project that is not in “crunch mode.”  Most developers will be waiting a long, long, long time.

Experience indicates that TDD actually saves time – you spend less time debugging and more time coding. Unfortunately, that sounds like “a good theory” and we all know that in theory, theory and practice are the same, but in practice, they never are.

One of the great pleasures, and total terrors of documenting this open-source application is that occasionally I have to offer up some half-baked ideas that risk displaying how little I know about a particular topic, but which are necessary to generate discussion. Caveat: this is such an entry.  I could have put this into the project documentation but I saw an opportunity to widen the audience on a topic that is important to Silverlight Programmers, even if not part of Silverlight itself.

If there is a commonly reoccurring need for a particular solution, there is a great probability that someone has - by now - solved that need and has finished the legwork involved in researching and constructing something that resolves it. At the very least, you will find documentation on general solutions to related problems that will enable you to gain insight on best practices, effective techniques, and real-world examples on the thing you are creating.

This post uses the Chart default initializer to illustrate how to implement default initializer for Silverlight controls, and explain the underlying editing model architecture.

1. Introduction

In the previous parts of the article I showed you the first two groups of patterns used in the Composite Application Library (CAL) – Composite User Interface patterns and Modularity patterns. In the final part I will show you the third group – Testability patterns.

2. Patterns and Practices in the CAL - quick overview

As a whole the patterns used in CAL can be separated in three main groups:

• Composite User Interface patterns (part 1)
  • Composite
  • Composite View
  • Command
  • Adapter
• Modularity patterns (part 2)
  • Separated interface and Plug In
  • Service Locator
  • Dependency Injection
  • Event Aggregator
  • Façade
  • Registry
• Testability patterns (part 3)
  • Inversion of control
  • Separated presentation

3.

1. Introduction

In the previous part of the article I showed the first part of most important patterns and practices used in the Composite Application Library (CAL). In the second part I will show you the second group – the Modularity patterns.

2. Patterns and Practices in the CAL - quick overview

As a whole the patterns used in CAL can be separated in three main groups:

• Composite User Interface patterns (part 1)
  • Composite
  • Composite View
  • Command
  • Adapter
• Modularity patterns (part 2)
  • Separated interface and Plug In
  • Service Locator
  • Dependency Injection
  • Event Aggregator
  • Façade
  • Registry
• Testability patterns (part 3)
  • Inversion of control
  • Separated presentation

3.