Using Mocking Framework - Moq

kick it on DotNetKicks.com
StumbleUpon.com
Save to delicious Saved by 0 users



This post will tell how to incorporate one of the popular & free object mocking framework, Moq in your unit tests.


I am sure you have heard about this if you have done unit tests before or you have experience in software development project that employs the TDD (Test Driven Development) approach.

What actually is a mock object? An object that mimics the behavior of real object in a controlled way. Mock objects are often used in unit test to simulate the behaviors of the dependencies for the object being tested. Mock objects are used because in real life the real objects are very impractical or impossible to create in the unit test environment. It is impractical and impossible because configuring and setting up all these real dependencies subjected to budgets, time or unavailability of the real dependencies at the time the unit testing is performed. For e.g. to unit test an object that uses a database, you  can easily setup up a SQL Server database connection with the Visual Studio and it is fairly simple and manageable task. What if the objects you need to test also depend on other data source that resides on the mainframe server in a secure environment or other third-party library that is still under development?

Let assume all the constraints to set up and configure the real dependencies for the objects to be tested don’t exist, then the unit tests themselves will look like the integration tests. This will defeat the purpose of unit testing as the unit test is to isolate each part of the program and to ensure each of this individual parts meet its design and behaves as intended. It meant to be simplest, fast and exercise very specific functionality.

The setting up and configuration of the real dependencies for the objects being tested should be deferred until the integration testing where the idea is to test the combination of units and to identify problems that occur when units are combined. It will eventually expand to testing the modules with those of other groups and finally all the modules that make up the process are tested together. It is significant slower than the unit testing.

The mock objects replace the real dependency objects and the objects that depend on them can be tested easily and effectively without being aware of the fact they are being served by the mock objects. This is possible because the mock objects conform to the interface of the real objects and they just have enough code to fool the tested objects.  With mock objects, developers can focus on testing the behaviors of the system under test without worrying on the complex dependencies which are awkward to create in the unit test environment. Click here to know more about the history of mock objects.

There are other thoughts from Gerard Meszaros and Martin Fowler that a more generic term, Test Double, should be used instead of the mock for any case where replace real objects for testing purposes. Under the test double term, there are few names to describe the specific implementations. The table below is taken from http://msdn.microsoft.com/en-us/magazine/cc163358.aspx

Test Double TypeDescription
DummyThe simplest, most primitive type of test double. Dummies contain no implementation and are mostly used when required as parameter values, but not otherwise utilized. Nulls can be considered dummies, but real dummies are derivations of interfaces or base classes without any implementation at all.
StubA step up from dummies, stubs is minimal implementations of interfaces or base classes. Methods returning void will typically contain no implementation at all, while methods returning values will typically return hard-coded values.
SpyA test spy is similar to a stub, but besides giving clients an instance on which to invoke members, a spy will also record which members were invoked so that unit tests can verify that members were invoked as expected.
FakeA fake contains more complex implementations, typically handling interactions between different members of the type it's inheriting. While not a complete production implementation, a fake may resemble a production implementation, albeit with some shortcuts.
MockA mock is dynamically created by a mock library (the others are typically produced by a test developer using code). The test developer never sees the actual code implementing the interface or base class, but can configure the mock to provide return values, expect particular members to be invoked, and so on. Depending on its configuration, a mock can behave like a dummy, a stub, or a spy.

While the unit testing has gained popularity in recent years, so do the number of mocking frameworks available for .NET. The mocking framework helps to simplifying the way the mock implementations of dependencies of the object under test are created. Some are open source like NUnit.Mocks, NMock, NMock2, EasyMock, Rhino.Mocks, Moq and some are commercial such as TypeMock . Here are two links that compare few of them http://www.phpvs.net/2009/04/25/net-mocking-frameworks-capability-comparison/ and http://codevanced.net/post/Mocking-frameworks-comparison.aspx .

Frankly speaking, I first experienced with unit testings only two and a half years ago. At that time, I was attached with one the US software company that provides customer relationship management solutions. The company practices agile software development. So, unit testing is one of the practices. The first unit testing framework I used is NUnit. However, in real work practices, the real dependencies are often handcrafted from scratch without relying on the use of mocking frameworks. Well, I am not really a full fledged TDD developer but I will try to commit myself to it as often as possible and this would also depend on whether the organization has the culture of practicing TDD.  Sometimes, the tight delivery time may have caused the unit testings being singled out for the sake of meeting the deadlines.

The mocking framework is new to me. In this post, I have chosen to use the open source Moq (pronounced “Mock-you” or just “Mock”) instead of the more popular open source Rhino.Mocks because of its simplicity in term of its API. Unlike other mocking frameworks, Moq doesn't use the record/replay model explicitly. So, its APIs are more intuitive to use and easy to learn. To learn what the record/replay mean in the TDD, please click What's wrong with the Record/Reply/Verify model for mocking frameworks, to follow the explanation by the Moq creator. Also, there is no real distinctions among the Test Double types in Moq. All of them are referred to as Mock. For a new comer like me, it poses less confusion as I can simply create whatever Test Double object through a single API, Mock.  Accessing any of its mocking utilities is just simply a dot away from the Mock instance.

The use of Moq is my personal preferences. I don't deny the pros of other mocking frameworks as each of them has its merits and users around the world. It is only that I find Moq is easy to start with and it is easy to pick up fast. Anyway, there is no harm to learn Dummy vs Stub vs Spy vs Fake vs Mock as you move along and get comfortable with the mocking. There is a link,  Mocks Aren't Stubs by Martin Fowler that explain this in further details.

