MEF4

There is a great set of Webcasts on application of MEF4 in Silverlight applications

http://mtaulty.com/CommunityServer/blogs/mike_taultys_blog/archive/2009/12/31/silverlight-4-screencasts-the-managed-extensibility-framework-mef.aspx

I have reproduced the examples in this set of webcasts. Now I would like to do exactly the same but with a WPF application. Unfortunately the .net assemblies that come with vs2010 Beta 2 do not include System.ComponentModel.Composition.Initialization.dll. When I try to use the DLLs from the Silverlight SDK in a WPF application I get a System.Windows.Markup.XamlParseException.

It is only a matter of time before this will be available also for non Silverlight applications. I have asked a question concerning this in

http://social.msdn.microsoft.com/Forums/en-US/MEFramework/thread/7eeabad4-73db-4f57-a01a-2b326b90b129

Here’s an example from this set of webcasts of the kinds of things that MEF4 can do in the way of dependency injection:

Here is an interface describing what it means to be a TextEngine:

using System;
namespace SilverlightApplication1
{
    public interface ITextEngine
    {
        string Name { get; }
        void ProcessText(string text);
    }
}

Here are 2 implementations of the Text Engine

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.ComponentModel.Composition;

namespace SilverlightApplication1
{
    [Export(typeof(ITextEngine))]  // Means I am a composable component
    public class TextEngine : ITextEngine
    {
        public string Name
        {
            get
            {
                return "default";
            }
        }
        public void ProcessText(string text)
        {
        }
    }
}

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.ComponentModel.Composition;

namespace SilverlightApplication1
{
    [Export(typeof(ITextEngine))]
    public class FancyTextEngine : ITextEngine
    {
        public string Name
        {
            get
            {
                return "FancyDefault";
            }
        }
        public void ProcessText(string text)
        {
        }

    }
}

Here is an implementation of a Word processor that consumes the Text Engines

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.ComponentModel.Composition;

namespace SilverlightApplication1
{
    [Export]  // Means I am a composable component
    public class WordProcessor
    {
        [ImportMany]
        public IEnumerable<ITextEngine> TextEngines { get; set; }
    }
}

Finally here is an application that consumes the WordProcessor

using System;
using System.Collections.Generic;
using System.Linq;
using System.Net;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Documents;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Animation;
using System.Windows.Shapes;

using System.ComponentModel.Composition;

namespace SilverlightApplication1
{
    public partial class MainPage : UserControl
    {
        [Import] // Menas this class needs a WordProcessor
        public WordProcessor WordProcessor { get; set; }

        public MainPage()
        {
            InitializeComponent();
           PartInitializer.SatisfyImports(this);
        }

    }
}

MEF resolves the imports and exports on the line PartInitializer.SatisfyImports(this);

MEF4 is really a useful tool for decoupling with dependency injection, there are many places where customization is possible. For example components can be lazy loaded, it is possible to set constructor parameters, the containers can be configured so that the source of assemblies can be customized, custom compiler attributes can be used to set metadata that can be used to make readable use of specialized components etc etc.

The web casts are really worth watching.

First steps with WF4 in VS2010 Beta 2

Here are some useful links:

http://msdn.microsoft.com/en-us/netframework/wf-webcasts.aspx
http://channel9.msdn.com/posts/mwink/Rules-Driven-UI-using-WF/

http://msdn.microsoft.com/en-us/library/ee342461.aspx

There are a series of good webcasts at:
http://bloggersguides.net/

Getting started
http://msdn.microsoft.com/en-us/library/dd489454(VS.100).aspx

http://msdn.microsoft.com/en-gb/netframework/first-steps-with-wf.aspx
http://blogs.msdn.com/mwinkle

Here is how to create a hallo world WF4 Console Application.
1. Create a New "WorkFlow Console Application
2. Modify Program.cs to

using System;
using System.Linq;
using System.Activities;
using System.Activities.Statements;

