Jan 7 2010

Five things to think about when working with messaging solutions

Category: DDD | Patterns | Messagesfossmo @ 16:21

I’m trying to gather some of my thoughts around messages and that resulted in these 5 points:

1) A message can be created with any technology. It can be JSON, XML, Binary or a custom format. If you want to use the message in different technologies (like Java and .NET), it might be smart to go for a format supported by both technologies. Well, if you choose a technology like XML, it’s not given that you can exchange messages. XML is just a way to format your message, it doesn’t say anything about the content.

2) A message consists of two basic parts; a header and a body.
The header describes the data being transmitted and the body holds the data being transmitted.

3) The tree most important message types are (as I see it); document messages, command messages, event messages. You can read more about this messages in the book Enterprise Integration Patterns: Designing, Building, and Deploring Messaging Solutions (I’m linking to the kindle edition. I love my Kindle :-) ).

A bit more about this message types: A command message is a regular message that contains a command. It uses the command pattern to, for example, encapsulate the request and send it to another system. A document message is used to transferee a data structure between applications and a event message is used to notify another system about a change; for example a price change.

4) When working with messages, you need a way to handle them. On the .NET platform there are several open source choices; NServicebus, Rhino Servicebus, Simple Servicebus and MassTransitt (it’s probably more solutions out there). I think all of them uses MSMQ when communicating the messages, but there are other ways too. There are probably some commercial products out there too, but I haven’t tried to look them up at the moment. For the record; you don’t need a enterprise service bus handle messages. A message can be used to communicate internal in an application, for example between bounded contexts.

5) Messages are immutable. You can look at them as value objects. Greg Young puts it like this; Mutable messages are an anti-pattern. You can read more about his at Greg Youngs blog.

Tags: , ,

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Jan 5 2009

Inversion of Control Containers

Category: C# | Patternsfossmo @ 05:35

Inversion of Control Container is easily put a hash table. A hash table that has a bunch of interfaces versus concrete types. There are a lot of these containers on the web. Some of the most used ones is Windsor, Autofac, Structuremap, Ninject and Unity. I will use Unity later in this post. To try to explain the concept of a IOC container, I will create a very simple one. The two main reasons I use IOC containers is to create loosely coupled applications and it helps me unit test my applications in an easy way. The core concept of dependency inversion principle, which a IOC container is based on, is that high level modules should not depend on the low level ones, but they should both depend on abstractions. The abstraction in these cases are interfaces or abstract-based classes. I recommend that you read my previous blog post about dependency injection if you don't know what dependency inversion principle is.

Let's create the IOC container.

  1:     public class MyIocContainer
  2:     {
  3:         private static readonly IDictionary<Type, object> objDictornary = new Dictionary<Type, object>();
  4: 
  5:         public static T Resolve<T>()
  6:         {
  7:             return (T)objDictornary[typeof(T)];
  8:         }
  9: 
 10:         public static void Register<T>(object objToRegister)
 11:         {
 12:             objDictornary.Add(typeof(T), objToRegister);
 13:         }
 14:     }

In 14 lines of code we have a very simple IOC container. If you want to start using a IOC container, but you can't add a third party library to your project, this could be an easy way to get some of the benefits a IOC container can give you. But, you are of course missing out on a lot of the features a "real" IOC container can provide. Some of the valuable features this container don't contain is allowing different styles of configuration (XML or annotations), lifetime management and autowiring. I will look into autowiring in a later post.

In the first post about DI and IOC containers, I ended the post with doing a poor man's dependency injection (line 11 in the code example below). I think the technical term for this is constructor initialization. This is done if you only want to expose only one of the parameters to the user of your library.

  1:           public Butler(IWeapon weapon, ICommunicate communicate)
  2: 
  3:           {
  4: 
  5:               _weapon = weapon;
  6: 
  7:               _communicate = communicate;
  8: 
  9:           }
 10: 
 11:           public Butler(IWeapon weapon): this(weapon, new Communicate())
 12: 
 13:           {}

Poor man's dependency injection works great, but it will give me a tight coupling against the Communication class. How can we get rid of this tight coupling? We can do as the code example below shows. In stead of creating a object in the constructor initializer I input "objects" from MyiocContainer as parameters.

  1:         public Butler():this(MyIocContainer.Resolve<IWeapon>(), MyIocContainer.Resolve<ICommunicate>())
  2:         {}
  3: 
  4:         //public Butler(IWeapon weapon): this(weapon, new Communicate())
  5:         //{}

