Design Considerations

Primarily this extension was developed to statisfy the dynamic creation of controls that have dependencies utilizing Dependency Injection (DI) with an eye towards constructor injection; however, there were a few additional constraints in mind (mostly due to a pretty strict policy regarding the MVVM pattern):

• Every View must have a corresponding ViewModel
• The ViewModel knows nothing about the View
• Domain and/or Entity classes will have a corresponding ViewModel
• Domain and/or Entity classes cannot be registered in Unity
• All mapping must take place in the Unity setup/bootstrapping
• Mappings must be human readable and easy to understand for junior developers

I realize that under the hood - the MappingFactory is actually implementing the Service Locator pattern (vs. true DI) which may be considered by some as an anti-pattern (Mark Seemann - Service Locator is an Anti-Pattern); however, this extension abstracts out the Service Locator piece down to its most basic logic. This means first and foremost that it should allow you to plug-in a better solution if one is available. Also, it maintains a clear separation of concerns within the code (important to anyone following the Single Responsibility Principle (SRP).

Please feel free to comment openly. I welcome any feedback! You can also comment on the StackOverflow post where this is discussed or send me a Tweet