namespace WorkflowConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            WorkflowInvoker.Invoke(new Workflow1());
            Console.WriteLine("Hit to quit");
            Console.ReadLine();
        }
    }
}

3. Add a new project of type Activity Library
4. Add a reference from the console application to the Activity library project
5. Add a new Code Activity to the Activity libray

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Activities;

namespace ActivityLibrary1
{

    public sealed class NigelRead : CodeActivity
    {
        // Define an activity input argument of type string
        public OutArgument<string> Text { get; set; }

        // If your activity returns a value, derive from CodeActivity<TResult>
        // and return the value from the Execute method.
        protected override void Execute(CodeActivityContext context)
        {
            // Obtain the runtime value of the Text input argument
            String t = Console.ReadLine();
            Text.Set(context, t);
        }
    }
}

6. Add anothe Code Activity
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Activities;

namespace ActivityLibrary1
{

    public sealed class NigelWriteLine : CodeActivity
    {
        public InArgument<string> Text { get; set; }
        protected override void Execute(CodeActivityContext context)
        {
            string test2 = Text.Get<String>(context);
            Console.WriteLine(">" + test2);

        }
    }
}

7. Add a new Activity
8. Rebuild the solution
9. Add a FlowChart
10. Drag and drop 1 NigelWriteLine 1 NigelReadLine and 1 NigelWriteLine into the flow chart
11. Join the three activities together under the green start circle
12. Click the Variables tab and Add MyName as a string with a defaul vbalue "Unknown"
13. In the Text field of of the first NigelWriteLine set "What is your name?"
14. In the Text field of NigelReadLine set MyName
15. In the Text field of NigelWriteLine set MyName
16. Rebuild the solution
17. In the Workflow1.xaml file drag and drop the activity just created
18. Run the Application

The result will be
>What is your name
Nigel
>Nigel
Hit to quit

Since the work flow is an object stack, here is an alternative way of executing the workflow:

Sequence wf = new Sequence
{
    Activities = {
        new CodeActivity1{Text="Hallo World"}
    }
};
WorkflowInvoker.Invoke(wf);
MessageBox.Show("WorkFLow Complete");

If you have have a long running task then derive from AsyncCodeActivity or CodeActivity<T>
Then you have to implement BeginExecute and EndExecute

There is an example showing how persistance works here http://stackoverflow.com/questions/2021433/windows-workflow-foundation-4-0-and-persistence

The database scripts are found in C:\WINDOWS\Microsoft.NET\Framework\v4.0.21006\SQL\en

SqlPersistenceService_Schema.sql
SqlPersistenceService_Logic.sql

It should work by creating a SqlWorkflowInstanceStore. Unfortunately on my version of the Beta of VS2010 I could not resolve this.

Designing Inheritance Hierarchies by Brad Adams

Here are some notes from a presentation on Designing Inheritance Hierarchies by Brad Adams

The Danger of Over Design
Here is the most common mistake story. A new program manager is appointed who is given the task of producing a new widget feature. He then starts producing the most phenomenal feature. Make it super feature rich by doing a lot of competitor analysis making sure that every feature from every competitor is covered. Then they have this really complex extensibility story so that any partner can plug in and do anything. Then the development starts and we are half way through, then the reality of shipping sets in and you get a mail from one of the release managers saying if its not done it's cut out. So we have to decide on which features are actually going to survive and which are going to be cut. At this point we don't usually make a deep reflection over how can we redesign this thing to make it simpler so it's scoped to fit. Instead we will look at what has a long bug trail. So what happens is you end up shipping this thing with the wire still hanging outside of the box, with a design that is not quite complete because we have lopped of some things. So not only did it not fully meet the requirements but even worse in VNext when we actually know how we need to make this thing extensible ie concrete partner requirements well thought out design and a well thought out extensibility scenario we are actually stopped from doing it becuse the wires are still hanging out of the box. In other word we do not still have freedom of design.

Moral: Do the absolute minimum know so that you have the freedom in the future to add the more extensibility that's needed