We need to create a interface for the communicate class, of course. This was done in the post about dependency injection, but I repeate it here for convinience.

  1:     public interface ICommunicate
  2:     {
  3:         void Speak(string phrase);
  4:     }

Now we have a interface for the communicate class. Let's see how we can use MyiocContainer in the program.

  1:        class Program
  2:        {
  3:            static void Main(string[] args)
  4:            {
  5:                MyIocContainer.Register<IWeapon>(new Poison());
  6:                MyIocContainer.Register<ICommunicate>(new Communicate());
  7:    
  8:               Butler butler = new Butler();
  9:               butler.Kill("The young man");
 10:               butler.Speak("Drink this if you dare, Sir!");
 11:               Console.ReadKey();
 12:           }
 13:       }

The output after running the code above, looks like this.

image

Cool. This is nice. I now have a application where the dependencies is mostly based on interfaces. I can insert a new communication class or a weapon class as long as they implement the interfaces ICommunication and IWeapon. But, now we have a coupling against the IOC container we created. I need to create a abstraction. Doing this I can choose another container later. If I want to use Unity, Structuremap or another IOC container, it won't be a problem.  Lets create the abstraction using the static gateway pattern.

  1:     public static class MyContainerAbstractor
  2:     {
  3:         private static IResolver _resolver;
  4:         public static T Resolve<T>()
  5:         {
  6:             return _resolver.Resolve<T>();
  7:         }
  8: 
  9:         public static void Init(IResolver resolver)
 10:         {
 11:             _resolver = resolver;
 12:         }
 13:     }
 14: 
 15:     public interface IResolver
 16:     {
 17:         T Resolve<T>();
 18:     }

In the Butler class's constructor I do these changes.

  1: public Butler():this(ContainerAbstractor.Resolve<IWeapon>(), ContainerAbstractor.Resolve<ICommunicate>())

Then I need to change MyiocContainer to implement the interface I created and remove the static keywords.

  1:     public class MyIocContainer:IResolver
  2:     {
  3:         private readonly IDictionary<Type, object> objDictonary = new Dictionary<Type, object>();
  4: 

  5:         public T Resolve<T>()
  6:         {
  7:             return (T)objDictonary[typeof(T)];
  8:         }
  9: 
 10:         public void Register<T>(T obj)
 11:         {
 12:             objDictonary.Add(typeof(T), obj);
 13:         }
 14:     }

The main method will look like this after we have done the changes.

  1:     class Program
  2:     {
  3:         static void Main(string[] args)
  4:         {
  5:             MyIocContainer container = new MyIocContainer();
  6:             container.Register<IWeapon>(new Poison());
  7: 
  8:             container.Register<ICommunicate>(new Communicate());
  9:             container.Register<IButler>(new Butler());
 10:             
 11:             ContainerAbstractor.Init(container);
 12: 
 13:             IButler butler = new Butler();
 14:             butler.Speak("Drink this if you dare, Sir!");
 15:             butler.Kill("The young man");
 16:             Console.ReadKey();
 17:         }
 18:     }

Now we are using a abstraction against the IOC container. It's easy to use an other container if we want to do that. Let's create a abstraction against Unity.

  1:     public class MyUnityContainer:IResolver
  2:     {
  3:         readonly IUnityContainer myContainer = new UnityContainer();
  4: 
  5:         public T Resolve<T>()
  6:         {
  7:             return myContainer.Resolve<T>();
  8:         }
  9: 
 10:         public void Register<T>(object obj)
 11:         {
 12:             myContainer.RegisterInstance<T>((T)obj);
 13:         }
 14:     }

To run the program with the Unity container we can just replace one line of code in the main method. Replace

  1: MyIocContainer container = new MyIocContainer();

with

  1: MyUnityContainer container = new MyUnityContainer();

and we will get the same output as before

image

That's it for now. I recommend you to look into IOC containers if you already haven't done so.
In the next post I will show how to create a very simple autowiring mechanism in my home made IOC container.

Tags: , , ,

Currently rated 5.0 by 1 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Dec 23 2008

Murder mysteries and Dependency Injection

Category: C# | Patternsfossmo @ 07:50

 

imageTo try to explain Dependency Injection and Inversion of Control Containers, I'm going to get inspiration from some old detective novels. When I say old, I think of novels like the ones Agatha Christie wrote. This first post will explain Dependency Injection, and the second one will explain Inversion of Control Containers. To start our story we need some characters.