Again, based on the Moq creator, it is intended to be straightforward and easy to use mocking framework that doesn’t require any prior knowledge of the mocking concepts. So, it doesn't requires deep learning curve from the developers.  It takes full advantage of the .NET 3.5 expression trees and the lambda expressions. Any of the methods and properties of the mock object can be easily represented in the lambda expressions.
Moq can be downloaded from the below link and it is maintained as the Google Code project.
http://code.google.com/p/moq/

In the rest of the post that follows, I will write the unit tests for the repository with mocking features available from the Moq. The repository APIs are what I have introduced in my writing on Repository, Specification, Unit of Work and Persistence Ignorance with Microsoft Entity Framework 4.0 Beta 2. You can read the post here. Your comments and feedback are always welcomed. If you go through the unit test source codes for the repository in the post, you will notice that the unit tests don't make use of the mock objects. Instead, it makes use of all the real dependencies for the testing. I have written all the codes and all those real dependencies such as the MS-SQL server connection, database instance,  entity framework features can be easily managed and  set up within the Visual Studio environment. So,  I have put the use of mocking objects aside. However, in the team environment where each of the team member has its own roles and responsibilities in different area/layer of the software development and because of the separation of concerns, it is very hard or impossible to have all the real dependencies ready to be used at the time when you want to carry out the unit testing on the codes you have written. In this situation, mocking objects will come into the picture and you will find that they are very helpful and make your life easy. Furthermore, unit testing with the real dependencies will sometimes make your tests fail unexpectedly because of the changes of configuration settings or errors in the real dependencies which are beyond your control.

Make sure you have downloaded the latest stable version of Moq which is Moq.3.1.416.3-bin.zip as of this writing.

Some basics of the Moq
i) It can mock both interfaces and classes, and use lambda expressions to make those mocks type safe and refactoring friendly.
ii) However, it cannot mock non-virtual, non-abstract and static methods, and can't mock sealed classes and private interfaces.

Without further ado, let look at the example:
I will unit test the Customer repository class again in the business layer project. But, this time I am going to take out the real dependencies in the CustomerRepository class and replace with mock objects. Figure 1.o shows the CustomerRepository that I am going to unit test against the Moq framework.  In my previous post on using Repository, Specification, Unit of Work and Persistence Ignorance POCO with Microsoft  Entity Framework 4.0 Beta 2, I have unit tested the business layer, CustomerRepository with all the real dependencies.


 Figure 1.0 CustomerRepository in the business layer project, MyCompany.Business.MoqDemo

At the first glance of my CustomerRepository type, it has direct dependencies on MyCompany.Data.RepositoryFactory and MyCompany.Data.Repository/IRepository interface. So, these two types are candidates for the mock objects. However, when I carefully look at the RepositoryFactory, which is a singleton class and can't be mocked directly with Moq framework without using some workaround like applying the Adapter pattern to the RepositoryFactory. Well, if you see it from the design by testability perspective; static methods, singleton and concrete types are not encouraged and they  limit the testability of  a type if they are not properly used.  Follow this link to read opinions of other people why singleton is bad. There are two articles from msdn magazine; Tame Your Software Dependencies for More Flexible Apps and Design for Testability, which I found very useful in telling how to write flexible application with loosely coupled and testable types.

Now, I admit that implementing the RepositoryFactory as singleton would be a wrong design decision if I want it to be easily mocked with Moq. Assuming that this is a fact and I can't change the RepositoryFactory code implementation but to live with it. My workaround solution to make RepositoryFactory mockable is to write a RepositoryFactory wrapper for it.

1:  public class RepositoryFactoryWrapper : IRepositoryFactory where TObject : class  
2:    {  
3:        private RepositoryFactory _repositoryFactory;  
4:        public RepositoryFactoryWrapper(RepositoryFactory repositoryFactory)  
5:        {  
6:          _repositoryFactory = repositoryFactory;  
7:        }  
8:       #region IRepositoryFactory<TObject> Members  
9:        public TObject CreateObject()  
10:       {  
11:          return _repositoryFactory.CreateObject();  
12:       }  
13:       public TObject CreateObject(string name)  
14:       {  
15:        return _repositoryFactory.CreateObject<TObject>(name);  
16:       }  
17:       #endregion  
18:    }  

Based on the above code segment, the RepositoryFactoryWrapper merely delegates method calls to the original MyCompany.Data.RepositoryFactory.


