Regulator is the object which holds the responsibility of managing the control flow between group of related objects by handling the state change of the objects and passing messages between them.
Components
Regulator / FowControlManager : Holds the instances of related objects (Colleagues) and observes the Colleagues for change in their state.
Colleague : Ability to notify the change in its state and focuses on its core responsibility. Wont hold reference to any of related objects or Regulator.
Scenario
Consideration : Silverlight application following MVVM.
Generally in Silverlight applications we use to separate the application into individual modules in order to create seperate XAP files and download to use it as and when needed. Let us imagine such a small module which has a landing page displaying some details along with few links(Detail1,Detail2). Upon clicking the links, the respective views(DetailView1, DetailView2) need to be displayed on the desiered location on the landing page itself. Also different messages need to be sent to different views based on the behavior and actions performed in other views and landing page.
Simply we can handle this by hand over the entire responsibility to the ViewModel of the landing page. If we do so, the landing ViewModel need to hold this control flow management and message passing mechanism in addition to its functionality.
Instead if we have an object that manages the flow control and message passing, then the respective ViewModels can just concentrate on their functionality without bothering about flow of control and message passing.
If Detail1 link is clicked on the landing page, Regulator takes this responsibility by observing Detail1 link got clicked on landing page, pass required details to the DetailView1.ViewModel and passes the DetailView1 to the LandingPage.
Component Responsibility
Colleagues just notifies about change of state which need to be observed.Regulator observes the state changes of the Colleagues as it holds their instances, passes the needed messages to respective instances and controls the flow.
State change can be notified through effective use of events and NotifyPropertyChanged mechanism we use in Silverlight.
Related patterns
Most of you might have already smelled the flavour of Mediator, Observer and Facade pattern.
Its true but the notion differs.
Unlike Mediator pattern, Colleagues in Regulator pattern won't hold reference to Regulator instance. Regulator itself subscribes to required state change notification of Colleagues.
Edit
10JAN2011
My friend upon having a glimpse at the title asked me where did I got the title from? Actually I should have specified about this at time of writing the article itself. I just named it based on the functionality and nature of implementation. Just thinking whether I've done anything unlawful.
Showing posts with label Patterns. Show all posts
Showing posts with label Patterns. Show all posts
Saturday, January 8, 2011
Saturday, December 25, 2010
Pattern for Silverlight child window
RAVAGE
I just wanted to convey the enitre motivation of this article in a simple sentence which resulted in the 'keyword like' entry as the title "Pattern for Silverlight child window". As per my observation the UI approach (way of presentation to the end user) for Silverlight varies with that of ASP.Net UI. In most of the Silverlight applications that I visited, I didn't noticed the heavy usage of the child (popup) window for interaction purpose except the light usage of notification purpose such as confirmation / information display dialogs. If we do need to use the child window for interaction purpose, then the first idea that we need to plan is about how to share object between the parent and the child window.
I came across a similar situation in my project where my client wanted to present the child window for interaction purpose in order to produce a native UI approach. I thought of implementing this without breaking the MVVM pattern. To achieve that, first I thought of sharing the same ViewModel object between the parent and child. It got ruled out immediately due to well know reasons of maintainabiltiy and scalability. Not all the members of the object will be common for both parent and child window. Hence sharing same ViewModel / object won't be the right choice.
Next option is to have two seperate view models for parent and child dialog holding reference to each other. This is better than the previous one, but think of the case having more than one child window which will result in the parent holding reference to each of the child window and each child window holds reference to the parent. Going one step forward, think of a case having more than one parent view and multiple child view which are related, might end up with each object having reference to other as a worst case scenario. So, are there any pattern that provides solution for the above case? Yes, as many article over the web suggests, Mediator pattern provides us the solution.
MEDIATOR FOR PARENT-CHILD VIEW
Mediator holds the instances of the parent and child objects and manage the interactions between the objects. The parent and child objects in turn holds the reference of the mediator and notifies the mediator about the relevant changes. Having received the change notification, the mediator will call the required update / action aginst the objects in relation to the change.
I implemented this change in my project and worked fine for me. But out of curiosity, I further fine tuned this implementation such that the parent and child view objects interact with the mediator using Observer pattern.
The implementation goes something like as follows:
I created an abstract class called Colleague which holds the instance for the Mediator as a property and an Update method which can be overriden by the class that inherits it.
Then I created an Mediator class which provides the methods to Attach, Detach and Notify. The Attach methods takes in an object of type Colleague as parameter and adds to a list of Colleague(to be notified). The Detach method takes in an Colleague type as parameter which removes from the list of Colleague. The Notify method iterates through the list of Colleague object and calls the Update method on each Colleague object.
The parent and child ViewModels inherits the Colleague class and overrides the Update method if needed. For example I was about to pass a selected item from my child ViewModel to my parent ViewModel. To achieve that upon selecting a particluar item from a list of items in the child view, I'll call the Notify method of my Mediator by passing the selected item. My parent ViewModel in its constructor will subscribe to receive the notification by calling and passing itself as paramter to the Attach method of the Mediator object. Upon the Mediator receives the notification from child view, it calls Update method of the Colleague (parent in this case) which got subscribed to it.
STRUCTURE
I actually have described an idea about the implementation in my project. Based on my project scenario, I had extended the same concept to handle multiple parent and child view models for which the usage of Observer pattern for interaction with the Medaitor helped me to produce a scalable and maintainable code. On the whole my idea is to implement a Mediator which acts as a change request manager holding the responsibility of interaction between the ViewModels. In my case, since I had only one change request manager (Mediator), I eliminated the introduction of abstract Mediator class. After completing my implementation, I realized that single instance for my Mediator holds good for my scenario. Hence, finally I also implemented Singleton pattern for my Mediator class.
I just wanted to convey the enitre motivation of this article in a simple sentence which resulted in the 'keyword like' entry as the title "Pattern for Silverlight child window". As per my observation the UI approach (way of presentation to the end user) for Silverlight varies with that of ASP.Net UI. In most of the Silverlight applications that I visited, I didn't noticed the heavy usage of the child (popup) window for interaction purpose except the light usage of notification purpose such as confirmation / information display dialogs. If we do need to use the child window for interaction purpose, then the first idea that we need to plan is about how to share object between the parent and the child window.
I came across a similar situation in my project where my client wanted to present the child window for interaction purpose in order to produce a native UI approach. I thought of implementing this without breaking the MVVM pattern. To achieve that, first I thought of sharing the same ViewModel object between the parent and child. It got ruled out immediately due to well know reasons of maintainabiltiy and scalability. Not all the members of the object will be common for both parent and child window. Hence sharing same ViewModel / object won't be the right choice.
Next option is to have two seperate view models for parent and child dialog holding reference to each other. This is better than the previous one, but think of the case having more than one child window which will result in the parent holding reference to each of the child window and each child window holds reference to the parent. Going one step forward, think of a case having more than one parent view and multiple child view which are related, might end up with each object having reference to other as a worst case scenario. So, are there any pattern that provides solution for the above case? Yes, as many article over the web suggests, Mediator pattern provides us the solution.
MEDIATOR FOR PARENT-CHILD VIEW
Mediator holds the instances of the parent and child objects and manage the interactions between the objects. The parent and child objects in turn holds the reference of the mediator and notifies the mediator about the relevant changes. Having received the change notification, the mediator will call the required update / action aginst the objects in relation to the change.
I implemented this change in my project and worked fine for me. But out of curiosity, I further fine tuned this implementation such that the parent and child view objects interact with the mediator using Observer pattern.
The implementation goes something like as follows:
I created an abstract class called Colleague which holds the instance for the Mediator as a property and an Update method which can be overriden by the class that inherits it.
Then I created an Mediator class which provides the methods to Attach, Detach and Notify. The Attach methods takes in an object of type Colleague as parameter and adds to a list of Colleague(to be notified). The Detach method takes in an Colleague type as parameter which removes from the list of Colleague. The Notify method iterates through the list of Colleague object and calls the Update method on each Colleague object.
The parent and child ViewModels inherits the Colleague class and overrides the Update method if needed. For example I was about to pass a selected item from my child ViewModel to my parent ViewModel. To achieve that upon selecting a particluar item from a list of items in the child view, I'll call the Notify method of my Mediator by passing the selected item. My parent ViewModel in its constructor will subscribe to receive the notification by calling and passing itself as paramter to the Attach method of the Mediator object. Upon the Mediator receives the notification from child view, it calls Update method of the Colleague (parent in this case) which got subscribed to it.
STRUCTURE
SUMMARY
Sunday, August 1, 2010
Dependency Injection
RAVAGE
After several years of familiarization of the concepts of Dependency Injection (DI) and Inversion of control (IOC), I just came to know about the existence of those concepts. Thanks to Silverlight, PRISM (CAL) and MEF which made me explore the concepts DI and IOC.
Anybody who wants to write an article or explore in depth about Dependency Injection will never fail to read Martin Fowler's article Inversion of Control Containers and the Dependency Injection pattern, for which I'm no exception.
Inversion Of Control
To understand from the name, its inverting the control of creation. Let's take the case of using the framework in an application, the framework takes the responsibility of creating objects/elements and the application will be hooked up with the created object as and when needed. Fowler states this with the example of UI framework and the application/program where the UI framework holds the responsibility of creating the graphical elements and the application instead creates the event handlers for those fields/graphical elements.
Dependency Injection
Think of a scenario class A uses class B which means class A depends on class B. In order to make use of class B in class A, usually what we do is we'll write code to instantiate class B in class A. While instantiating class B, we need to pass the values that class B expects, to be clear, we need to satisfy the dependencies of class B. Say if class B expects and depends on class C, then in class A we need to instantiate class C first and then pass it to class B. Also we need to make sure that we should satisfy the dependencies of class C if any.
Ok, now think of changing the instantiating structure of the dependency object. For that we need to change the code in all the areas where it got used. In our example if class c changes its expectation(expects different parameter), we need to change the source code in class A.
There are situations that we don't know the concrete implementation at the time of writing the code or during compile time for various reasons - like we may need the code developed to be reused and the concrete implementation will be known sometime later.
In the above mentioned cases/paragraphs, just the scenarios are mentioned and the intentions are incomplete. Are there any solution for this? If so what is it? How to handle this? Dependency Injection is one solution to handle that.
Dependency Injection Types
As you guess for constructor injection, we need to specify the dependencies as the parameter for the constructor of the class which requires it. Since we're trying to get rid of the concrete implementation, we need to specify the type (interface) of the dependency which it confirms to.
For setter injection, dependencies are exposed as properties which will be set during the instantiation process.
Ok, who'll hold the responsibility of creating, managing and injecting these dependencies? Builder object or containers will do that for you.
Containers
Containers - Are these containers new to .Net based applications? As quoted in msdn CLR itself is a container. If you think it is more generic, let's take the case of asp.net web applications, where there are times that we've used a common base class for handling security, authentication, common functionalities, etc. These base classes can also be considered as a form of container.
Since the containers will create, manage and inject objects, it avoids tight coupling of objects with its dependencies. Containers acts as a repository or lookup manager that maintains instances. We need to map or configure the containers which instances need to be used on which context. Containers also takes additional responsibilities like managing the lifetime of the objects, so that it supplies singleton or new instances upon requests.
Microsoft patterns and practices provides a lightweight extensible container called Unity Application Block. Prism which is used to create modular WPF or Silverlight applications usually uses this Unity Application Block as container.
SUMMARY
Basically Dependency Injection containers decouples the classes from its dependencies and also the responsibility of managing the dependencies. The issues that we face with DI is it's hard to track while debugging. Also we need to make sure that the container has the ability to resolve the dependency where its required. Previously I've specified in this article that dependency injection is one solution. Other solution generally proposed for this scenario is Service Locator.
REFERENCE
http://martinfowler.com/articles/injection.html
http://msdn.microsoft.com/en-us/library/ff649378.aspx
http://msdn.microsoft.com/en-us/library/aa973811.aspx
http://msdn.microsoft.com/en-us/magazine/cc163739.aspx
http://tutorials.jenkov.com/dependency-injection/when-to-use-dependency-injection.html
After several years of familiarization of the concepts of Dependency Injection (DI) and Inversion of control (IOC), I just came to know about the existence of those concepts. Thanks to Silverlight, PRISM (CAL) and MEF which made me explore the concepts DI and IOC.
Anybody who wants to write an article or explore in depth about Dependency Injection will never fail to read Martin Fowler's article Inversion of Control Containers and the Dependency Injection pattern, for which I'm no exception.
Inversion Of Control
To understand from the name, its inverting the control of creation. Let's take the case of using the framework in an application, the framework takes the responsibility of creating objects/elements and the application will be hooked up with the created object as and when needed. Fowler states this with the example of UI framework and the application/program where the UI framework holds the responsibility of creating the graphical elements and the application instead creates the event handlers for those fields/graphical elements.
Dependency Injection
Think of a scenario class A uses class B which means class A depends on class B. In order to make use of class B in class A, usually what we do is we'll write code to instantiate class B in class A. While instantiating class B, we need to pass the values that class B expects, to be clear, we need to satisfy the dependencies of class B. Say if class B expects and depends on class C, then in class A we need to instantiate class C first and then pass it to class B. Also we need to make sure that we should satisfy the dependencies of class C if any.
Ok, now think of changing the instantiating structure of the dependency object. For that we need to change the code in all the areas where it got used. In our example if class c changes its expectation(expects different parameter), we need to change the source code in class A.
There are situations that we don't know the concrete implementation at the time of writing the code or during compile time for various reasons - like we may need the code developed to be reused and the concrete implementation will be known sometime later.
In the above mentioned cases/paragraphs, just the scenarios are mentioned and the intentions are incomplete. Are there any solution for this? If so what is it? How to handle this? Dependency Injection is one solution to handle that.
Dependency Injection Types
- Constructor injection
- Setter injection
- Interface injection
As you guess for constructor injection, we need to specify the dependencies as the parameter for the constructor of the class which requires it. Since we're trying to get rid of the concrete implementation, we need to specify the type (interface) of the dependency which it confirms to.
For setter injection, dependencies are exposed as properties which will be set during the instantiation process.
Ok, who'll hold the responsibility of creating, managing and injecting these dependencies? Builder object or containers will do that for you.
Containers
Containers - Are these containers new to .Net based applications? As quoted in msdn CLR itself is a container. If you think it is more generic, let's take the case of asp.net web applications, where there are times that we've used a common base class for handling security, authentication, common functionalities, etc. These base classes can also be considered as a form of container.
Since the containers will create, manage and inject objects, it avoids tight coupling of objects with its dependencies. Containers acts as a repository or lookup manager that maintains instances. We need to map or configure the containers which instances need to be used on which context. Containers also takes additional responsibilities like managing the lifetime of the objects, so that it supplies singleton or new instances upon requests.
Microsoft patterns and practices provides a lightweight extensible container called Unity Application Block. Prism which is used to create modular WPF or Silverlight applications usually uses this Unity Application Block as container.
SUMMARY
Basically Dependency Injection containers decouples the classes from its dependencies and also the responsibility of managing the dependencies. The issues that we face with DI is it's hard to track while debugging. Also we need to make sure that the container has the ability to resolve the dependency where its required. Previously I've specified in this article that dependency injection is one solution. Other solution generally proposed for this scenario is Service Locator.
REFERENCE
http://martinfowler.com/articles/injection.html
http://msdn.microsoft.com/en-us/library/ff649378.aspx
http://msdn.microsoft.com/en-us/library/aa973811.aspx
http://msdn.microsoft.com/en-us/magazine/cc163739.aspx
http://tutorials.jenkov.com/dependency-injection/when-to-use-dependency-injection.html
Subscribe to:
Posts (Atom)