Please welcome:
The Colonel - This is the old guy with the white mustache and monocle.
The young man - He is in love with the woman, and is always trying to show his interest for her.
The woman - She is a countess and have a very rich father (probably the reason the young man got into her in the first place).
The butler - He is always the killer, likewise in this story. 
The detective - Always traveling around running into mysteries to solve.

We should probably have at least ten characters more, but this will do for our examples. They are all invited to a big mansion to spend the weekend there. 

To get our story going, we need a weapon. Let's create one.

  1:     public class Gun
  2:     {
  3:         public void UseWeaponOn(string target)
  4:         {
  5:             Console.WriteLine(string.Format("{0} is shot dead!", target));
  6:         }
  7:     }

In most of the "Agatha Christie-like" detective novels, the butler is the villain. In this story he is the villain to. Let's create a butler so he can start committing crimes (read: killing ;-) ).

  1:     public class Butler
  2:     {
  3:         private Gun _gun;
  4: 
  5:         public Butler()
  6:         {
  7:             _gun = new Gun();
  8:         }
  9: 
 10:         public void Kill(string target)
 11:         {
 12:             _gun.UseWeaponOn(target);
 13:         }
 14:     }

The butlers first target is the colonel:

  1:     class Program
  2:     {
  3:         static void Main(string[] args)
  4:         {
  5:             Butler butler = new Butler();
  6:             butler.Kill("The Colonel");
  7:             Console.ReadKey();
  8:         }
  9:     }

This is what happens after the code is run:

image

The butler has killed his first victim. But, he has a problem. After killing the colonel, he have to find a new weapon for his next kill, because the detective is snooping around the mansion and he has found the murder weapon. This also gives us a problem. Since the gun is created inside the butler class's constructor, we have to modify the implementation of the class in order to make this change.

Coupling or dependency is the degree to which each program module (class) relies on each one of the other modules (classes). The butler class is tightly coupled to the gun class. When modules are tightly coupled, they cannot be replaced without altering their implementation. In order to avoid tightly coupled classes, we can use interfaces to provide a level of abstraction. Let's create an interface to represent a weapon.

  1:     public interface IWeapon
  2:     {
  3:         void UseWeaponOn(string target);   
  4:     }

Then we can implement the interface in the gun class.

  1:     public class Gun:IWeapon
  2:     {
  3:         public void UseWeaponOn(string target)
  4:         {
  5:             Console.WriteLine(string.Format("{0} is shot dead!", target));
  6:         }
  7:     }

And now we can change the butler class.

  1:     public class Butler
  2:     {
  3:         private IWeapon _weapon;
  4: 
  5:         public Butler()
  6:         {
  7:             _weapon = new Gun();
  8:         }
  9: 
 10:         public void Kill(string target)
 11:         {
 12:             _weapon.UseWeaponOn(target);
 13:         }
 14:     }

There is still a small problem with the coupling. The gun class is still created inside the butler class. How can we change this? Well, here is the solution:

  1:     public class Butler
  2:     {
  3:         private IWeapon _weapon;
  4: 
  5:         public Butler(IWeapon weapon)
  6:         {
  7:             _weapon = weapon;
  8:         }
  9: 
 10:         public void Kill(string target)
 11:         {
 12:             _weapon.UseWeaponOn(target);
 13:         }
 14:     }

We inject the weapon through the butler's constructor and create the gun object outside the butler class.

  1:     class Program
  2:     {
  3:         static void Main(string[] args)
  4:         {
  5:             IWeapon weapon = new Gun();
  6:             Butler butler = new Butler(weapon);
  7:             butler.Kill("The Colonel");
  8:             Console.ReadKey();
  9:         }
 10:     }

Now we have a butler class that is loose coupled to the gun class. It is now easy for us to create a new weapon when the butler starts killing people again. In every old detective novel there need to be a murder committed using poison. Arsenic, of course. We then need to create a new weapon class:

  1:     public class Poison:IWeapon
  2:     {
  3:         public void UseWeaponOn(string target)
  4:         {
  5:             Console.WriteLine(string.Format("{0} is killed by poisoning.", target));
  6:         }
  7:     }

To convince his victim to drink the poison, the butler needs to persuade the poor person to drink it. We need to create a communication class.

  1:     public class Communicate
  2:     {
  3:         public void Speak(string phrase)
  4:         {
  5:             Console.WriteLine(phrase);
  6:         }
  7:     }

