This post is about WPF / Silverlight separation of concern and on the continues question Who own that XAML?
Before we begin here is my proper disclosure:
I'm not an expert in WPF nor in Silverlight though take this post as a thought sharing and i would like to get your comments on that subject.
The all subject emerge while i was listening to Herding Code podcast about MVVM.
So i was asking myself, how would i assemble UI team and have them working with great productivity and without ruin each other work?
The main failure point that everybody going around is that XAML thing, but some time it seem that the questions people asking isn’t the right one.
I’m thinking that the main question should be
who own the XAML? rather then
who’s touching the it and when?
I will go farther and argue that we should separate the XAML into 2 separate XAMLs.
1. Developer XAML
2. Designer XAML
each of the XAML has very clear ownership and very clear goal.
The developer XAML should be limit to hold sheer functionality without any beauty factor (target for the minimal view developer need in order to get it functioning).
Events wiring actions (not animation) will fall under the developer responsibility, MVVM command is even better.
The Designer XAML should target the followings:
- Enriched data templates
Binding the beauty factor
Farther thinking of switching between the developer view and the designer view, i come to the following idea.
I believe that the code behind should have properties which the data templates and styling should be bind to.
This properties can be initialize form configuration and this way (for testing purpose) we can switch to the developer view to see whether our problem cause by the design or functionality fault.
I believe that following that pattern we will end up with mach clearer separation of concern and higher productivity and maintainability.
I know that there is lot more aspects that i didn’t touch in this post (like unit testing and other) and i encourage you to leave comment expressing your thought on this subject.