Extending Classes: Extension Methods or Inheritance?

Introduction

Extension methods were introduced in C# 3.0 as a way of extending a class without necessarily having access to the original source code of the class.

As discussed in the C# Programming Guide on MSDN, extension methods were primarily introduced to the language to allow LINQ to add standard query operators such as GroupBy and OrderBy to any class that implements IEnumerable<T>.  This is very neat syntactically.

This article will examine how extension methods can be created and used.  It will then show one example where inheritance is probably a better approach to class extension.

Basic Usage of Extension Methods

To illustrate the basic approach to using extension methods as usual a code example is available.

This contains three projects:

1. A ‘Core’ class library intended to represent code developed by a core group of developers and used as a library by other developers.
2. A ‘DerivedExtended’ library that is intended to represent code extending the Core library, developed by a second group of developers.
3. A ‘Client’ library that uses the DerivedExtended library.

Initially the Core library contains just one class with just one public property:

namespace Core
{
    public class MyCoreClass
    {
        public int CoreValue { get; set; }
    }
}

How Extension Methods Work: Writing an Extension Method

We can extend our core class in our DerivedExtended library using extension methods.  To do this clearly DerivedExtended has to reference Core.  The syntax is simple to set up an extension method:

using Core;
 
namespace DerivedExtended
{
    public static class Extended
    {
        public static void SetCoreValue(this MyCoreClass myCoreClass)
        {
            myCoreClass.CoreValue = 1;
        }
    }
}

To make this work both the class and the method in it are declared static, and we use the ‘this’ keyword on the myCoreClass parameter.  The name of the static class (‘Extended’) is not relevant for the purposes of the extension method (it’s not used to invoke it in any way).

Our extension method can only access the public interface of the class it is extending.  That is in our case it can access the CoreValue property because it is public: if it were private the extension method would not be able to set it.

How Extension Methods Work: Calling an Extension Method

We now set up client code to use this:

using System;
using DerivedExtended;
 
namespace Client
{
    class Program
    {
        static void Main(string[] args)
        {
            // Instantiate the core class
            Core.MyCoreClass myCoreClass = new Core.MyCoreClass();
 
            // Call extension method
            myCoreClass.SetCoreValue();
 
            // Get property value from core class and display it
            Console.WriteLine(myCoreClass.CoreValue);
 
            Console.ReadLine();
        }
    }
}

Note the syntax for calling the SetCoreValue extension method: to the client code it looks exactly like a normal instance method on the myCoreClass instance.  Note also that we have to use ‘using DerivedExtended’ directive for the compiler to find the relevant extension method.

Clearly the code above prints ‘1’ to the console window: the extension method has set the property value as you would expect.

Why This is Fragile

Now imagine our core developers decide that they need a method to set the core value, and that the method should be setting the value to 100.  If they are library developers they may know nothing about the client code and DerivedExtended library written by the second development team.  So they make the simple change below:

namespace Core
{
    public class MyCoreClass
    {
        public int CoreValue { get; set; }
 
        public void SetCoreValue()
        {
            myCoreClass.CoreValue = 100;
        }
    }
}

Now if we run our client code we see that the behaviour has been changed: it prints out 100.  However nothing has ostensibly been broken: our DerivedExtended developers could easily rebuild against the new Core library, not spot anything had changed, and ship the code with changed behaviour.  Of course in my simple example it doesn’t look like the effects of this are likely to be catastrophic.  However because of the extension method the DerivedExtended developers now need to be much more careful when the implementation of the Core library changes.

Extension Methods or Inheritance?

Of course, in object-oriented languages we already have a means of extending a class where we don’t necessarily have access to or want to change the original source code: it’s called inheritance.

In C# and other object-oriented languages there is extensive support for allowing a base class writer to control how their class will be extended by inheritance, such as declaring methods as virtual, declaring member variables as protected and so on.  A number of our core design patterns are based around designing classes that can be extended in this way (e.g. Template Method).

Why This Isn’t a Problem with Inheritance

Now consider the same extension as above being made with inheritance.  Firstly we revert our Core class to simply have the CoreValue property:

namespace Core
{
    public class MyCoreClass
    {
        public int CoreValue { get; set; }
    }
}

Then we construct a Derived class that contains a SetCoreValue method that again sets the value to 1.  Thus we extend our code in a new library in the traditional way:

namespace DerivedExtended
{
    public class Derived : Core.MyCoreClass
    {
        public void SetCoreValue()
        {
            base.CoreValue = 1;
        }
    }
}

We can now change our client code to use this extension:

    class Program
    {
        static void Main(string[] args)
        {
            // Now consider case where we extend by inheritance
 
            // Instantiate the Derived class
            Derived derived = new Derived();
 
            // Call the derived method
            derived.SetCoreValue();
 
            // Get property value from derived class and display it
            Console.WriteLine(derived.CoreValue);
 
            Console.ReadLine();
        }
    }

}

And clearly here the code will print out ‘1’ again.

Now, as before, assume our Core library developers add a SetCoreValue method to the Core class, unaware that there already is one in the Derived class:

    public class MyCoreClass
    {
        public int CoreValue { get; set; }
 
        public void SetCoreValue()
        {
            CoreValue = 100;
        }
    }

This doesn’t change the behaviour of the existing client code, which still prints out ‘1’.  However, we get a compiler warning:

‘DerivedExtended.Derived.SetCoreValue()’ hides inherited member ‘Core.MyCoreClass.SetCoreValue()’. Use the new keyword if hiding was intended.

So not only has the code not been broken, but our DerivedExtended developers will get a warning that there is a problem when they come to recompile their code against the new library.

Note also that any code the Core developers write calling SetCoreValue on the Core class will correctly call the Core class version (they don’t know about the Derived class version so can’t want to call it).

This behaviour is deliberate: by default a method in a derived class hides rather than overrides a method with the same signature in a base class if there has been no explicit use of the ‘new’ or ‘virtual/overrides’ keywords.  This is precisely because of the circumstances with regard to extension described here.

Summary

So in summary, in the circumstances described where a development team is extending classes in a library it seems better to do this by inheritance than by extension methods.  Obviously it isn’t always possible to extend a class by inheritance and we may need to use other techniques, but in general extension methods seem fragile to me.

To an extent the same argument applies to any class in our code, whether in a library or not.  Suppose we use extension methods and then later on we alter the implementation of the class we are extending.  We can break our extension methods without necessarily noticing we have done so.  Of course this is true of any code that uses the public interface of our class if its behaviour changes, so is less valid as an argument against extension methods.

MSDN