The point is that we absolutely know that certain products will have a next version. So you can do the minimum now and add more to it in the future.

Abstract and Base Classes
- Base Classes serve as the roof of an inheritance hierarchy
- Abstract classes are a special kind of base class that are non-instantiable and may NOT contain members that are not implemented
- Prefer broad, shallow hierarchies
  - Less than or equal to two additional levels = rough rule
- Contracts and responsibilities are difficult to maintain and explain in deep complex hierarchs.

Consider making base classes not constructible (eg use abstract classes)
- Make it clear what the class is for (is it a utility class OR is it a base in a hierarchy)
- Provide a protected constructor for subclasses to call
- A bad example is System.Exception should not have a public constructor

Virtual, abstract and Non-Virtual Methods
- Virtual members are points of specialization or callbacks in your code
  public virtual int Length [ get {...}}
  This is like saying this is code, I am not in love with it, you are free to override it with your own provided you meet the contract
- Abstract members are required points of specialization in your code
  public abstract int Root()
  This is like saying There is no seed code for this method, you must implement it yourself to the contract specified
- Non-virtual members cannot be overridden in derived types
  public string Remove (int index, int count)
  This is like saying, I AM in love with this code, when ever this is called I want to be sure that my implementation of the code is being used because I have some dependency on this.

There is not enough time to make something infinitely extensible so it is important to make sure that the extensibility hooks are in place. So by default you make it non virtual and then as you understand the extensibility requirements you can make those things virtual. It is not a breaking chnage to go from non-virtual to virtual. But it is a breaking change to go from virtual to non-virtual.

Virtual Methods An example of where it goes wrong

public class TheBase : Object
{
  public override string ToString()
  {
     return "Hallo from base";
  }
}

public class Derived : TheBase
{
  public override string ToString()
  {
     return "Hallo from derived";
  }
}

One problem above is that Object.ToString should give the type name. So what gets printed out in the following examples

Dervived d = new Derived()
Console.WriteLine(d.ToString());

TheBase tb = d;
Console.WriteLine(tb.ToString());

TheBase o = d;
Console.WriteLine(o.ToString());

The answer is...
Virtual methods all output "Hallo from Derived"... Why?
- Method call virtualizes at run time
- The static type doesn't matter
- "The most derived guy wins"
The danger am the power of virtual methods
- Danger: Owner of the base classes cannot control what subclasses do
- Power: Base class doesn't have to change as new subclasses are created

Overriding
- Don't change the semantics of member
  - Follow the contract defined on the base class
- Don't require clients to have knowledge of overriding (ie no checking for types)
- Consider whether you should call the base implementation
  - Choose to call it unless you have good reason not to

Virtual and Non-Virtual
- Use non-virtual members unless you have specifically designed for specialization
  - Have a concrete scenario in mind
  - Write the code!
  So you should be able to answer the question "why is that member virtual?" The answer should be a useful example of how this should work on a concrete scenaro and that no more is required
- Think before you virtualize members
  - Modules that use references to base types must be able to use references to derived types without knowing the difference
    - Must continue to call in the same order and frequency
    - Cannot increase or decrease range of inputs or outputs
  - See the Liskov Substitution Principle

Abstract Members
- Methods, properties and events can be abstract
- Use abstract members only where it is absolutely required that subclasses provide a custom implementation
- Only use when the base class cannot have any meaningful default implementation
The thing that really bothers Brad is that there is an increased opportunity for bugs to be introduced

Abstract, Virtual and non-virtual members
- Default to making non-virtual
- Make virtual if it is designed to be specialized by subclasses
- Make abstract if no meaningful default implementation is possible
  - Unless versioning issues prohibit it, in which case throw NotImplementatedException

Interfaces vs Base Classes
Choose to use Base classes over interfaces
- Bases classes  version better in general
  - Allows for adding members
- Members can be added with a default implementation
  - Avoid incompatibilities common in MS ActiveX (Interface based)