To make this loose coupled, we create a interface for the communication class too.

  1:     public interface ICommunicate
  2:     {
  3:         void Speak(string phrase);
  4:     }

This means that we need to change the butler class to also inject the communication class.

  1:     public class Butler
  2:     {
  3:         private IWeapon _weapon;
  4:         private ICommunicate _communicate;
  5: 
  6:         public Butler(IWeapon weapon, ICommunicate communicate)
  7:         {
  8:             _weapon = weapon;
  9:             _communicate = communicate;
 10:         }
 11: 
 12:         public void Kill(string target)
 13:         {
 14:             _weapon.UseWeaponOn(target);
 15:         }
 16: 
 17:         public void Speak(string phrase)
 18:         {
 19:             _communicate.Speak(phrase);
 20:         }
 21:     }

The butler has found a new victim; the young man.

  1:     class Program
  2:     {
  3:         static void Main(string[] args)
  4:         {
  5:             IWeapon weapon = new Poison();
  6:             ICommunicate communicate = new Communicate();
  7:             Butler butler = new Butler(weapon, communicate);
  8:             butler.Speak("Please drink this, Sir!");
  9:             butler.Kill("The young man");
 10:             Console.ReadKey();
 11:         }
 12:     }

The output we get is this:

image 

After a few days the detective gathers all the people living, and working, in the mansion in the big living room. He then starts to explain who the killer is. The colonel was killed by a mistake. The real target was the young man.  It turns out that the butler is secretly in love with the woman, and wanted to get rid of all men interested in her. He killed the young man because he saw the woman get a bit intimate with him.

If the butler hadn't been stopped, he would continue to kill people that were interested in the woman. He would probably use a different weapon next time. A weapon that maybe didn't require him to speak. Instead of us creating a communication object and input a null value, we can do a Poor man's dependency injection. That means overloading the constructor this way:

  1:         public Butler(IWeapon weapon): this(weapon, new Communicate())
  2:         {}

Doing this, the communication object will be created automatically.

A nice quote that fit into this context is:

"It's OK to figure out murder mysteries, but you shouldn't need to figure out code. You should be able to read it."
- Steve McConnell (Code Complete)

In the next part I will try to explain what IoC containers are.

Tags:

Currently rated 5.0 by 3 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Apr 3 2008

Very good article of how to create loosely coupled applications

Category: C# | Patterns | Thoughtsfossmo @ 14:10

I just read a very good article about how to create a loosely coupled application.
It's written by James Kovacs for MSDN magazine.
It's named "Tame Your Software Dependencies for More Flexible Apps".

tame

Link to the article is found here: http://msdn2.microsoft.com/en-us/magazine/cc337885.aspx

Tags:

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Mar 27 2008

To night I understood what you gain using the Model-View-ViewModel pattern

Category: C# | Patternsfossmo @ 15:19

To follow me in this post I believe you need to have some pre knowledge about this Model/View/ ViewModel-pattern.

In my company we have a thing called "fagkveld". Its basically 1,5 hours where we present different design patterns and best practices to each other. To night Kjetil talked about something that I think is really exiting; the pattern Model View ViewModel. It's a pattern, among other things, for separating the (business) logic from the GUI (in Windows Presentation Foundation).

I have implemented the Model View Controller pattern in WPF earlier, and didn't then see the advantage of using a ViewModel. To night I understood what you gain using a ViewModel.

When using ViewModel on top of a (domain) model you get the benefit of customizing the ViewModel to exactly fit your views needs. If you need to change the data before you present it in the view, you can do this in the ViewModel. Let's say you have a model representing a person and you want to merge the persons first name and last name into one textbox in the view. You can do this in the ViewModel to avoid adding logic to the code behind file in the view. To completely remove code from the view, you also can use the Routed command pattern included in WPF. If you have a (domain) model that isn't suitable to databind to your view, ViewModel is your savior.

A problem I see using a ViewModel, is that the (domain) model isn't updated before you specific tell it to update it self. If other parts of the application relies on the model being updated "on the fly", you may have a problem. But, i guess this problem is possible to overcome.

Model View ViewModel is perfect to adapt an "old" domain model to support the mind blowing features in Windows Presentation Foundation.

Good reading for learning about the pattern:

http://blogs.msdn.com/johngossman/archive/2005/10/08/478683.aspx

Tags:

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Jan 20 2008

What is the factory method pattern?

Category: C# | Patternsfossmo @ 10:29

The factory method pattern is a creational pattern. You can use it when you don't know witch object you must use at runtime.