Microsoft itself agrees with the central argument in this article.  In the page on extension methods in the C# programming guide it says:

General Guidelines

In general, we recommend that you implement extension methods sparingly and only when you have to. Whenever possible, client code that must extend an existing type should do so by creating a new type derived from the existing type. For more information, see Inheritance (C# Programming Guide).

When using an extension method to extend a type whose source code you cannot change, you run the risk that a change in the implementation of the type will cause your extension method to break.

Conclusion

Extension methods can be fragile.  My recommendation is that you don’t write your own extension methods, for the reasons explained above.

Running Visual Studio as an Administrator under Windows Vista

Introduction

This article discusses why we should run Visual Studio as an administrator, and examines the easiest way to do that under Windows Vista.

Visual Studio and Administrator Rights

As .Net developers we need to be able to run Visual Studio as a Windows administrator.

Visual Studio 2005 actually warns you at start up if you are not running it as an administrator under Vista, and Microsoft recommends that you always run it with administrator privileges.  In fact MSDN gives a list of scenarios where Visual Studio 2005 will have ‘issues’ if it is not running with these privileges:

http://msdn.microsoft.com/en-us/vstudio/aa972193.aspx

For other versions of Visual Studio and operating systems there are fewer issues about not running Visual Studio as an administrator.  However there are a number of scenarios where you need administrative privileges.  These include needing to install or reinstall anything, or to do any kind of Office add-in work, or to use ActiveX controls, or even just to register a library for COM Interop.

Running Visual Studio as an Administrator

Under earlier versions of Windows developers usually just made themselves local administrators on their development computers to ensure Visual Studio had sufficient privileges.   Under Vista however, this is not enough (it is still necessary to be an administrator, but not sufficient).

This is because if you run an application under Vista by default it does not have administrative privileges unless specifically given them.  This is true even if the user running the application has administrative privileges.

Granting Visual Studio Administrative Privileges

There are (at least) three ways of starting Visual Studio with administrative privileges in Vista.

Note that for all three you need access to an administrator account.  It’s easiest if you are logged in as an administrator, in which case you will simply get a User Account Control warning saying ‘A program needs your permission to continue’ (and you can just click ‘OK’).  If you are not logged in as an administrator the User Account Control will ask you for an administrator’s ID and password before it will launch the program.

The three ways of running Visual Studio with administrative privileges are:

1. Right-click on the shortcut to Visual Studio and select ‘Run as administrator’ from the context menu.
2. Type ‘devenv’ into the Start Search box (at the bottom of the Vista Start menu: just hit the Windows key and you are in it).  Then hit Control-Shift-Enter, rather than just Enter.  Control-Shift-Enter tells Windows to start the program with administrative privileges.  This one is for those of you who don’t like reaching for a mouse.
3. Right-click a shortcut to Visual Studio, select the Compatibility tab, and check the ‘Run this program as an administrator’ checkbox at the bottom.

Always Running Visual Studio as an Administrator

The last of the items above (item 3) is the one to use if you always want to run Visual Studio as an administrator.  Once the checkbox is checked in future you will be able to click on any shortcut to Visual Studio and it will run with elevated privileges.

Note that setting the ‘Run this program as an administrator’ property on a shortcut actually sets it on the underlying executable itself (in this case devenv.exe).  It isn’t possible as far as I can see to have one shortcut that will run the program as an administrator, and another one that will run it with normal privileges.

User Account Control

If you always run Visual Studio as an administrator you are going to get the User Access Control warning every time you start it, even if you are logged in as an administrator to Windows.  Obviously you can just click ‘OK’ to dismiss this warning, but it may tempt you to turn User Access Control off.

Note that this is true only if Vista’s User Account Control (UAC) is turned on.  Many developers turn UAC off, and in this case Vista behaves in the same way as earlier versions of Windows with regard to starting Visual Studio: if you are logged in as an administrator then Visual Studio will by default run with administrative privileges.

The Administrator Account

Vista also has an account called ‘Administrator’ which behaves differently from other administrator accounts.  In fact it behaves like administrator accounts in earlier versions of Windows, in that all programs launched when using it run with administrator privileges by default.  There’s no need to specifically set up the program as described above.

As a developer your really shouldn’t need to use this account: you can develop with administrator privileges using the techniques described in this article.

However you may have occasions when you aren’t sure whether a program is failing because of some coding error or simply because a process is being launched with insufficient privileges.  In these cases it may be useful to use the Administrator account temporarily to simply rule out a problem with privileges.  Note that if you work for a large organization they are almost certainly not going to let you near this account, however: this is really only useful for those developing at home.

Using the Administrator Account

To enable the Administrator account start a command prompt with administrator privileges as described above (type ‘cmd’ in the Start Search box and hit Control-Shift-Enter).  Then enter:

net user Administrator /active:yes

This has a blank password by default.  To set a password use:

net user Administrator {password}

You can now log off and log on as the Administrator.  Once you are done with any testing you should disable this account again as below

net user Administrator /active:no

Note that disabling the account does not clear the password.  However if you forget it you can always set it again as above when you come to use the account again (provided you have access to at least one account with administrator privileges).

Aside: Administrator Account on Windows XP

The Administrator account discussed above is the main default administrator account for a computer.  Previous versions of Windows had this account as well, although other accounts with administrator rights behaved in the same way.

In particular it existed under XP.  Not only that it was enabled by default, and had a blank password.  If you’ve got an XP computer at home try hitting Ctrl-Alt-Del twice on the screen that shows your accounts, and then enter ‘Administrator’ and a blank password.  If that logs you on with admin rights you may want to consider disabling the account as described above.

Code links now working again

The links for downloading code should now be working again.

Apologies: Code Links Are Broken

Apologies to those of you trying to download code. I am having some issues with Plusnet. I will try to resolve these as soon as possible.

Model-View-Presenter using the Smart Client Software Factory (Introduction To CAB/SCSF Part 25)

Introduction

Part 23 and part 24 of this series of articles described the Model-View-Presenter pattern.

This article explains how the Smart Client Software Factory supports this pattern by generating appropriate classes.

Part 26 of this series of articles will show how to use the generated classes in more detail.

Guidance Automation Packages in the Smart Client Software Factory

We saw how we could use the Smart Client Application Guidance Automation Package to set up a Smart Client Application in part 18. We can also set up a Model-View-Presenter pattern in a Smart Client application using another of the Guidance Automation Packages.

This will only work in an existing Smart Client Application.

Running the Model-View-Presenter Package

To use the Guidance Automation Package we right-click in Solution Explorer on a project or folder where we want to run the package. It is intended that we do this in the Views folder in a business module. On the right-click menu we select ‘Smart Client Factory/Add View (with presenter)’. We get a configuration screen that lets us name our view, and also lets us put the classes that get created into a folder. For the purposes of this example we name our view ‘Test’, and check the checkbox that says we do want to create a folder for the view.

When we click ‘Finish’ we get three classes and a TestView folder as below:

Classes Created

1. TestView
   This is (obviously) our View class. It is intended that this contain the auto-generated code to display the View. As discussed in the previous articles any complex view logic will not go into this class, but will go into the Presenter.
2. TestViewPresenter
   This is our Presenter class. As discussed in previous articles this should contain logic to deal with user events. It should also contain any complex view logic, and should directly update the View with the results of an view logic calculations. It has access to the View class via an interface.
3. ITestView
   This is the interface that the View implements. The Presenter can only update the View through this interface.

Diagram

In terms of the diagrams shown in parts 23 and 24 this looks as below. Remember that we may or may not have arrows between the Model and the View depending on whether we are using the active View or passive View version of Model-View-Presenter:

Where’s the Model?

The Guidance Automation package does not set up a Model class for us. As we have seen, the Model has no direct references to a View/Presenter pair (it raises events), and there may be multiple View/Presenter pairs for one Model. Further the Model would not usually be in the same folder, or even in the same component, as our View and Presenter.

For these reasons we are expected to set up our Model classes separately by hand.

Note that the Presenter (and the View as well if we are using the active View pattern) will have a direct reference to the Model. We will have to add these references manually.

Active and Passive View: a Quick Recap

Remember that in Model-View-Presenter the Presenter updates the View via an interface. We can set this up so only the Presenter is allowed to update the View. This is the ‘passive View’ pattern. We can also set this up so that the Presenter can update the View in complex cases, but the View can also update itself (in response to an event or user request) in simple cases. This is the ‘active View’ pattern.

Active and Passive View: Which Should We Use?

The pattern described in the SCSF documentation is the passive View: the documentation implies that all updates to the View should be done by the Presenter.

However there is nothing to stop us using the active View pattern with the classes generated by the Guidance Automation Package. We can add code to update the View wherever we like. In fact I would recommend using active View in simple cases: passive View should only be used where we are putting too much logic into the View class.

Should We Use Model-View-Presenter for Every Screen? A Personal View

Let me also reiterate a point made in part 24. It’s easy to get obsessive about the use of patterns and use them everywhere without thinking. My personal opinion is that we should only use the full Model-View-Presenter pattern where we have a complex screen that will benefit from the separation of the View and Presenter classes. For very basic screens the pattern is really too complex to give us benefit. In simple cases I think it is fine to put event handling and screen update logic directly behind the screen.

Note that I don’t think this applies to the use of the Model. We should always separate out the business logic from our screens into separate classes (this is what Martin Fowler calls ‘Separated Presentation’). However, we frequently have screens that don’t show any business logic or business data, so we may not need a Model class either.

For example an About screen that just shows the system name and version won’t need separate View and Presenter classes, and probably won’t need anything in a Model class either.

Equally a screen that shows a read-only grid of currencies used in a trading system probably doesn’t need separate View and Presenter classes. In this case the currencies themselves should be in a Model class so that other screens can access them.

Implementation Details: What We’d Expect

If we examine the diagram above, we expect the Presenter to have a data member with type of our ITestView interface that it will use to access the View. We expect the View to implement the ITestView interface to allow this. We further expect the View to have a direct reference to the Presenter class (a data member), which it will use to invoke code relating to user events. We’d probably expect both the View and the Presenter classes to be created the first time the View is needed.

Implementation Details: the Base Presenter Class

The actual details of the implementation of the Presenter are a little unusual.

If we look at the code generated by the Guidance Automation Package we see that the TestViewPresenter above has been given its core functionality by inheriting from an abstract Presenter<TView> class. Remember that the generic ‘TView’ simply lets us provide a type whenever we use the Presenter class. Here we inherit from Presenter, and provide the type when we inherit:

    public partial class TestViewPresenter : Presenter<ITestView>
    {

This allows the base Presenter class to have a data member of type ITestView (which is what we expect), rather than it being directly in the TestViewPresenter class. Note that the base Presenter is in the Infrastructure.Interface project (which is one of the reasons why we have to use this pattern in a Smart Client application).

The base Presenter class exposes our ITestView data member publicly, contains a reference to our WorkItem, and has disposal code and a CloseView method. It also has virtual OnViewReady and OnViewSet methods. These get called when you’d expect from the name and let us respond at the appropriate times by overriding the methods in our TestViewPresenter class.

All the above functionality in the base Presenter class means that the derived TestViewPresenter class is basically empty when it is created. It is up to us to put logic in there to handle user events and complex view logic.

The TestView class is a normal user control. It implements ITestView and contains a reference to the TestViewPresenter as we’d expect. It also calls OnViewReady as appropriate (in the OnLoad event of the user control). Again other than this TestView is also basically empty.

Conclusion

This article has shown us how to set up Model-View-Presenter classes using the Smart Client Software Factory, and discussed some issues surrounding it.

Part 26 of this series of articles will show how to use these classes in practice, providing code examples.

Model-View-Presenter: Variations on the Basic Pattern (Introduction to CAB/SCSF Part 24)

Introduction

Part 23 of this series of articles described the basic Model-View-Presenter pattern (MVP).

This article examines the Model-View-Presenter pattern in more detail. It describes some variations on the basic pattern, and looks at the advantages and disadvantages of using the pattern.

Part 25 of this series of articles will examine how the Model-View-Controller pattern is implemented in the Smart Client Software Factory (SCSF).

Can the View Update Itself? Active View versus Passive View

The version of Model-View-Presenter described in part 23 has an ‘active View’. This means that the View can update itself directly from the Model (arrows C and D on the diagram in the article). As described in part 23, the View can also be updated by the Presenter.

An alternative to this is what Martin Fowler calls the ‘passive View’. Here the View cannot update itself directly from the Model. The only way the View can be updated is via the Presenter. This is the pattern that the Microsoft SCSF documentation describes as Model-View-Presenter.

Diagrammatically this looks as below. It’s identical to the diagram in part 23 except that there are no arrows between the Model and the View:

The passive View design leads to more code in the Presenter and more code in general as the View now has to expose everything that can be updated on its interface, and the Presenter has to be coded to update it appropriately. However, this is arguably a less complicated design than the original active View in part 23.

Does the View Update Automatically? Active Model-View-Presenter versus Passive Model-View-Presenter

As with Model-View-Controller we have a distinction between an ‘active’ and a ‘passive’ design overall (see the section ‘Active and Passive MVC’ in part 22). Model-View-Presenter as described above in part 23 is ‘active’ Model-View-Presenter. This means that if the Model changes all Views will be updated automatically via the eventing mechanism. These events may be sunk in the Presenter or the View.

It is also possible to set up ‘passive’ Model-View-Presenter. This is a slightly simpler pattern where the Model does not raise an event when it changes. This means the View is not updated ‘automatically’. Instead the View is updated when the user next requests it (by pressing a ‘Refresh’ button for instance). At this time either the View or the Presenter will go to the Model to get the new data.

Advantages of Model-View-Presenter

As with Model-View-Controller, Model-View-Presenter has the advantage that it clarifies the structure of our user interface code and can make it easier to maintain. Not only do we have our data taken out of the View and put into the Model, but also almost all complex screen logic will now reside in the Presenter.

This solves the problems with more traditional user interface designs as described in the last few articles. However, it comes at the cost of some complexity.

Since we now have almost no code in our View apart from screen drawing code Model-View-Presenter also makes it theoretically much easier to replace user interface components (user controls, whole screens, or even the whole user interface (Windows Forms to WPF for example)).

In addition unit testing the user interface becomes much easier as we can test the logic by just testing the Presenter. However see part 23 for some comments on whether this is strictly necessary.

Disadvantages of Model-View-Presenter

The disadvantages of Model-View-Presenter are similar to the disadvantages of Model-View-Controller as described in part 22:

• The pattern is complex and may be unnecessary for simple screens.
• The pattern is one more thing to learn for busy developers: there’s some overhead.
• It can be hard to debug events being fired in active Model-View-Presenter.
• The ‘Passive View’ version of Model-View-Presenter can lead to a certain amount of boilerplate code having to be written to get the interface into the View to work.

My personal view is that even if you think this is a useful pattern (and it is) you shouldn’t use it indiscriminately on every screen in your application. You should use it where you have reasonably complex logic which will benefit from splitting the user interface classes in this way.

User Events and View Logic Combined in the Presenter

One thing that seems a bit odd with Model-View-Presenter is that we have factored both the responses to user input events and what I’m calling the ‘complex view logic’ into our Presenter. At first glance these seem to be slightly different things: perhaps we should have separate classes for each? Perhaps we need a Presenter and a Controller?

One reason for not doing this is that our user interface is getting very complicated if we have both Presenter and Controller.

Also, in the passive version of Model-View-Presenter we may want the user event itself to call the complex view logic and to directly update the View. This means that the code to handle the user event also needs to contain the view logic. It can’t do this if we have separate classes for the two pieces of functionality. In this case it makes more sense if we only have one class.

However, splitting the Presenter into two classes may be a valid pattern in active Model-View-Presenter. Here the Model will be updated in response to a user event by the Presenter. The Model will then raise an event to the Presenters telling them to update the View for complex view logic. The user event and complex view logic are thus separate in the Presenter and could be split into separate classes. We would probably only want to do this in very complex screens.

Model-View-Controller and Model-View-Presenter Confusion

As Martin Fowler points out, there’s a lot of confusion over what Model-View-Controller is. As already discussed, this arises because it doesn’t really apply to modern user interface programming languages in its purest Smalltalk form.

Equally there seems to be a lot of confusion over what Model-View-Presenter is. Martin Fowler currently calls the basic MVP pattern that I describe in part 23 ‘Supervising Controller’. He calls the amended version presented in this article ‘Passive View’ (as does this article).

I’m not quite sure why Mr Fowler calls the basic Model-View-Presenter pattern ‘Supervising Controller’ and not ‘Supervising Presenter’. It seems to me that the key difference between Model-View-Controller and Model-View-Presenter is that the Presenter in Model-View-Presenter can update the View directly. This is not permitted in Model-View-Controller; here the View updates itself from the Model. In the ‘Supervising Controller’ the Presenter/Controller can update the View directly.

Having said that I’m not sure that Mr Fowler would recognize the pattern described in part 22 as Model-View-Controller: this is closer to Model-View-Presenter as he describes it. As I mention in part 22 the pattern described is not ‘pure’ Model-View-Controller because the user events are initially sunk in the View (which is normal with modern UI widgets) and because there’s only one Controller and View per screen, rather than one per widget as in pure Model-View-Controller.

Finally note that I have adopted the ‘Passive View’ nomenclature in this article. However personally I think calling this pattern ‘Passive View’ adds to the confusion surrounding Model-View-Presenter. We already have the concept of active/passive Model-View-Controller and Model-View-Presenter as a whole, ‘active’ being the case where all Views get updated automatically on a change in the Model, ‘passive’ being where they have to update themselves. This is easily confused with an active/passive View distinction. Here an ‘active’ View is one that can update itself from the Model, whether automatically or not.

Conclusion

We have now covered quite a lot of the theory behind both Model-View-Controller and Model-View-Presenter.

Part 25 of this series of articles will show how we can use Model-View-Presenter in the CAB/SCSF using an SCSF Guidance Automation Pattern.

References

The two flavours of Model-View-Presenter described by Martin Fowler
http://www.martinfowler.com/eaaDev/PassiveScreen.html (‘Passive View’ in fact)
http://www.martinfowler.com/eaaDev/SupervisingPresenter.html (‘Supervising Controller’ in fact)

Martin Fowler overview of GUI Architectures, including Model-View-Controller and Model-View-Presenter
http://www.martinfowler.com/eaaDev/uiArchs.html

Good explanation of Model-View-Presenter, Passive View and Supervising Controller on CodePlex
http://www.codeplex.com/websf/Wiki/View.aspx?title=ModelViewPresenterPatternDescription&referringTitle=MVPDocumentation

MSDN Article with code example (although the article is a little confusing)
http://msdn.microsoft.com/msdnmag/issues/06/08/DesignPatterns/

See also the page in the Smart Client Software Factory documentation on Model-View-Presenter
http://www.codeplex.com/smartclient/Release/ProjectReleases.aspx?ReleaseId=5027

Model-View-Presenter: Why We Need It and the Basic Pattern (Introduction to CAB/SCSF Part 23)

Introduction

Part 22 of this series of articles looked at the Model-View-Controller pattern and discussed how it is one way of structuring a user interface to avoid having too much code behind a screen.

This article will examine some of the shortcomings of Model-View-Controller, and describe an alternative, which is Model-View-Presenter.

Part 24 of this series of articles will then briefly examine some variations on the basic Model-View-Presenter pattern described here, and look at the advantages and disadvantages of the pattern.

Part 25 of this series of articles will look at the support that CAB/SCSF gives us for the Model-View-Presenter pattern.

Model-View-Controller Problems

There are a couple of user interface scenarios that are difficult to handle with the Model-View-Controller pattern. The first of these is the one that is most widely cited as a problem with Model-View-Controller, but in my opinion the second is the more difficult case to deal with, in spite of the fact that it’s hardly an unusual scenario:

1. Elements of our screen display depend on complex business logic

The canonical example here is coloring the background of a field in varying colors depending on the output from some business rule.

For example suppose we are showing daily sales figures for a business. We might want to color the background of a sales figure green if that figure is more than 10% above the average daily sales figure for the quarter, and color it red if it’s more than 15% below the average. Otherwise we leave the background white.

Model-View-Controller struggles with this scenario. Clearly it involves calculations involving business logic (averaging the sales figures for the quarter). In the Model-View-Controller pattern the business logic should go in the Model class. However, the only place we can sensibly put the coloring logic is in the View when it refreshes itself. We’ll come back to this below.

Note that we want to be able to enter the daily sales figure and have the background color change appropriately depending on the new value.

2. Elements of our screen display depend on what the user has selected in other screen components in a complex way

This could be as simple as a Save button being enabled only if the user has actually changed something on the screen (and being disabled again if the user changes the screen back to its original values).

Again the only place we can logically put this sort of logic in the Model-View-Controller pattern is in the View when it refreshes itself.

Whilst these problems are slightly different they can both be thought of as complex view logic surrounding the state of the user interface.

Why is Putting View Logic in the View a Problem?

In both of the examples above there probably isn’t all that much code relating to our view logic, and maybe putting it in the View in a Model-View-Controller pattern will be fine. However, with complicated screens this ‘view logic’ can run to many hundreds of lines of code. We don’t really want this code in our View, which we want to just be simple screen drawing code. Part of the idea of splitting out the View, after all, is that it becomes so simple we can easily replace it if we want to change our screen technology.

Another problem with having this logic in the View is that the event model may get quite complex. In my example it’s possible that a change in a sales figure that we’re not actually displaying could affect the background color of the textbox. Remember that we are comparing the textbox contents to the average daily sales. If the average daily sales change sufficiently we may need to raise an event to force a color change.

There’s another reason why developers prefer to get this ‘view logic’ out of the actual View class. It can be hard to automatically unit test a View class. Screen widgets often don’t lend themselves to unit testing. If the view logic is in another class it may be easier to unit test it.

Aside on Unit Testing in User Interfaces

I think the difficulties of unit testing user interfaces in Microsoft world are hugely exaggerated. Most Microsoft controls will let you do programmatically almost anything you can do with a mouse and keyboard. So, for example, we have a PerformClick method on a button, and settable SelectedIndex and SelectedItem properties on a ListBox. We can instantiate our screen in the test and interact with it programmatically in the same way we would if we were clicking on things. We have extensive unit tests that work this way in our current project.

It’s true that interactions between controls can be difficult to test (e.g. drag-drop operations). Also third-party (non-Microsoft) controls often don’t expose mouse and keyboard actions in the same way. However, in general you can usually unit test a user interface fairly extensively without recourse to restructuring your code as outlined in this article.

The Presenter in Model-View-Presenter

The first thing to understand about Model-View-Presenter is that it is very similar to Model-View-Controller, only with the Controller replaced with a Presenter (predictably).

The idea of the Presenter is that it can update the View directly. This isn’t permitted for a Controller in Model-View-Controller. This means we can put our complex ‘view logic’ described above into the Presenter and take it out of the View. Clearly we couldn’t do this with the Controller in Model-View-Controller since it had no easy way of updating the View with the results of the view logic: the View updated itself from the Model and the Controller was not involved.

Note that the Presenter, as with the Controller in Model-View-Controller, handles user events raised from the View as well. This means the View only contains screen drawing logic, which is what we want.

So a Presenter is able to ‘present’ data: it can directly update the View. On the other hand a Controller only controls: it takes user input and updates the Model as appropriate. Note that the Presenter is doing some controlling as well since it handles user events.

Diagram of Model-View-Presenter

Diagrammatically this looks as below:

As you can see, we again have three classes that interact. As with Model-View-Controller the Model class contains the data to be displayed, and the View class contains the code that actually draws the screen. We have already discussed the Presenter.

As with Model-View-Controller we can have multiple Presenter/View pairs of classes interacting with the same Model (with a change entered on one screen updating other screens showing the same data).

Class Interaction (active Model-View-Presenter with an active View)

When a user interacts with the View an event will be raised. This will be passed immediately to the Presenter (A). The Presenter will update the Model as appropriate (B): it may go back to the View to get the data it needs (F). The Model may at this stage raise an event that gets sunk in the View (C), leading to the View updating itself from the Model (D).

So far everything is the same as in active Model-View-Controller (except with the Controller replaced with the Presenter).

The difference is that when the Model is updated by the Presenter it may raise an event that also gets sunk back in the Presenter itself (E). The Presenter may then apply the complex view logic to work out what needs to be displayed before updating the View (F).

So in this version of Model-View-Presenter the View can update itself directly from the Model in simple cases where there is no view logic. When some view logic is needed the Presenter intervenes. It handles that logic and updates the View directly.

Interface on the View (F)

Another point to note here is that the Presenter accesses and updates the View through a clearly-defined interface on the View (F in the diagram). This has two effects. Firstly we can replace the View more easily with another screen technology since we know exactly what methods need to be exposed (those in the interface). Secondly this makes automated unit testing simpler. We can test the Presenter without needing screen elements directly by mocking the interface on the View in another class.

Conclusion

This article has described a basic Model-View-Presenter pattern and contrasted it with Model-View-Controller. It has examined why we need a different pattern to Model-View-Controller.

Part 24 of this series of articles will examine some variations on the Model-View-Presenter pattern described here, including the one in the Microsoft documentation for the SCSF. It will also discuss some of Martin Fowler’s user interface patterns that are relevant. References to articles for part 23 and part 24 will be given at the end of part 24.

Model-View-Controller Explained (Introduction to CAB/SCSF Part 22)

An Apology, and Topics Still To Be Covered

Let me start by apologizing to all the CAB/SCSF fans (?) out there who have been asking me to continue the series of posts. I know it’s been a while since I wrote about the CAB/SCSF (I got diverted by FpML as you can see). However the series of articles is not yet finished and I will be sporadically posting on the topics many of you have been asking about. If there’s interest I may look at how to use some of the other application blocks with the CAB as well.

If there are specific things you would like to see covered please leave a comment.

Having said that, our CAB project is live and working well, and we are moving onto other issues, so my enthusiasm for spending my Saturday mornings writing about CAB/SCSF has waned somewhat.

Introduction

Part 21 of this series of articles briefly discussed foundational modules and the way constants are handled in an SCSF project.

Part 23 of this series of articles will examine another Smart Client Software Factory Guidance Automation pattern, the Model-View-Presenter.

By way of preparation for part 23, this article discusses the problems with putting code directly behind screens in smart client applications, and a traditional solution to this, which is Model-View-Controller.

The Basic Problem

When writing user interface code it’s quite easy to put too much logic in the class that draws a form or user control.

In badly-designed .Net applications, for example, it’s not uncommon to see classes behind user controls of several thousand lines of code (excluding the automatically generated code). We may have code that handles events, updates the data on the screen, caches and refreshes data, updates the state of user interface controls based on the data or user input, colors parts of the screen based on the data, binds data to controls in complex ways and so on.

With all this code in one class it can be difficult to work out what is going on. The code becomes hard to maintain.

Clearly if we have a lot of code doing different things in a class we are violating the single responsibility principle. We should be looking to refactor in such a way that we have a number of classes, each with a clear role and tidy interfaces into the other classes.

The difficulty with this is that it isn’t necessarily easy to see how to break up this sort of code in a logical way. There are a number of user interface patterns that address this. The granddaddy of them all is Model-View-Controller (MVC), although as we shall see this is not a pattern you are likely to see in a .Net application, at least in its original pure form.

Where to Cache the Data

It’s arguable that the main problem Model-View-Controller solves is that of data being cached directly behind a screen and not elsewhere in the application. Again this is a common problem in poorly written smart client applications.

Suppose we have a screen that displays data that has been retrieved into a series of textboxes directly from a middle-tier service. This data is loaded into the textboxes the first time it is displayed, retained in the textboxes but not actually stored in any variables anywhere. There may be a ‘refresh’ button that lets us reload the data from the service. However, the values in the textboxes will not automatically update if there’s a change server-side.

Suppose we now want to add another screen that uses that data in some calculations. Where does the second screen get the data from? If it goes back to middle-tier service the data may be out of sync with the data displayed in the screen. Should it go to the screen itself?

Model-View-Controller (MVC)

The traditional solution to this problem is to use the Model-View-Controller pattern (MVC).

MVC dictates that we have three classes for user interface display:

1. A Model class contains the data to be displayed. This can be a simple data cache, although it may be a full domain model (classes containing data plus associated business functionality).
2. A View class that contains the screen code. This would be a user control or form in .Net.
3. A Controller class that provides the glue between the Model and the View. This class is a little more difficult to understand than the other two. The idea is that the Controller handles all user input, which means events raised in response to user actions (e.g. clicking a button, changing a value in a textbox etc.). It then updates the Model as necessary.

Note that the Controller does not update the View. It updates the Model. If necessary the Model will then raise an event saying that it has changed. The View will subscribe to this event and redraw itself, getting the new data directly from the Model. Note that this is the Observer design pattern: the View(s) observe the Model.

In its purest form the View class should ONLY contain code that draws to the screen: it shouldn’t contain any event handling code for user events, all of which should be in the Controller. This isn’t actually possible with a .Net user control of course, where your event handlers have to be in the code behind the user control (the View). We can achieve the same effect by immediately calling the Controller from the View in the event handler. This means the View will have to have a reference to the Controller, which isn’t the case in the ‘pure’ MVC pattern (see below).

Class Interaction in Model-View-Controller

These classes should have references to each other as shown in the diagram below:

The solid arrows above represent references between classes through which direct method calls can be made.

The View class will have a reference to the Model to allow it to directly request the data it needs to display (A).

The Controller will have a reference to the Model because it will need to manipulate it in response to user actions (B). The Controller also has a reference to the View because it may need to retrieve values that have been changed in order to manipulate the Model in an appropriate way (C).

Note however that the Controller will not update the View directly. The View itself will go to the Model to actually get the data.

The dotted lines above represent an indirect relationship where events can be raised from one class into the other. So the Model may raise events when its data changes, which the View will sink and update any display depending on that data (D).

Note that the Model has no direct reference to the other two classes: it is independent of any Views or Controllers.

Use Case Examples

It can be difficult to understand exactly how this fits together when we see it for the first time. In particular what the Controller does can be confusing.

To clarify this here is a use case example:

• A user interacts with a screen displaying data (which is the View). Suppose that they change some base data and hit an Update button. Further suppose that they expect some derived data on the screen to change as a result of this action.
• The click event for the Update button gets raised in the Controller. A parameter to the event may be the data that needs to be saved (otherwise the Controller can go back to the View to get it). The Controller takes the changed data and updates the Model for the changes. This will include updating any derived data.
• The Model raises an event that it has changed.
• The View will sink the event and redraw itself based on the new data. This means that the correct derived data will now be displayed.
• The system waits for further user input when the cycle above will be repeated.

Solving the Data Caching Problem

MVC gives a solution to the data cache problem outlined above. We have separated the data for our screen into a Model class. Any other screen that needs to display the same data can access the same Model class (using its own Controller). The textboxes on the screens are effectively just views of this data whenever they are displayed.

As a result if the data changes it should only need to be changed in the one place (the Model) for the individual screens to be able to use it. What’s more, because the Model raises an event when the data changes, ALL we need do is change the data in the Model and all the screens will automatically update. If we change a value in a textbox on one screen it should update on any other screens via the process described in ‘Use Case Examples’ above.

Note that this means that one Model can be associated with multiple Views and Controllers. However, it is usual to have a one-to-one mapping between Views and Controllers: each View will have its own unique Controller class.

‘Pure’ Model-View-Controller

The Model-View-Controller pattern described in this article is one that could be used with modern programming languages such as .Net. The description here is what is usually meant by ‘MVC’ these days. However, MVC as described here differs slightly from the original pure MVC design. This article has already mentioned the fact that the Controller should directly handle all events raised by the user from the user interface, something that isn’t possible in .Net. There’s one other fairly major difference with the pure MVC pattern.

MVC originated with early Smalltalk which was a very different language from modern user interface languages like .Net or Java. For a detailed look at the history of MVC (and of MVP) see Martin Fowler’s article ‘GUI Architectures’.

In the original Smalltalk design every single control (textbox, button, etc.) would have its OWN View and Controller class, and the screen they were on would have a top-level View and Controller that would handle putting them all together. This was because Smalltalk didn’t have draggable user interface controls in the way we do today, so writing a user interface was a somewhat different proposition.

Clearly we could do this in a modern programming language such as .Net, but it would arguably make our code less clear rather than clearer.

Active and Passive Model-View-Controller

MVC as described here is ‘active’ MVC. This means that, as we have seen, if the Model changes all Views will be updated automatically via the eventing mechanism.

It is also possible to set up ‘passive’ MVC. This is a slightly simpler pattern where the Model does not raise an event when it changes, and consequently the View cannot update itself ‘automatically’. Instead the View is updated when the user next requests it (by pressing a ‘Refresh’ button for instance). At this time the View will go to the Model and get the new data.

Advantages of Model-View-Controller

MVC obviously has the advantage that for complex screen logic we get clearer code, which should be easier to maintain. In theory this pattern also makes it easier for us to replace the user interface itself, since only screen logic is in the screen.

MVC also provides an easy way of allowing multiple views of the same data to always be synchronized (via the event mechanism).

Disadvantages of Model-View-Controller

Of course, there’s one obvious argument against using MVC for every single screen in a system: it’s a fairly complex pattern, and for very simple screens may simply mean we create three classes where we only need one. Also you clearly have to learn the pattern to be able to use it effectively, which is an overhead.

MVC also suffers from the same problem that all eventing mechanisms have: it can be hard to debug. When the Model fires an event saying it has changed it may not be immediately obvious where this event is being sunk, and finding out in order to debug the code may be tricky.

However, the biggest problem with MVC is that it doesn’t actually solve all of the issues involved in the original problem described in this article. There are multiple reasons why we might have too much code behind our screens, and for some of these it’s not clear how MVC helps us. For this we may need a slightly different pattern, which might be the Model-View-Presenter pattern the SCSF gives us.

This will be discussed at greater length in part 23 of this series of articles.

Conclusion

Model-View-Controller is a pattern that can be used to structure the code in a user interface in a logical way, and prevent too much code being in the screen class itself. In particular it splits the data for a screen into a separate class.

However, it doesn’t solve all our user interface coding problems as we shall see in the part 23 of this series of articles. For this reason it’s not all that common in modern .Net applications.

References

Martin Fowler on MVC and MVP
http://www.martinfowler.com/eaaDev/uiArchs.html

MVC was originally designed for Smalltalk
http://st-www.cs.uiuc.edu/users/smarch/st-docs/mvc.html

Microsoft on MVC
http://msdn2.microsoft.com/en-us/library/ms978748.aspx

Table of Contents: Introduction to using Financial Products Markup Language (FpML) with Microsoft .NET Tools

Part 1 Introduction

An overview of how we can use Visual Studio to examine the FpML XSDs. Shows how to create a Visual Studio project containing the FpML schemas, and how to use that to navigate through them. Also shows how to validate the XML examples that are provided in the FpML download, both using Visual Studio and in C# code.

Part 2 How FpML Validates A Basic Trade Document

Looks at the structure of an FpML trade document in some detail. Explains how the FpML schemas fit together to validate such a document, and examines the use of base and extension types, and of substitution groups, in the XSDs.

Part 3 Generating .Net Classes From The FpML XSD Schema

Shows how to generate .Net classes in C# from the XML schema documents using Xsd.exe.  Explains how to load data into these classes from an FpML document using C# code, and to save the document back out again from the classes.

Part 4 Problems With Using Xsd.exe To Generate .Net Classes From The FpML XSD Schema

Goes through some of the problems with the C# code generated in part 3, and discusses how to fix them.

Problems with Using xsd.exe to Generate .NET Classes from the FpML XSD Schema (Introduction to using FpML with .NET Tools Part 4)

Introduction

Part 3 of this series of articles showed how we can generate .NET classes from the FpML XSD schema using xsd.exe. It showed how we can then use standard .NET serialization syntax to populate the classes from FpML documents, and vice versa.

However, as mentioned in part 3, xsd.exe generates buggy code when used with the FpML XSDs. This article will go through some of the problems with this code and describe how to fix them.

Corrected .NET Classes

Corrected generated classes, which are the end result of the work in this article, are available. This code has been corrected such that it appears to work in most circumstances. However we cannot be certain that it is free of all bugs.

The corrected code is based on FpML 4.2. The main aim of this article is to give you a starting point if you are trying to generate .NET code from other versions of the specification.

Please note also that this article was written using the xsd.exe supplied with Visual Studio 2005 Service Pack 1. Different versions of Visual Studio, or Visual Studio 2005 without the service pack applied, may give different results. See the discussion in the Comments for this article for more details.

Generating the Code

Part 3 of this series of articles described how to use xsd.exe to generate C# code from the FpML schemas. This gave us a file called fpml-main-4-2_xmldsig-core-schema.cs, which contains a Document class which should be the root class for our serialization. Unfortunately if we attempt to create an XmlSerializer object using this code we get exceptions.

Problem 1: Substitution Groups and Extension

The most fundamental problem with our generated code is that xsd.exe has got confused about the substitution groups and associated extension that were discussed in some detail in part 2 of this series of articles.

In particular it has not decorated the Product property of our Trade class correctly to allow it to deal with all the possible products correctly.

In part 2 we saw that the product element in the FpML is replaced with various individual product types using the substitutionGroup syntax. The product element is a sub-element of the trade element in the XML. As a result in our C# code we have a Trade class which contains a data member of type Product and a public property that gets and sets this. Excerpts from our generated code are as below:

[System.CodeDom.Compiler.GeneratedCodeAttribute("xsd", "2.0.50727.42")]
[System.SerializableAttribute()]
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.ComponentModel.DesignerCategoryAttribute("code")]
[System.Xml.Serialization.XmlTypeAttribute(Namespace="http://www.fpml.org/2005/FpML-4-2")]
public partial class Trade {
 
    private Product productField;
 
    public Product product {
        get {
            return this.productField;
        }
        set {
            this.productField = value;
        }
    }

The problem with this code is that, as we saw in part 2, we need to be able to put a Swap object (for example) in to our Product data member. We have a Swap class in our code, and this inherits Product, as we’d expect. So we can store a Swap object in our Product data member.

However, .NET doesn’t know how to serialize or deserialize a swap element in the XML into our product property without being told. In particular, if the deserializer finds an element called ‘swap’ where it’s expecting ‘product’ it doesn’t know that it should deserialize into a Swap object. As we saw in part 2, in ird_ex01_vanilla_swap.xml there is a ‘swap’ element where you might expect a ‘product’ element.

This is very easily fixed in this case. We simply decorate the Product property with an XmlElementAttribute that tells the serializer what to do:

    [System.Xml.Serialization.XmlElementAttribute("swap", typeof(Swap))]
    public Product product {
        get {
            return this.productField;
        }
        set {
            this.productField = value;
        }
    }

This does solve the problem for swap. However, there are multiple other product types that need the XmlElementAttribute added to Product to get the serialization to work (there are over twenty in fact). Also it turns out that this problem isn’t limited to Product. There are other elements that use the substitution group and extension property in this way and have the same problem

At first glance it appears there is no easy solution to this: we are going to have to go through all the possible places where there might be errors and correct the code by hand. However, there’s a much easier solution.

Problem 1 Solution

For simple examples of this problem xsd.exe will correctly generate the required XmlElementAttribute. It’s not immediately obvious why it fails to do so with the full FpML schemas.

It turns out that the reason xsd.exe gets this wrong is because the FpML schemas are spread across multiple files. If we create one big xsd file containing all of the FpML schema files and then run xsd.exe on this the problem goes away. I’ll leave you to draw your own conclusions about the quality of the xsd.exe code.

So to fix the problem we can cut and paste all of the FpML xsd files into one file, removing the include statements that become redundant. An example of this is available. We then use xsd.exe as described in part 3 to create our C# classes.

Problem 2: RoutingIds

If we fix problem 1 as above, we still get an error when we try to create our XmlSerializer object. The error message says ‘Connot convert type ‘RoutingId[]’ to ‘RoutingId’’.

This exception arises because xsd.exe has got an XmlArrayItemAttribute wrong in class RoutingIdsAndExplicitDetails. The generated code for the routingIds property in this class is as below:

    [System.Xml.Serialization.XmlArrayItemAttribute("routingId", typeof(RoutingId), IsNullable=false)]
    public RoutingId[][] routingIds {
        get {
            return this.routingIdsField;
        }
        set {
            this.routingIdsField = value;
        }
    }

The XmlArrayItemAttribute says that the property relates to an array of type RoutingId. However, the property (correctly) is of type RoutingId[][] which is an array of arrays of type RoutingId. So the XmlArrayItemAttribute should be changed as below:

    [System.Xml.Serialization.XmlArrayItemAttribute("routingId", typeof(RoutingId[]), IsNullable=false)]
    public RoutingId[][] routingIds {
        get {
            return this.routingIdsField;
        }
        set {
            this.routingIdsField = value;
        }
    }

Testing the Generated Classes

The two fixes above appear to make the generated classes work correctly. With these changes we can deserialize our ird_ex01_vanilla_swap.xml FpML document into the classes. We can then serialize it back into XML, and we end up with the same document we started. We saw this in one of our code examples from part 3. It’s not easy to test this code is working in all cases however. One approach is to take all the sample FpML files provided with the FpML download and attempt to deserialize them and reserialize them. The code is working if the final document is the same as the original one.

Testing Program

A testing program that does this is available. This contains the code we have seen before (in part 3) for serialization and deserialization.

It also contains a basic class for comparing the original and final FpML documents and outputting any differences. It does this simply by iterating through the lines in the two files and comparing them. This may not be the best way to do this as it is quite difficult with XML.

It is difficult because there can be valid differences between the files that are hard to deal with. For example we have a ‘difference’ where the original line is:

<hourMinuteTime>09:00:00</hourMinuteTime>

After deserialization and reserialization this becomes:

<hourMinuteTime>09:00:00.0000000+00:00</hourMinuteTime>

These are clearly the same thing but our file comparer has to be able to deal with it. It does so in a very basic way by hard-coding such differences to be ignored in method ‘CompareLines’.

Extent of Testing of Generated Code

Because of the difficulties described above the testing program has only been used to test that the generated code works with the interest rate derivatives and credit derivatives sample files.

Usefulness of Generated Classes

In the last two articles we have demonstrated that we can generate C# classes based on the FpML XSD specification, and with a little work can deserialize FpML documents into this object model, manipulate the objects, and serialize back into FpML.

However, my personal opinion is that we need to think carefully as to whether we want to use these classes. FpML has a very hierarchical structure, and as a result in the generated code we have very many classes interacting to represent even a simple trade. Our object model is not very easy to understand or use as a result.

For example, suppose we want to change the notional on the fixed leg of our interest rate swap (ird_ex01_vanilla_swap.xml) once we have it in the object model. Starting with the top-level Document object that we have deserialized, the syntax is as below:

        private void ChangeNotional(Document document)
        {
            DataDocument dataDocument = (DataDocument)document;
            Trade trade = (Trade)dataDocument.Items[0];
            Swap swap = (Swap)trade.Item;
            InterestRateStream interestRateStream0 = swap.swapStream[0];
            InterestRateStream interestRateStream1 = swap.swapStream[1];
            Calculation calculation1 = (Calculation)interestRateStream1.calculationPeriodAmount.Item;
            Notional notional = (Notional)calculation1.Item;
            notional.notionalStepSchedule.initialValue = 1000000;
        }

In fact, I don’t think this routine is complex enough, since it should really check which of interestRateStream0 and interestRateStream1 is the fixed leg.

A code example incorporating this code is available.

It’s hard to argue that this code is straightforward: for instance we have a number of ‘Item’ properties referenced that can be of various types. We have to know which type we want. In addition we have the issue that we are not entirely sure that the code generated by xsd.exe is free of bugs, even after the work we have done to patch it up.

As a result in a current project I am working on we have decided not to use the classes generated by xsd.exe, but instead to deserialize into flatter structures of our own design.

Conclusion

This article has shown that it is possible to fix the code generated by xsd.exe from the FpML schemas such that we can deserialize/serialize FpML documents into/out of the object model. We have also shown that it is difficult to test that this will work correctly in all cases, and that the resulting object model is not all that easy to use.

Licensing of FpML Specifications

The FpML Specifications of this document are subject to the FpML Public License (the “License”); you may not use the FpML Specifications except in compliance with the License. You may obtain a copy of the License at http://www.FpML.org.
The FpML Specifications distributed under the License are distributed on an “AS IS” basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License for the specific language governing rights and limitations under the License.
The Licensor of the FpML Specifications is the International Swaps and Derivatives Association, Inc. All Rights Reserved.

http://www.fpml.org/documents/license.html