1:   public class CustomerRepository  
2:    {  
3:      private readonly IRepositoryFactory<IRepository<Customer>> _customerRepositoryFactory;  
4:      //Explict public default constructor  
5:      public CustomerRepository()  
6:      {  
7:        _customerRepositoryFactory = new RepositoryFactoryWrapper<IRepository<Customer>>(RepositoryFactory.Instance);  
8:      }  
9:      public CustomerRepository(IRepositoryFactory<IRepository<Customer>> repositoryFactory)  
10:     {  
11:        _customerRepositoryFactory = repositoryFactory;  
12:     }  

Based on the above code segment, my CustomerRepository will have two constructors. The first one is the default constructor which the client component will call by default when the CustomerRepository is created. Within the default constructor, an instance of the RepositoryFactory will be returned from its singleton pattern and passed as parameter to the RepositoryFactoryWrapper's constructor.The second constructor of the CustomerRepository is for us to pass our mock object of the IRepositoryFactory interface during the unit testing.

Now we have all the infrastructure in place, we can use Moq to achieve our mocking purposes. The general steps to work with the mocking frameworks are as follow:-

1. Create a mock object from an exiting interface or classes with the mocking framework. In Moq, it can be easily achieved with Mock .
2. Set the expectations for the mock object. This is to tell the mocking framework what will be called, returned, set, get and etc on the mock object.
3. Pass the mock object to the object that depends on it during the unit testing.
4. Verify the expectations were met.

Let look at the CustomerRepositoryTest as an example.


1:    /// <summary>  
2:    /// Unit tests for customer repository.  
3:    /// </summary>  
4:    [TestClass]  
5:    public class CustomerRepositoryTest  
6:    {  
7:       private Mock<IRepositoryFactory<IRepository<Customer>>> _customerRepositoryFactoryMock;  
8:       private Mock<IRepository<Customer>> _customerRepositoryMock;  
9:       private List<Customer> _customerList;  
10:      private CustomerRepository _customerRepository;  
11:      public CustomerRepositoryTest()  
12:      {  
13:        //setup our mock objects here.  
14:        _customerRepositoryFactoryMock = new Mock<IRepositoryFactory<IRepository<Customer>>>(MockBehavior.Strict);  
15:        _customerRepositoryMock = new Mock<IRepository<Customer>>(MockBehavior.Strict);  
16:        //Collection Initializer  
17:        //Simulate the persistent in memory storage for the Customer Repository Tests  
18:        _customerList = new List<Customer>() { new Customer{ CustomerID = "TEST1", ContactName = "TestCompanyName1"},  
19:                            new Customer{ CustomerID = "TEST2", ContactName = "TestCompanyName2"},  
20:                            new Customer{ CustomerID = "TEST3", ContactName = "TestCompanyName3"}};  

In the constructor of CustomerRepositoryTest, we setup our mock objects for IRepositoryFactory> and IRepository using the Mock class. It has a generic type parameter which accepts the type of the interface of  the mock object to create. You will notice that the Mock constructor accept the MockBehavior enum option which can take three values; Strict, Loose and Default. I have chosen to use the Strict option. So during the unit testing if there is any method call made on these two dependencies in the CustomerRepository instance doesn't have the corresponding expectation being setup, then the Moq framework will throw an exception telling me that the invocations don't have a corresponding setup. The Loose option will mean that the Moq framework won't throw any exception but will try to create default value as necessary.

For e.g. In the implementation of the public methods API of the CustomerRepository, there is call to the IRepositoryFactory>.CreateObject() to return an instance of the generic customer repository. If I didn't setup the expectation for the IRepositoryFactory>.CreateObject() method, the Moq will throw an exception when encountering a call to the CreateObject() method in the CustomerRepository class. If the Loose option is used, then the Moq will ensure CreateObject() method returns a null reference instead of throwing and exception. The Default option is actually Loose option.

After the mock objects are setup, we will move to the expectations setup for the mock objects. Prior to this, I have created a list of customer collection for the purpose of CRUD operations performed on the IRepository mock object. It serves as an in memory storage for holding up all the customer entity objects.

1:   //Setup expectation for the Dispose method of the IRepository<Customer> mock  
2:   _customerRepositoryMock.Setup(cr => cr.Dispose());  
3:   //Setup expectation for the Create method of the IRepository<Customer> mock  
4:   _customerRepositoryMock.Setup(cr => cr.Create()).Returns(new Customer());  
5:   //Setup expectation for the Add method of the IRepository<Customer> mock  
6:   _customerRepositoryMock.Setup(cr => cr.Add(It.Is<Customer>(c => !string.IsNullOrEmpty(c.CustomerID)))).Callback((Customer c) =>  
7:   {  
8:    _customerList.Add(c);  
9:   }  
10:   );  
11:  //Setup expectation for the Attach method of the IRepository<Customer> mock.  
12:  _customerRepositoryMock.Setup(cr => cr.Attach(It.Is<Customer>(c => !string.IsNullOrEmpty(c.CustomerID))));  
13:  //Setup expectation for the Update method of the IRepository<Customer> mock.  
14:  _customerRepositoryMock.Setup(cr => cr.Update(It.Is<Customer>(c => !string.IsNullOrEmpty(c.CustomerID) && _customerList.Exists( d => d.CustomerID == c.CustomerID)))).Callback  
15:  ((Customer c) =>  
16:  {  
17:    //update the customer object in the memory customer list storage  
18:    Customer tempCustomer = _customerList.SingleOrDefault(e => e.CustomerID == c.CustomerID);  
19:    tempCustomer.Address = c.Address;  
20:    tempCustomer.City = c.City;  
21:    tempCustomer.CompanyName = c.CompanyName;  
22:    tempCustomer.ContactName = c.ContactName;  
23:    tempCustomer.ContactTitle = c.ContactTitle;  
24:    tempCustomer.Country = c.Country;  
25:    tempCustomer.Fax = c.Fax;  
26:    tempCustomer.Phone = c.Phone;  
27:    tempCustomer.PostalCode = c.PostalCode;  
28:    tempCustomer.Region= c.Region;  
29:   }  
30:  );  
31:  //Setup expectation for the delete method of te IRepository mock.  
32:  _customerRepositoryMock.Setup(cr => cr.Delete(It.Is<Customer>(c => !string.IsNullOrEmpty(c.CustomerID) && _customerList.Exists(d => d.CustomerID == c.CustomerID)))).Callback  
33:  ((Customer c) =>  
34:   {  
35:    //remove the customer object from the memory customer list storage  
36:    int index = _customerList.FindIndex(d => d.CustomerID == c.CustomerID);  
37:    if (index > -1)  
38:    _customerList.RemoveAt(index);  
39:   }  
40:   );  
41:   //Setup expectation for the Save method of the IRepository<Customer> mock.  
42:   _customerRepositoryMock.Setup(cr => cr.Save()).Returns(1);  
43:   //Setup expectation for the customer repository factory to return the IRepository<Customer> object  
44:   //from the IRepository<Customer> mock.  
45:   _customerRepositoryFactoryMock.Setup(c => c.CreateObject()).Returns(_customerRepositoryMock.Object);  
46:   //Pass the IRepositoryFactory<IRepository<Customer>> object the specific customer repository object which the unit test will test against.  
47:   _customerRepository = new CustomerRepository(_customerRepositoryFactoryMock.Object);  

The above code segment shows all the expectations being setup on the two mock objects having the interface IRepositoryFactory and IRepository.
The expectations on the mocked type can be specified with the Setup() method. In version 2.x, it is named as Expect. The Setup() method let us specify the methods we expect the mocked type to be called during the unit testing along with its parameter as well as the return value if there is any. The statement  _customerRepositoryMock.Setup(cr => cr.Dispose()) tell the Moq framework that the Dispose() method on the interface IRepository will be called during the unit testing. So, the Moq framework will be able to provide a mocked implementation of this Dispose() method for the interface IRepository.

Let look at this statement,  _customerRepositoryMock.Setup(cr => cr.Create()).Returns(new Customer()) . The method expectation requires a return value as part of its invocation. When the Create() method is invoked, a new Customer entity object will be returned.
Let look at this statement,

_customerRepositoryMock.Setup(cr => cr.Add(It.Is(c => !string.IsNullOrEmpty(c.CustomerID)))).Callback((Customer c) =>
{
     _customerList.Add(c);
}

);

The static class, It allows us to pass constraint to the method expectation. The It.Is will match any values that satisfy a predicate. The above statement tell the Moq framework that the Add() method only accept a customer entity object whose CustomerID property is not null or empty. If this constraint is not being obeyed during the method invocation, then Moq framework will throw an exception  if  Strict enum is specified for the MockBehavior.

The Callback allow us to specify or includes a chunk of codes to be executed during the method invocation. It similar to the body of the method. When the Add() method is invoked, the customer entity object argument is passed to the callback body which merely add the customer entity object to the in memory customer list,  _customerList.

So far, you will notice that all the method expectations are represented in lambda expressions which make the mock type safe and refactoring friendly. One more thing to notice is that last two statements of the code segment.

1:  //Setup expectation for the customer repository factory to return the IRepository<Customer> object  
2:  //from the IRepository<Customer> mock.  
3:   _customerRepositoryFactoryMock.Setup(c => c.CreateObject()).Returns(_customerRepositoryMock.Object</span>);  
4:  //Pass the IRepositoryFactory<IRepository<Customer>> object the specific customer repository object which the unit test will test against.  
5:  _customerRepository = new CustomerRepository(_customerRepositoryFactoryMock.Object);  


The Object property return the instance of the mocked objects of both interfaces IRepositoryFactory> and IRepository respectively. _customerRepositoryMock is not returned as part of the method expectation, CreateObject() method because it is merely a proxy class that hold the actual mocked instance.
Last but not least, there is a limitation of the Moq mocking framework. Please look at the following code segment. I expect the following would be possible

1:  _customerRepositoryMock.Setup(cr => cr.Find( c => c.CustomerID == "TEST4")).Returns(() => _customerList.Where(c => c.CustomerID == "TEST4").AsQueryable());  

However, I get a NotSupportedException error during the run time as shown in Figure 1.1


 Figure 1.1 NotSupportedException error when passing lambda expression to the method that can accept expression input.

This post just introduces the basic usage of the Moq framework APIs. If you are into it, you can refer to the Moq quick start here which shows a more complete sample of how its APIs can be harnessed.

Code Download Customer Repository Unit Test with Moq object framework. (This application sample requires Visual Studio 2010 Beta 2/RC that can open C# project. Right click on the above link and choose Save Target As. Rename the extension from .pdf to .zip once you have downloaded the file. Let me know if you have any problem running the code.)

See you in my next post.
Bye and stay tune...


ASP.NET MVC Framework 2 Preview 2 with Repository – Part 1

kick it on DotNetKicks.com
StumbleUpon.com
Save to delicious Saved by 0 users



Part 1 of this post will only briefly explain and tell what is MVC, its history and its derivatives. Demo source codes are provided at the end of each pattern. Part 2 of this post is still in writing and it will touch on the ASP.NET MVC 2 Framework.


Preface

 

This is my first post on ASP.NET MVC Framework 2 Preview 2 that ships with the .NET Framework 4.0 Beta 2. It will be a post of creating simple ASP.NET application using the MVC Framework 2 Preview 2 along with the Repository framework that I have posted previously in my blog. If you are interested to know one of the way of implementing Repository, Specification and Unit of Work with Entity Framework 4.0 Beta 2, you can click here to have a look and give me some comment and feedback. The sample project comes with this post may or may not work after the official release of Visual Studio 2010 and .NET Framework 4.0 on March 2010.

I would like to outline the prerequisites that you need to have in order to run the sample project attached with this post.
ASP.NET MVC 2 Preview 2 included in Visual Studio 2010 Beta 2. If you need to know about the ASP.NET roadmap, please click here .

Before I go on with ASP.NET MVC Framework 2 Preview 2, I would like to clear up the confusion of all these buzzwords, MVC, Application Model MVC, MVP, Supervising Controller, and Passive View. If you are already familiar with these, then you can skip this post I. Of course, I will still welcome your feedback and comments. So, I would be able to know the crucial points and facts that I may have missed out.


 

MVC, Application Model MVC, MVP, Supervising Controller, Passive View

 

Without further ado, let look at what they are all about. In brief, they are architectural pattern used to isolate the business/domain logic from the user input and presentation. We gain the advantages of better separation of concerns. Better separation of concerns results in better reusability, better maintenance and easier testing.

In other words, MVC, MVP and Presentation Model are all GUI architectures. MVC comes first. MVC was one of the concepts originally found in Smalltalk. MVC was first described in 1979 by Trygve Mikkjel Heyerdahl Reenskaug who formulated the Model-View-Controller architectural pattern.

The MVP stands for Model-View-Presenter which is a derivative of MVC. It was in response to some shortfalls of the MVC. The Model-View-Presenter software pattern originated in the early 1990s at Taligent, which was the name of an object oriented operating system and the company dedicated to it.

Martin Fowler, later split the MVP into the Supervising Controller and Passive View through his retirement note for Model-View-Presenter at http://martinfowler.com/eaaDev/ModelViewPresenter.html. Supervising Controller and Passive View are similar to the MVP. They are different in the autonomy the view has in the view update logic.

Next is the Martin Fowler’s Presentation Model which pulls the state and behavior of the View into a Model class that is part of the presentation. One of the specialization of the Presentation Model is MVVM (Model View ViewModel) originated from Microsoft. It is targeted at the WPF (Windows Presentation Foundation) and Silverlight. MVVM clearly separate the responsibility of developer whose job is to purely write code and the UI designer whose job is to purely do the user interface design.


 

MVC (Model View Controller)

 

MVC make a clear division between the domain model and the presentation objects (view/controller). It is the business logic and data on which the business logic operates in general term. In a domain driven approach, it includes the domain model (entities and values objects), the Repository which mediates between the domain and the data mapping layer, the domain logic which are functional requirements of the business that add meaning to the domain model. (For e.g. calculating shipping taxes, loan interests and etc), the service facade which exposes the business logic as service so other applications can consume and it also abstract the other applications from the changes in the business logic as the service facade will make these transparent to them,and of course the persistence storage. Most of the applications persist the data in some form of storage such as database. This implies that the data access logic/layer also fall under the Model.

The view is some form of visualization of the state of the model. When we talk about the MVC in 80’s, it is the widget on the screen surface which can be a button, textbox, label and etc. It just concerns itself about only with the user interface in response to the update from the model. It neither cares about the presentation logic nor the processing of the user inputs.

The controller offers facilities to change the state of the model. In other words, it processes user inputs coming from input devices such as keyboard and mouse and transform them into the changes in the model. The controller will sometimes make logical decisions about the user input and update the view accordingly without involving the model. Here, I would like to stress again that we are talking about the widgets of 80’s which doesn’t know about mouse or keyboard inputs. The widget’s main purpose is to display the model’s data and the processing of the user inputs are the main purpose of the controller. So, the view and the controller form an indivisible pair. MVC requires each view has a controller and each controller has a view. Each view’s controller is dedicated to that view’s sole service.

Figure 1.0 shows the communication among the Model, View (widget) and Controller in the traditional MVC pattern in 80's



a. Controller receives input from user through keyboard or mouse.

b. Controller updates the state of the model based on the user input.

c. The Model changes based on the update from the Controller and notify the View about the change.

d. The View queries the Model to determine the stage change and updates the user interface to reflect the latest change.

e. Controller may not update the model after receiving the user input but instruct the View directly

If you look up the Wikipedia at http://en.wikipedia.org/wiki/Model_view_controller, you will notice that there will be reciprocal communication flow between the view and the controller. This is fine as the widgets (view) now are able to capture mouse and keyboard events since the inception of Microsoft Windows and its event driven programming.

The MVC explanation that follows after here is based on the general MVC diagram found in the Wikipedia.

The model, view and controller must communicate regularly. The model must notify the view about its state change. The view must register with the controller in order to receive user interface update event. The controller needs to update the model and the view in response to the user input.

To facilitate this communication, the model itself needs to keep a reference to the view instance which renders its state change in the form of user interface. Both the view and controller need a reference to the model instance respectively and reciprocal references to each other.

In MVC implementation, there may be multiple views per model, but there is exactly one controller for each view. Each controller serves only the view that it is dedicated to. The MVC pattern can be applied to a single user interface element like (text box, button and etc), to a group of user interface elements like (a user control which contains a number of other user interface elements), to an entire web page or winform or an entire application.

I will present the MVC clock application demo to show the implementation of the MVC pattern. Although, there is no single definite right way to implement MVC and there are lots of incarnations in the market now, the basic principle of the MVC pattern prevails.

The sample MVC clock application project that I have included here is rather a simplified implementation of the traditional MVC pattern in 80’s. In the traditional MVC pattern in 80’s, each view on the screen surface is a widget (label, text box, button and etc) and each of this widget has its own dedicated controller to form an indivisible view/controller pair. Thus, we will end up with a number of view/controller pairs for a simple application. The MVC clock application will target the entire clock screen (contains a number of text box, button, label and date pickers) as a view and a clock controller is dedicated to the clock view. I am not trying to have the MVC clock application to emulate the exact way the MVC pattern being implemented in the Smalltalk application in 80’s but just to give you an idea of the MVC principle. As you know the advance in technology will affect the way we implement certain things but the underlying principles still remain. For e.g. the widget (view) in the 80’s didn’t deal with the user input, instead it relied on its dedicated controller for the job. Whereas, the widget now can process inputs due to the advance in GUI technology.

Figure 1.1 depicts the MVC communication cycle for the MVC clock.



Figure 1.1 shows the simplest case of the MVC pattern used in the MVC clock application demo which you can download the code at the end of this discussion. It only has a single model, a single view and a single controller. However, it is very common for an application to have more than one view for a single model. For e.g. in the MVC clock implementation, we have only one single clock Model but we can have more than one view, probably we can add another analog clock view to the MVC clock project.

 

Class responsibilities in the MVC Clock

 

This section will touch on the MVC clock application demo.

Responsibilities of the Model (Clock)

 

The Clock model in our clock application defines methods specific to a clock. The methods include the SetTime() (to set the current time of the clock model) and SetAlarmTime() (to set the alarm time of the clock model). Controllers in the MVC must be custom written to manipulate the model. So, the controllers must know the SetTime() and SetAlarmTime() in order to manipulate the clock model.

In MVC, the model’s data can be changed externally by other classes or internally by its own logic. For e.g. the user might set a new time for the clock by clicking on the Set New Time button or it might be updated because, internally, it detects the passing of a second. In the clock application code, it  tracks the passing of a second itself through a timer that fires every 1000 milliseconds.

The model must also provide a way for the views to register themselves with the model. In the event of model’s state change, the model can notify all the registered views about the changes. The clock demo application implements the notification through the Observer pattern. If you would like to know how this pattern is being implemented in .NET  framework using the C# or other .NET language, please follow Microsoft’s pattern and practices at  http://msdn.microsoft.com/en-us/library/ms998543.aspx.

The clock view instance will have to register with the clock model’s TimeChanged and AlarmTimeChanged event through the method call to RegisterModel() in the clock view’s constructor. The TimeChanged event will notify all the registered clock views when there is time change due to the user input or due to the internal tracking logic that detects the passing of a second. The AlarmTimeChanged will notify all the registered clock views when the alarm time changed by anyone of the user input from the view.

You will notice that the clock model is implemented as static class including all its members as static. I want to make it as global and available to any instance of the view at runtime. It also provides the simplest implementation in term of codes.

In the clock demo application, there is only one digital clock view but you can easily add in another analog clock view without making any changes to the model and the controller. What you need to do is just to hook up your analog clock view with the model and the controller.

 

Responsibilities of the View

 

The view will render the user interface to reflect the state change in the model. In our clock demo application, when the time changes, the model will notify the registered clock view. In response to the notification, the clock view will refresh its current time on the form.

Each view must forward the input requests/events to the controller. It should not process the input itself. For e.g. the user might change the current time through the date time picker and click the button for the Set New Time on the view, then the view merely forward the input information to the controller and the controller make change to the model through its methods.

Although the view cannot process the input and make change to the model, it can query the model for information when a notification is received from the model. For e.g. the view might invoke the GetTime() method on the model to determine the new time when it receives time change notification from the model. However, in the clock application demo, I have chosen to send the new time to the views directly in an TimeEventArgs object at notification time (Observer pattern). This is a more common approach and straightforward compared to having the view to query the model again when the time change notification is received.

You may find odd that if the user make changes in the view, instead of responding to it immediately, the view passes the input to the controller which can make change to the model through its methods, model notifies the view about the change and the view finally renders its changes to the user. It would be easier if all these steps are skipped. However, when the application become more complex, you will see the benefits of MVC pattern. For e.g. I have decided to add another analog clock view to the MVC clock demo application, the MVC pattern allows this to be done seamlessly because what I need to do is just to hook up my new analog clock view to the clock model and the clock controller. My job is done. Any changes in any of the clock views will be detected and reflected in all the views. I don’t even need to write any code to make the digital clock view to notify or update the analog cock view (or vice versa).

Besides, the logic is centralized in the model, which prevent code duplication and it allow us to add or remove views at runtime with minimal effort.

Responsibilities of the Controller

 

The controller listens for notifications from the view based on user input and translates that input into changes in the model. For e.g. when the user click on the Set New Time button in the view, the controller translates the input conceptually from “Set New Time” to the command on the model “Set model’s time to bla bla bla”.

There are cases when the controller doesn’t update the model directly but instruct the view to make changes to user interface by calling methods on the view. These changes are purely cosmetic and have no effect on the model. For e.g.  Changing the time format from 12-hour to 24-hour format or vice versa. This is purely presentation concern and it doesn’t affect how the model stores its time.



After all the explanation of the MVC clock application demo, there are two key elements of MVC; Separated Presentation and Observer Synchronization . As the Smalltalk developed, these two key elements stayed.

Code Download: MVC clock application demo. (This application sample only requires Visual Studio 2008 that can open C# project. Right click on the above link and choose Save Target As.  Rename the extension from .pdf to .zip once you have downloaded the file. Let me know if you have any problem running the code.)


 

Application Model MVC

 

The original MVC used in the Smalltalk object-oriented programming language is not without faults. The MVC clock application example in the previous MVC section is just a simple way to demonstrate the MVC pattern and it only has very simple use cases which are very hard to find in the real life application. In our real life, User Interface gets more complex than we think especially in our current UI technology trend where it gets more complex, fancier, and user friendly.

To illustrate this point, let add another condition/requirement to the MVC clock application. If the time displayed is the alarm time set by the user then the displayed time is changed to some preset or user chosen color. It sounds simple at the first look. But the question is which element in the MVC is going to be responsible for this piece of presentation logic. Should this piece of logic be in the model, view or controller?

This shouldn’t fit into the domain logic object as the color used to display the alarm time is not part of the domain. It is certain that we can preset the color or allow the user to set the color through some mean of input and store the color value into a table for later references. Making the decision as to what color to preset or what color is available for the user input is certainly the domain issue. However, mapping that to the color for the displayed time is certainly the view logic issue. Where this piece of logic should be put? It is not a good idea also to put it in the text box that displays the time and we rather keep the text box generic and ignorant any kind of logic.

It is this kind of situation, the Application Model was invented. As the Smalltalk evolved, the folks behind Smalltalk faced this kind of problem and came up with a solution to it. It is called the Application Model MVC which is more inclined to the Presentation Model. It is introduced to shield the model and the view from the presentation logic responsibility. Thus, the controller and the view don’t access the model directly and don’t register with the model’s events. Instead, they access the Application model and register to its events. 

”Smalltalk was originally developed by Xerox Parc labs and they span off a separate company, ParcPlace, to market and develop Smalltalk. ParcPlace Smalltalk was called VisualWorks and made a point of being a cross-platform system.” – Taken from the VisualWorks Application Model section under Martin Fowler’s GUI Architectures.

Under the Application Model MVC, the communication among the model, view, controller and application model for the MVC Clock application will look something like this;


Figure 1.2 Communications among the Model, Application Model, View and Controller when the user changes the alarm time.

a. Controller receives input from user through keyboard or mouse to set the new alarm time.

b. Controller commands the application model to set the new alarm time.

c. Application model access the model and set the new alarm time through its method, SetAlarmTime().

d. The model raises the AlarmTimeChanged event so the application model will get notified about the change of the alarm time.

e. The application model delegate the event to the clock view.

f. The clock view queries the application model for the new alarm time and update its display to reflect the the latest alarm time.


Figure 1.3 Communications among the Model, Application Model, View and Controller when the current time equal to alarm time.

a. Model has the internal logic of tracking the passing of a second. For each passing of a second, the model raises an event to notify the application model about the change of the time.

b. Application model queries the model for the latest current and alarm time. It checks whether the current time is equal to the alarm time.

c. Application model then fires the TimeChanged event and the AlarmSet event to notify the text box about the change of time and the alarm time is reached.

d. The text box in the clock view displays the latest time in response to the TimeChanged event and changes the color of the time with the blinking effect in response to the AlarmSet event send by the application model.

Based on the Figure 1.2 and Figure 1.3, we notice that the Application Model can’t access or manipulate the view directly. Instead, it relies on the Observer Synchronization to communicate with the view. The application model cannot simply change the color of the text box; instead it has to raise the AlarmSet event and has the view to respond to it.

There is one more benefit with the application model. You can use it to store the state or data related to the view.


 

MVP (Model View Presenter)


MVP, a derivative of MVC. It was first published by IBM in 1996 and was declared as IBM’s next generation programming model for C++ and Java. Later, it was adapted by Andy Bower and Blair McGlashan for Smalltalk’s next generation framework called Dolphin Smalltalk, targeted at the Microsoft Windows platform. They find the latest variation of MVC; Application Model MVC doesn’t fit their needs until they discover IBM’s publication on MVP. They make some twists to the original MVP by IBM and come up with a more simplified MVP.

Dolphin Smalltalk’s MVP becomes the mainstream nowadays and IBM’s MVP is less appealing. In Dolphin Smalltalk’s MVP, there is more explicit discussion of how the presenter manipulates the view including information on what the presenter can do and can’t do. It is also easier to understand and straightforward.

Later, Martin Fowler retires the MVP pattern in favor of the Supervising Controller and Passive View.
Actually, the supervising controller described by Martin Fowler is oriented toward the MVP pattern employed in the Dolphin Smalltalk’s GUI framework where the MVP’s presenter replaces the application model in the Application Model MVC. In the Supervising Controller, the view handles a good deal of view logic and the presenter handles more complex cases.

In contrast, the presenter in the Passive View pattern has to do all the manipulation of the widgets leaving the View totally passive. The Passive View emerges later when people start exploring into TDD (Test Driven Development) in which the Passive View pattern makes the user interface of an application easily testable by introducing mock objects in the unit test.

Now we focus back on why the folks work for the Dolphin Smalltalk search for a better pattern to replace Application Model MVC. The controller used in the Application Model MVC is no longer applicable as there is no need for the controller to process the user inputs (capture keyboard and mouse events). With the introduction of Graphical User Interface operation system, Microsoft Windows into the market, a set of widgets are made available to construct user interfaces. At the same time they are able to capture the mouse and keyboard events leaving the controller needless.

The other usability problem with the Application Model is its inability to access the view directly despite the fact it is responsible for the view/presentation logic. It relies heavily on the Observer Synchronization to manipulate the view. For e.g. changing color of the text to show validation error, enabling and disabling the buttons and etc. Because of this, it will be better to break the observer synchronization to gain access to the view directly so the codes to perform all these will be less awkward.

So, the next will be the Supervising Controller as Martin Fowler describes it as the direction behind the Dolphin Smalltalk’s MVP.


 

Supervising Controller 

 

Dolphin Smalltalk’s is similar to Martin’s Fowler’s Supervising Controller. So, I would explain both as one. As we know, in MVP we have Model, View and Presenter with the Presenter as the replacement of Controller in MVC. Below is the role for each of them. 

Model

The model in Supervising Controller has the same role in the MVC whose sole purpose is to represent the problem domain. It is completely ignorant of the User Interface and the presenter which is the intention of the pattern. Even if the view has communication with it through query, it will be loose coupling through the mean of Observer Synchronization. 

View

It is the composition of widgets (text box, button and etc) on the screen. In MVC, each widget on the screen surface coupled with a controller. Since the controller is eliminated, the screen (web page/winform) is the view itself which has the responsibility to respond to the mouse and keyboard events and pass these input events to the presenter for further processing. In supervising controller, the view itself has some autonomy in User Interface update which can be defined declaratively. 

Presenter

It is in charge of the presentation logic. It commands the model to make necessary changes and change presentation according to the application rules. The presenter is allowed to communicate directly with the view so that it can make changes to the view. This is normally done through abstraction where the presenter keeps a private reference to the interface that the view inherits or implement. The interface, through which the presenter can manipulate the view. If we compare it to the Application Model MVC where the application model communicate with the view through observer synchronization, the presenter which can communicate directly with the view has eliminated the awkward code in the Application Model MVC. There is no special event needed for the view to handle as in the Application Model MVC. The rationale behind the Application Model MVC only communicates with view through loosely coupled events is it has unknown number of view/controller pairs for each widget added to the screen. Having this kind of relationship will shield the application model from frequent modification whenever there is new widget added to the screen. 

Figure 1.4 shows the communication among the Model, View and Presenter for the Supervising Controller.



Let apply this pattern to our MVP (Supervising Controller) clock application demo for the scenario when the user change the alarm time.


Figure 1.5 Communications among the Model, View and Presenter (Supervising Controller) when the user changes the alarm time.

a. View receives input from user through keyboard or mouse to set the new alarm time.

b. View delegate user input to the presenter.

c. Presenter accesses the model and set the new alarm time through its method, SetAlarmTime().

d. The model raises the AlarmTimeChanged event so the view will get notified about the change of the alarm time.

e. The clock view queries the model for the new alarm time and update its display to reflect the latest alarm time.

Let apply this pattern to our MVP (Supervising Controller) clock application demo for the scenario when the current time equal to the alarm time.



Figure 1.6 Communications among the Model, View and Presenter (Supervising Controller) when the current time equal to alarm time.

a. Model has the internal logic of tracking the passing of a second. For each passing of a second, the model raises a TimeChanged event to notify the presenter about the change of the time.

b. Presenter queries the model for the latest alarm time through model’s GetAlarmTime() method. It checks whether the current time is equal to the alarm time.

c. The presenter changes the view directly to reflect the latest state change in the model through the view’s interface IsAlarm.

Code Download: MVP – Supervising Controller clock application demo. (This application sample only requires Visual Studio 2008 that can open C# project. Right click on the above link and choose Save Target As.  Rename the extension from .pdf to .zip once you have downloaded the file. Let me know if you have any problem running the code.)


 

Passive View

 

Passive View is pretty much the same as Supervising Controller. The only different is that the view itself is totally passive as the name implies. The presenter in the Passive View handles all the view/presentation logic as much as it can no matter simple or complex cases. In this case, the view will become completely passive and it is no longer responsible to update itself from the state change in the model. Thus, the dependencies between the view and the model in either direction are totally eliminated as the presenter will assume all the responsibilities and roles between the view and the model in the Supervising Controller.

Passive view described by Martin Fowler look something much like the Application Model MVC. In Application Model MVC, the view interacts with the model through the application Model. In Passive View, the view interacts with the model through the presenter. The views in both patterns are shield from the model by application model and presenter respectively.

The force that drives Passive View’s popularity is its testability. Since all the presentation logic to update the view resides in the presenter, then the presenter is in charge of the entire workflow. The view can be easily mocked and the presenter can be effectively tested. We can test all the User Interface logic by just testing the presenter alone. By testing the presenter itself, we are actually testing the view indirectly and we only run a little risk by not testing the actual view itself.

Anyway, the decision to use Supervising Controller or Passive View is a judgment call.  Both patterns provide testability and the driving issue is how much of the view update logic to leave in the view. By having all the view update logic in the presenter, there will be lot of effort being put in to write the presenters as all the simple view update logic needed to be included into the presenter as well. However, if codes simplicity is preferred over the testability, Supervising Controller will be a better choice. 

Figure 1.7 shows the communication among the Model, View and Presenter for the Passive View.



Let apply this pattern to our MVP (Passive View) clock application demo for the scenario when the user change the alarm time.




Figure 1.8 Communications among the Model, View (Passive View) and Presenter when the user changes the alarm time.

a. View receives input from user through keyboard or mouse to set the new alarm time.

b. View delegates the user input to the presenter.

c. Presenter updates the model with the new alarm time through the model’s SetAlarmTime method.

d. The model’s raise AlarmTimeChanged event so the presenter will be notified of the change in the alarm time.

e. The presenters update the view directly through the view interface’s AlarmTime to reflect the latest alarm time in the view.

Let apply this pattern to our MVP (Passive View) clock application demo for the scenario when the current time equal to the alarm time.


Figure 1.9 Communications among the Model, View and Presenter (Supervising Controller) when the current time equal to alarm time.

a. Model has the internal logic of tracking the passing of a second. For each passing of a second, the model raises a TimeChanged event to notify the presenter about the change of the time.

b. Presenter queries the model for the latest alarm time through model’s GetAlarmTime() method. It checks whether the current time is equal to the alarm time.

c. The presenter changes the view directly to reflect the latest state change in the model through the view’s interface IsAlarm.

Notice that in both the Supervising Controller and Passive View patterns, when more complex presentation logic is involved (change the time to different color to indicate alarm time), the presenter assume the role to update the view according to the application rules. Only in Passive View, the presenter assumes simple and complex view update logic. The Supervising Controller encourages coupling between the view and the model via Observer Synchronization.

Code Download: MVP – Passive View clock application demo. (This application sample only requires Visual Studio 2008 that can open C# project. Right click on the above link and choose Save Target As.  Rename the extension from .pdf to .zip once you have downloaded the file. Let me know if you have any problem running the code.)

The two clock application samples I have enclosed with the Supervising Controller and Passive View patterns are desktop (winform) application. So, we can have a state full model to allow direct synchronization between the model and the view and presenter in Supervising Controller, and direct synchronization between the model and the presenter in Passive View.

In web application (ASP.NET), due to the stateless nature of the web, it rarely make sense to use the observer synchronization between the model and presenter or model and view.
This would be the end of this post. I haven’t touched on the Presentation Model which I have mentioned at the beginning of this post. I will leave it to my different post when I plan to write some stuff on the WPF. The MVVM (Model View ViewModel) is a derivative of Presentation Model and it is being employed in the Composite Application Block for WPF and Silverlight (PRISM).

My post 2 will surface within this month if I have not had much of the personal stuff to attend to.

See you in my next post.
Bye and stay tune...


References

 

  1. Official Microsoft ASP.NET   -> http://www.asp.net/mvc
  2. Martin Fowler’s GUI Architectures -> http://www.martinfowler.com/eaaDev/uiArchs.html
  3. Web Client Software Factory’s View Testability Guidance -> http://msdn.microsoft.com/en-us/library/cc304760.aspx