Advantage of this pattern; you can delay assigning action code till more information is available. It's also easy to add other classes (in the code example below; color classes).
 

factory method pattern

What happens in the figure above?

The first thing that happens, is that a parameter is passed into the GetInstance method in the Factory class. Depending on the parameter passed in, a object is returned. In this instance, a object from class Blue is returned. The factory method pattern is as simple as that. If I wanted to work with the Green object, I would have passed Green as a parameter.

This patterns can be used in all parts of your code. You can use it to choose, for instance, databases or different graphical user interface frameworks at runtime.

Let's look at some code:

 

   1:  using System;
   2:   
   3:  namespace FactoryPattern
   4:  {
   5:      // Color objects to choose
   6:      enum MyColors
   7:      {
   8:          Green, Blue
   9:      }
  10:   
  11:      // The contract the objects have to implemet
  12:      interface IColor
  13:      {
  14:          void ShowFavoriteColor();
  15:      }
  16:   
  17:      class Factory
  18:      {
  19:          // A instance of a object is returned based on the input parameter.
  20:          public IColor GetInstance(MyColors type)
  21:          {
  22:              IColor color = null;
  23:   
  24:              // Whice object to return is decided.
  25:              switch (type)
  26:              {
  27:                  case MyColors.Green:
  28:                      color = new Green();
  29:                      break;
  30:                  case MyColors.Blue:
  31:                      color = new Blue();
  32:                      break;
  33:              }
  34:              return color;
  35:          }
  36:      }
  37:   
  38:      class Green : IColor
  39:      {
  40:          public void ShowFavoriteColor()
  41:          {
  42:              Console.WriteLine("My favorite color is green");
  43:          }
  44:      }
  45:   
  46:      class Blue : IColor
  47:      {
  48:          public void ShowFavoriteColor()
  49:          {
  50:              Console.WriteLine("My favorite color is blue");
  51:          }
  52:      }
  53:   
  54:      class ColorChooser
  55:      {
  56:          public static void Main()
  57:          {
  58:              Factory factory = new Factory();
  59:   
  60:              // Decides which instance to start
  61:              IColor baseClass = factory.GetInstance(MyColors.Blue);
  62:   
  63:              // Executes method in chosen instance
  64:              baseClass.ShowFavoriteColor();
  65:   
  66:              Console.ReadKey();
  67:          }
  68:      }
  69:  }

Tags:

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Jan 8 2008

Dependency Injection explained

Category: C# | Patternsfossmo @ 11:35

Dependency Injection (DI) is a fancy word for a very simple pattern. You probably use DI at some sort every time you code. In it simplest form, a variable is injected into a method and the method can interact with the variable. That's DI.

I often use DI in a other pattern called Model View Presenter. 

In the figure below, I visually try to show how DI works.

DependencyInjection

(Click on the image to view larger)

Below is a example of how I often use the pattern.

   1:  namespace DependencyInjection
   2:  {
   3:      class Program
   4:      {
   5:          static void Main(string[] args)
   6:          {
   7:              Class1 class1 = new Class1();         
   8:          }
   9:      }
  10:   
  11:      public interface IProperties
  12:      {
  13:          string MyValue { get; set; }
  14:      }
  15:   
  16:      public class Class1:IProperties
  17:      {
  18:          string _myValue = "Class1 value";
  19:          Class2 class2;
  20:   
  21:          public Class1() 
  22:          {
  23:              Console.WriteLine(MyValue);
  24:              class2 = new Class2(this);
  25:              class2.ChangeMyValue();
  26:              Console.WriteLine(MyValue);
  27:              Console.ReadKey();
  28:          }
  29:   
  30:          public string MyValue
  31:          {
  32:              get
  33:              {
  34:                  return _myValue;
  35:              }
  36:              set
  37:              {
  38:                  _myValue = value;
  39:              }
  40:          }     
  41:      }
  42:   
  43:      public class Class2
  44:      {
  45:          private IProperties _view;
  46:   
  47:          public Class2(IProperties view)
  48:          {
  49:              _view = view;
  50:          }
  51:   
  52:          public void ChangeMyValue()
  53:          {
  54:              _view.MyValue = "Changed by instance of Class 2";
  55:          }
  56:      }
  57:  }
 
 
 
In line 7, a instance of Class 1 is created. The constructor in Class 1 is executed (line 21). 
Class 2 is called with the instance of the current object (Class 1). 
This is possible because Class 1 implements the interface IProperties (line 11). In line 25, class 2
calls the method ChangeMyValue. The property MyValue in Class 1 is changed.
 
