ASP.NET MVC Framework

Published 10/27/2007 by Henry in ASP.NET | Patterns

On Scott Guthrie's blog I saw that there is going to be a framework to build ASP.Net applications using the Model View Controller pattern.

What is the Model View Controller Pattern?
The MVC design pattern provides the ability to vary different software components separately. The pattern improves the software robustness and reusability.
The MVC pattern helps the software designer to fulfill the object-oriented design principles, such as the Open Closed Principle(OCP).
The idea of the OCP is that developers must decide early on in the analysis or design phase which parts of the system will be expanded later and which will stay fixed.
According to the OCP principle, the design is extended by adding new code and classes by inheriting existing base classes rather than modifying the existing ones.
Completed and tested code is declared closed, and it is never modified.

Classic design pattern Model View Controller
  • Model: Contains and manipulates the data in the program.  These are the components of the application that are responsible for maintaining state.  Often this state is persisted inside a database
  • View: defines how the data of the model is presented to the user; the view forwards received commands and requests to the controller. These are the components responsible for displaying the application's user interface. 
  • Controller:Defines how the user interface reacts to received commands and requests. These are the components responsible for handling end user interaction, manipulating the model, and ultimately choosing a view to render to display UI.  In a MVC application the view is only about displaying information - it is the controller that handles and responds to user input and interaction.

The idea is that the Presentation layer (GUI) easily can be switched from for example an ASP.Net web user interface for a windows Forms user interface.
The discussion if this is practical and will be used in real world applications always comes up when discussing this pattern.
When we switch the UI for a Unit test framework, this discussion is almost always turned over in favor for the pattern, because (Unit)testing ASP.Net Webpages can be quite cumbersome at times.
So just for the sake of (unit) testing our code alone this pattern can really add value to our work as developers.
The maintainability of the code should benefit also, because all the layers of our application are really separated and encapsulated.

The ASP.NET MVC Framework will be fully integrated with ASP.NET, which means it supports existing ASP.NET features like forms/windows authentication, URL authorization, membership/roles, output and data caching, session/profile state management, health monitoring, configuration system, the provider architecture, etc.
It will be pluggable and extensible for example: you can optionally plug-in your own view engine, routing policy, parameter serialization, etc. 
It also supports IOC container models (Windsor, Spring.Net, NHibernate) for using existing dependency injection.
You can unit test the application without having to run the Controllers within an ASP.NET process (making unit testing fast).
You can use any unit testing framework you want to do testing ( NUnit, MBUnit, MS Test).

I really am interested and will try to follow this, frankly I can't wait to try out a CTP.

Henry Cordes
My thoughts exactly...

Factory Pattern

Published 11/10/2005 by Henry in C# | Patterns
Tags: ,

The challenge:
We got a lot of classes derived from one baseclass. Like a TableRow with controls in it.
Every control got another control in the third row, like:

  • A Textbox
  • A DropdownListBox 
  • A RadioButtonList
  • Multiple Textboxes and a Dropdownlist (Date)
  • Etc.

In our client (A Webb App) we do not want to be bothered with which control we have to instantiate. We want to instantiate and get the right kind of object returned.
For this kind of scenario we can use the Factory Pattern.

A Factory Pattern returns an instance of one of the several classes depending upon the parameters passed to the shared/non-shared factory method. Typically, all these classes are inherited from a common parent class.
Each of them has common methods. But each of them has their own optimization task operation on data. For simplicity I decided to give an example that is more simple than the real life implementation I described above.
I will use a very simple example.

We got an abstract Employee class (must be inherited), which will act as our base class.
The Employee class has two properties:

  • Name (string)
  • Salary (double)

We derive from the Employee class two classes:

  • Developer
  • Manager

Because we do not want the hassle to instantiate another class everytime we want to create a developer instance, or a Manager instance and because there will be more Employee derived objects in the future (Secretary, Architect, etc.), we create a Factory class that does the job for us.
We call it the EmployeeFactory. 


 Here is the code for the Employee class, with the derived classes:

   1:  using System;
   2:  namespace FactoryExample
   3:  {
   4:      public abstract class Employee
   5:      {
   6:          #region Private Members
   7:          private string m_Name = string.Empty;
   8:          private double m_Salary = 0;
   9:          #endregion
  10:          #region Public Properties
  11:          public string Name
  12:          {
  13:              get { return m_Name; }
  14:              set { m_Name = value; }
  15:          }
  16:          public double Salary
  17:          {
  18:              get { return m_Salary; }
  19:              set { m_Salary = value; }
  20:          }
  21:          #endregion
  22:      }
  24:      public class Developer:  Employee
  25:      {
  26:          public Developer()
  27:          {
  28:              Name = "John Refactorer";
  29:              Salary = 2000;
  30:          }
  31:      }
  33:      public class Manager: Employee
  34:      {
  35:          public Manager()
  36:          {
  37:              Name = "Peter PeopleManager";
  38:              Salary = 5000;
  39:          }
  40:      }
  41:  }

Next we have the Factory:

   1:  using System;
   2:  namespace FactoryExample
   3:  {
   4:      public class EmployeeFactory
   5:      {
   6:          public Employee CreateEmployee(int employeeKind)
   7:          {
   8:              Employee EmployeeObject;
   9:              switch (employeeKind)
  10:              {
  11:                  case 0:
  12:                      EmployeeObject = new Developer();
  13:                      break;
  14:                  case 1:
  15:                      EmployeeObject = new Manager();
  16:                      break;
  17:                  default:
  18:                      EmployeeObject = new Developer();
  19:                      break;
  20:              }
  21:              return EmployeeObject;
  22:          }
  23:      }
  24:  }

And last but not least the console app that calls the factory to instantiate the Developer and manager objects.

   1:  using System.Collections;
   2:  using System.Text;
   3:  namespace FactoryExample
   4:  {
   5:      class Program
   6:      {
   7:          static void Main(string[] args)
   8:          {
   9:              EmployeeFactory EmpFactory = new EmployeeFactory();
  10:              Employee emp;
  11:              for (int i = 0; i < 2; i++)
  12:              {
  13:                  emp = EmpFactory.CreateEmployee(i);
  14:                  Console.WriteLine("{0} - ({1}) Name: {2} Salary: {3}",
  15:                                      i,
  16:                                      emp.GetType().Name,
  17:                                      emp.Name,
  18:                                      emp.Salary);
  19:                  emp = null;
  20:              }
  21:              Console.Read();
  22:          }
  23:      }
  24:  }

When we run this code the output in the console looks like this:


I hope you get the idea, I have some real use for this pattern in the situaton described at the beginning of this post.

Henry Cordes
My thoughts exactly...