- Interfaces are good for versioning behavior (changing semantics)
- Avoid having both base class and interfaces
  - Adds confusion about which to use (so do decide)
    - Component vs. IComponent
  - Little advantage
- Consider using aggregation
- Don't use attributes where a contract is needed

Aggregation
- Some of the needs for multiple inheritance can be solved with aggregation
- Instead of having C derive from A and B, have C derive from A and have member that returns an instance of B

// WRONG
public class C : A, B {}

// RIGHT
public class C:A
{
  public B MyB { get{...}}
}

Versioning of interfaces

Version1
interface IStream // version1
{
  void Read (byte[] value);
}

class FileStream: IStream
{
  public void Read (byte[] value){...}
}

Version2
interface IStream // version1
{
  void Read (byte[] value);
  void Write (byte [] value); // WRONG TypeLoad Exception in FileStream
}

In the java world this became such a problem that they took this check out of the compiler

Versioning of Base Classes
Version1
public class Stream
{
   public virtual void Read(Byte[] value {...}
}

public class FileStream : Stream{
   public override virtual void Read(Byte[] value {...}
}

Version2
public class Stream
{
   public virtual void Read(Byte[] value {...}
   public virtual void Write(Byte[] value {...}
}
FileStream continues to work with default implantation for Write()

Interface Usage
public interface IComparable
{
  int CompareTo(object obj):
}
- Interfaces are useful
- The smaller and more focused the interface the better
  - 1-2 members are best
  - But interfaces can be defined in terms of other simpler interfaces
  - Eg IComparable, IFormattable

Explicit Method Implementation
- Implementing members of an interface "privately"
  - Not a security boundary (because you can cast that type into it's base type)
- Only accessible when cast to the interface type
- Hides implementation details
  - Clean public interface
    - IConvertable on Int32 etc
- Differentiates implementations
- Simpler strong typing

Explicit Method Implementation: Clean Public Interface
- The 19 ToXxxx methods on IConvertable don't "pollute" the Int32 public view
- But they are there when the case to IConvertable
Solution is to implement them privately

public struct Int32 : IConvertable, IComparable
{
   public override string ToString () {...}
   int IConvertable.ToInt () {...}
   ...
}

int i = 42;
i.Tostring();                  // Works
i.ToInt32();                   // Does not compile
((Iconvertable), i).ToInt32(); // Works

Explicit Method Implementation: Differentiates Implementations
- Interface developed by different groups can have the same signature for different meanings
  - Draw() a picture and Draw() a gun (wild different implementations)
- Frequently you want to differentiate the implementation
- Explicit method implementations enables this
- Avoids us recommending "unique" names in interfaces

interface IGraphics
{
   void Draw();
   Brush Brush {get; set;}
   Pen Pen {get; set;}
}

interface IBandit
{
   void Draw();
   void Duel(IBandit oponnent);
   void Rob(Bank bank, IBandit[] sidekicks);
}

class Bandits: IBandit, IGraphics
{
  void IBandit.Draw() {...}
  void IGraphics.Draw() {...}
}

Framework Design Guidelines by Krzysztof Cwalina

I have just started reading a great book about Software Architecture by Cwalina Krzysztof. Here are some notes I have made from a presentation on the CD that comes with the book. Unfortunately an electronic version of the presentation was not available.  The book goes into the Design aspects in great depth and it is a great read.

The Processes Affecting Framework APIs are
- Organization
- Planning
- Architecture
- Design
- Development

Organization: The most powerful design tool

The size of the organization will determine if you have a large or a small set of APIs

Project Management Triangle: Scope Cost Time
Assumes costs are uniform ie add/remove 1 person has a proportional effect
Project Management Square: Scope Cost Time Organization

Organizational Influences
- Size of the Organization
  - Small Team -> Simple Design
  - Large Team -> Powerful Design
- Organization's Culture/Biases
  - Customer-Focused -> End-2-End Scenarios
  - Technology-Focused -> Long Lasting Architecture
- Decision-Making Process
  - Individuals Empowered -> Time to Market
  - Hierarchy -> Interoperability and integration
  - Consensus -> Team building

DO: understand how the organizational structure, culture and decision making processes impact your product

Planning: Make sure we are building the right thing?

Peanut Butter vs Skyscrapper

Peanut butter
Focus: features
Results: stability
Incremental improvements, not great end-to-end scenarios
Does not require so much interaction across teams

Skyscrapers
Focus: scenarios
Results: Excitement, breakthroughs, but beware of leaving existing customers behind
Requires interaction with other teams

AVOID: Peanut butter

Architecture: Ensuring the long term health of the framework
DO: Manage your dependencies

Component and Componentization
- A component is a set of types that ship and evolve as a unit
- Componentization is a process of organizing types into components, with explicitly designed controlled dependencies between components
- NOTE: Componentization is different from assembly factoring (ie an assembly might have more than one component)

Types of Dependencies
API Dependency
Component A has an API dependency on component B, if a type in B shows in the publicly accessible (public or protected) API surface of a type in A. This includes
- Base types and implemented interfaces
- Generic parameter constraints
- Return types and parameters of members
- Applied attributes
- Nested types

Implemented Dependency
If a type in A uses a type in B in its implementation
- Hard dependencies (required to run)
- Soft dependencies (optional)

Circular Dependency
Occurs when component A depends on Component B and component B depends on component A (even indirectly)
- Note: Two (or more) components with a circular API dependencies can be considered a single component for all practical purposes.

Framework Layering
Layering is a process of organizing components in layers and enforcing dependency rules between components in these layers
Distinguish between Core components these are components that are required throughout. This is important from a dependency point of view because it limits what can be replaced

Dependency Management Rules
-Types in a component can freely depend on each other
-Cross component dependencies must be carefully controlled
  - A component can freely take dependencies on components in a lower layer
  - A component must not have hard coded dependencies on components in higher layers
  - A component should avoid soft dependencies on components in higher layers
  - Dependencies between components of the same layer must be carefully managed.[NOTE: we have an approval process for this]
- In general it's good to minimize dependencies, if it does not create to much duplication (bloat)

Taxonomy of Types and Framework Architecture
- Primitives
- Abstractions
- Reusable Components

Primitives
- Very little policy (behavior design decisions)
- Stable design
- Commonly appear in publicly accessible APIs
- Almost impossible to evolve/change design, any design changes have huge breaking change impact on other APIs
- eg Ing32, String

DO: Use the least policy! because at sometime you might want to revisit that decision!!!

Abstractions
- Interfaces, abstract classes, some concrete classes with extensive virtual surface
- Similar to Primitives (show in APIs), but usually have more policy(through less than libraries)
- Hardest types to design right
  - With the exception on a few historically well understood abstractions (lists, streams etc) abstarctions with more that 2-3 members are rarely successful
- Difficult to evolve
- Glue between parts of the framework
  - Through polymorphism
- Very useful for decoupling components
- eg Stream, IEnumerable<T>
DO: Keep them extremely simple

Reusable Components
- Perform operations on primitives and abstractions (or the system)
- Almost never passed around
- Change often as frameworks evolve
  - XmlDocument(Fx 1.0 - XML DOM)
  - XPathDocuments(Fx 2.0 - XPath)
  - XDocument(Fx 3.5 - Linq to XML)
- Relatively easy to evolve (if designed and used properly) they can be simply replaced
- Eg XmlDocument, EventLog, SerialPort

Easy to evolve
DO NOT: Mixing types eg Primitives, Reusable components

Component Orientated Design
- Rich APIs with lots of features, thus with lots of dependencies
- Great usability, poor evolvability
- Eg Object.GetType() - Every object has a very easy access to its type but also every object depends on Reflection
- Good higher level components, not for the core of a platform
- NOTE: "Componenet" is an overloaded term. In this context it does not have anything to do with componentization. Unfortunately COD is already an established term

Primitive Orientated Design
- aka Handle base design (functional)
- Great evolvability, poor usability (sometimes)
- Low level stable primities + highlevel reusable components with limited dependencies other than to the primitives
- EG Type.GetType(object> - works but not as convenient as Object.GetType

Improving Usability of Primitive Oriented Design
- Members with heavy dependencies can be extension methods for primitives in a separate component
- This is essentially functional programming

// low level assembly with no dependency on globalization
namespace System
{
  public struct Decimal
  {
    public string ToString(); // Culture independent
  }
}

// higher level assemblynamespace System
{
  public static class DecimalFormatter
  {
    // decimal point character is culture sensitive
    public static string ToString(this.Decimal d, string format); // Culture independent
                                //====
  }
}

NOTE: Same namespace makes the API easy to use

DO: Balance advances with compatibility
People underestimate the advantages of compatibility. When you break something how much are you improving?

Types of Compatibility, which do we need
- Cross-Version Compatibility: Code written for a version of a redist works on a different version of the same redist
- Cross-Redist Compatibility: Code written for a redist works on a different redist
- Backward compatibility: Code written for a version of redist works on a newer version of the same redist
- Forward compatibility: Code written for a vcersion of a redist works on a previous version of the same redist

Forward is important for service components

- Binary Compatibility: a binary runs on a different version of a different redist than what it was build for without recompilation
- Source Compatibility: Source code compiling on a version of redist can recompile without changes on a different version of a different redist
- API Compatibility: Stronger than source. Weaker than binary. Source compatibility allows for some changes in APIs (ge covariant changes to input parameters). API Compatibility does not.

Establishing Compatibility Bar
- Define what is a breaking change
- This definition depends on the objective
  - Eg Enable portable code between Silverlight and .Net Framework
  - Eg Enable cross version portability
- For example, Silverlight interfaces cannot have less members than .NET interfaces, but concrete types can.

AVOID: Duplication and Overlap

When to replace existing APIs
- When the new technology is "10x better" (It cannot be a small improvement)
- Make sure you understand the impact on theecosystem
  - What would happen if the BCL team added a new String?
- Whats the migration path for code using the old API

Design: This is where quality happens

DO: Design APIs first by first writing code samples for the main scenarios and then define the object model to support the code samples
You cannot start with a UML Case tool and starting to decide entities and primitives of the system. Case tools are designed for internal implementation where you are trying to minimize ripple effects. API design has different constraints because once you ship it you can't change it

DO: Treat simplicity as a feature

Simplification Techniques
- Remove Requirements
- Reuse Existing Concepts or APIs
- Adjust Abstraction Level eg making an API for printer proporties -> Just get a XML document with Printer properties

Measure Measure Measure: It is not the act of measuring that is important its the decision what to measure that is important

Specification Document: Qualities
- Performance Goals
  - Baseline: What is the best my components could do?
  - Measure delta from the baseline
- Threat Models
  - Threat: What is the worst that my components could do
  - Mitigate the threats
- Same for many other qualities you want your framework to have
These are things that we want to design in eg security.

Development The bits customers get.. or not
Development happens in branches that periodically integrate into the product tree

AVOID: Integrating unfinished features
Because once you check it in people can take dependency from it

Feature Complete & Quality Gates
- Functional Specification
- Developer Design Specification¨(eg FxCop)
- Test Plan
- Threat Model
- API Review
- Architectural Review
- Dependency Management
- Static Analysis
- Code Coverage
- Testing (Unit and Integration)
- 0 bugs
- Performance

DO: Pay your debt
Stop from time to time to improve what you have implemented already

Milestone quality MQ
- Initiatives that are hard to do in regular milestones
- Large productivity and efficiency improvements
- Infrastructure changes
  - For example a new source control system
- Refactoring of fragile subsystems
- Internal implementation documents
- Bug backlog

What is the debt that we acquired during the last release? The framework is a fragile thing and it's important to get it right. This is a way to slow this down and stop

I