That's the dependency injection pattern.
 

Tags:

Currently rated 5.0 by 1 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Dec 26 2007

Model View Presenter explained

Category: C# | Patterns | Scrum | Testingfossmo @ 18:36

I have used Model View Presenter (MVP) a lot the last months. It's a great pattern, but a lot of the people I talk to have problem understanding how it works, and how to use it. I will try to explain it simple in this blog post.

Passive View and Supervising controller
The creator of MVP, Martin Fowler, spilt the pattern into to new patterns. This was due to apparent confusions between Model View Controller and MVP. The new patterns is called Passive View and Supervising Controller. The main difference between this to patterns, is that Passive View puts all the view update behavior in the controller/presenter and Supervising Controller encourage the view to do most of the updating itself, and only brings in the presenter/controller when there's more complex logic involved. In my example application later in this blog post, I show Passive View.

When to use it
MVP is a great pattern to ease up unit testing the graphical user interface (GUI), and to decouple the GUI from the underlying model. MVP makes switching GUI a breeze.

Explained graphically
MVP is a pursuance of an other pattern called Model View Controller. In MVP, the view and the model don't know of each other, but in MVC the view knows of the model, and gets its updates from it.
I will cover MVC in a later post.

The figure below visually illustrates the pattern.

mvpgrap

More thoroughgoing, this is what happens:

1) The user executes a action. The action is forwarded to the presenter.
2) The presenter asks the database (model) for the data to view.
3) The model sends the data back to the presenter.
4) The presenter updates the view with the new data.

There are normally four main classes used in the MVP pattern. To be more specific,  three classes and a interface; the view, typical a WinForm, WebForm or XAML-file. The interface, witch describes the fields in the view. The presenter, witch executes the views actions and communicates with the model. And, of course,  the underlying model, e.g. a database.

Example application
I have created an application witch displays name, e-mail, state, etc. The application uses the MVP pattern. This is what the application does: You enter a name into the search text box and the program reads information from a textfile. Information about the user is displayed in the form. 

Application 
Shows the GUI in the application

Project
The solution consists of three projects. One view, one presenter and one model. If you wanted to have several forms, you would have to create more presenters and views. 

projectstructur
Shows the project structure

Interface
Let's look at the interface. It's found in the presenter project, and is named IPerson. It includes all the fields I want to display in the view.

interface

The last field in the interface is Message. You will find it in the lower part of Form1, displaying: "Data fetched.". If any error occurs in the application, it's shown there. The class Form1 (Form1.cs), implements the interface.

implemented interface   

Form1 implements all the properties in the interface. This is, as you know the startingpoint of the application. A instance of the presenter is created in the view. This way the presenter and view can communicate, and the presenter can update the GUI elements.

implementations
Shows some of the properties in Form1

When the search textbox is filled with a name, a event is triggered. It ends up in the method txtSearch_KeyUp in the class Form1:

keypressed

The presenters constructor, inputs the view and the class fetching data from the model, as parameters. Hence, the presenter has access to the view and the model. This way of doing things is called Dependency Injection.

presenter

In the method UpdateData (called from the view), data is fetched from the datasource, and the view is filled with the returning data. If a exception occurs the field message, in the view, displays the error message. If nothing happens, the field displays "Data fetched.".

ReadData

In the model (Data project), data is fetched from the file and put into a person object. Person object is returned to the presenter. If no data is found, an exception is thrown (witch is displayed in the message field in the GUI).

nodatafound

That is the course of events in the Model View Presenter pattern.
I recommend you to fire up Visual Studio and debug the sample application.

If you want to download the sourcecode for this example, you can find a link below.  

Tags: ,

Currently rated 5.0 by 5 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Dec 26 2007

Learn some design patterns

Category: Scrum | Patternsfossmo @ 05:31

Why, you ask?
It makes you and your team a lot more productive. A lot of the time you is programming, you is doing things that have been done by other programmers. Why not take advantage of what great programmers have done before you? I think it's a vast of your stakeholders money and time not to learn and use design patterns. Communication between team members will be much more easy. You don't have to draw complex drawings on whiteboards and spend hours explaining what you meant. If your team knows design patterns, you can just say Dependency Injection, and all the team members knows what needs to be done. It will take you about 2 seconds versus hours of explaining. A great book for learning the most basic patterns is "Head first design patterns".

headfirstdesignpatterns

Tags:

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5