A (somewhat) new approach to application development

I am excited about Silverlight 1.1 – very excited! Whilst all the graphics and animations will be a wonder for creating great user experiences, I eagerly awaiting the chance to run managed code in the browser.

In my mind, and partially in code, I have already begun to formulate a new way to design applications. Of course, by new I really mean stealing a bunch of existing good ideas and gluing them together!

The first key idea is putting the users first – always. These auto-magic, drag-n-drop data binding tools are great for quick and dirty CRUD applications, but I am yet to see one produce an application that has great usability. We need to start by putting ourselves in the user’s position and thinking about why they are using our software in the first place. It is all about finding the simplest, cleanest, more beautiful way to enable the user to get their job done. Slapping another data grid on a page probably is the worst approach!

I am a new convert to the Model-View-Presenter way of writing client applications. Although, I think, the order of coding should be Presenter-View-Model (it does not have quite the same ring to it however). In addition, by View I mean the view implementation, not the UI design. I always sketch the view design on paper/white board first. I suppose using a tool like Microsoft Expression Blend would be OK as long as you are not precious about the XAML it creates. I am never afraid to throw out code and start afresh, so why should UI mark-up be any different? Use whatever tools you find easiest to knock up UI prototypes and shove them under the user’s nose. The key here is to know roughly what buttons, textboxes, etc, the UI will contain (we can leave all the fancy colouring in to some guy in a turtle neck). Once this is the case, we can begin the most important part of the coding: The User Interaction Logic (UIL).

The UIL is the Presenter. The UIL says stuff like when the user clicks this button, read this data from the UI, tell the underlying model to do something and then tell the view to update. Whilst for some applications this level of control may seem like overkill, I argue that having to slow down sometimes is OK. This approach means you have to think about what the user will be doing in your application.

The best way to develop this code is by being test-driven. Create unit tests that describe the behaviour of the Presenter in terms of how it interacts with View and Model object-oriented interfaces. Each user story then becomes testable.

Key tools I plan to use here are:

Rhino Mocks – to create mock objects of Views and Models

Boo + my Rhino Mocks DSL – to make the unit tests easy to read and write

SharpDevelop – because Boo is not readily usable in Visual Studio yet

Visual Studio 2008 – to write the implementation of the Presenter in C#

As awesome as the language Boo is, I just cannot stand SharpDevelop for more than simple projects like the unit tests. Refactoring, intellisense and code-completion are just way to well done in Visual Studio to ignore it. I have enough memory and screen space to run VS and SD side-by-side.

As the Presenter is written, the interfaces for the View and Model are being fleshed out. The refactoring tool adding the methods automatically to the interfaces usually does this.

The choice now is whether to develop the Model or the View next. The View is a very dumb object that simply maps data to and from the UI and raises events when the user does stuff (clicks, key presses, etc). Since Silverlight does not have data binding yet, this may lead to somewhat tedious code. Bear in mind also that the Presenter is meant to be doing tasks such as converting strings into numbers and back. However, I reckon a tool can generate most of the standard mapping code.

The declarative nature of XAML means it should be easy to add attributes to button elements that describe the event they should raise when clicked. A tool could scan this data and write the code for me.

If data binding was ever added to Silverlight, I would consider creating pure “data” objects that the Presenter tells the View to bind too. No logic would be contained within the data objects.

The Model is where things become more interesting from a software architecture point of view. Silverlight runs in the client’s web browser. So the Presenter is running client-side, as is the Model on which is depends. The Model is maintaining state about the client application. For example, which check boxes are checked, which customer is selected? However, the Model also will need to communicate with a database running back on the server to read and write data.

To solve this problem, I plan to use my tier splitting C# macro. I will write the Model class as one coherent class. By coherent I mean all the data is there and all the logic regarding the data is there. I do not believe manually splitting the class and messing about with proxies and web services makes any business sense. I am not developing some kind of SOA application that is to be called by numerous different clients. I am trying to get my Model to save its valuable data on the database that is only accessible from the web server from whence it came. This is a reasonable tight coupling between the client and server versions of the Model. The coupling is so tight; I argue that I do not even want to see it!

In the case where the data does come from a remote web service, we still have to return to the application’s home server since Silverlight disallows cross-domain calls. It makes sense to put any database calls/remote web services calls into the Model. The Model knows what data it needs, so why bother moving that knowledge outside of the class only to marshal all the data back in again.

With LINQ being available we do not even have to pollute the Model with database specific SQL.

The tier splitting macro will handle generating all the WCF services and proxies. I just have to decorate the Model’s remote methods with [RunAtServer].

Thorough unit testing of the Model is required. It should be possible to create a mock D-LINQ implementation. I can then make assertions about how the Model interacts with the data layer.

In summary, I want to have a Silverlight UI that is but a marionette to a Presenter running client-side. This presenter has complete unit testing to describe the different user interactions. The Presenter uses a Model object to store all data. This Model exists on both the client and server side. However, the split implementation is effectively invisible to the developer.

The application of adequate tooling (both 3^rd party and custom made) will make this an excellent way to approach writing applications. As Silverlight 1.1 becomes more complete, I will continue to expand this topic.

The result should be a happier developer and, more importantly, a happier user.

Tuesday, August 14, 2007 1:02:43 PM (GMT Standard Time, UTC+00:00)      Comments [0]  .net | boo | c# | dsl | programming | rhino_mocks | ria | silverlight | tier_split

Tier Splitting C# Classes

When developing a Model for an MVP architecture it needs at some point to access the database to read and write data. When this model is running on the client-side (in Silverlight for example) it has no access to the database. I suppose the standard solution here is to put the data access code in a separate class running on the server. The client then invokes this service passing the data required.

The approach obviously works, but I don't like it. The Model contains all the data relevant to the business problem. It has the validation logic for the data. Why do I need to suddenly create an entirely different service just to read and write to the database? Now with LINQ there are no code-level ties to a particular database technology.

The Model should be in charge of telling the database what data it needs, reading the data and storing into its fields. When saving data the Model should tell the database what query to execute to save the data.

The root of the problem here is that the Model needs to be split between the client and server sides. However, I want this to be done in such a way that the developer is not wading through plumbing and service layers. In essence, I want this:

[DataContract]
public class Model : IModel
{
  [DataMember] public string CustomerName { get; set; }
  [DataMember] public decimal InvoiceAmount { get; set; }
  [RunAtServer]
  public void Load(int id)
  {
    // Access database here. Get data. Save into properties.
  }
}

This needs to generate two Model classes, one for the server (which is basically the same as above) and one for the client that replaces the [RunAtServer] methods with calls to a service object.

I have this working! :) I have used my C# macro tool to take the above code and generate a new file that contains the two Models, a WCF service and client proxy. These classes are surrounded by "#IF SERVER" and "#IF !SERVER". I then have a WCF service project and Client project that both compile the generated file. The conditional preprocessor directives mean each project only gets what it needs.

This is all still prototype-level code, but it does work. I am waiting on Silverlight 1.1 to have better support for WCF, so for now I'm using XBAPs to test. However, there is nothing stopping me using WinForms for the client as well. I see this as being a great way to write rich internet applications. I can focus on modelling the business problem and just decorate any methods that need to be remote with an attribute.

Wednesday, August 08, 2007 12:17:48 PM (GMT Standard Time, UTC+00:00)      Comments [0]  .net | c# | programming | tier_split | ria

C# Syntactic Macros

After a late night hacking session, I finally have a working syntactic macro system for C#! It is comprised of a VS custom tool that uses the CSparser. The end result allows me to do this:

using System;
[Macro(AutoClass)]
public interface IModel
{
  string FirstName { get; set; }
  string Surname { get; set; }
  int ID { get; }
  event EventHandler FirstNameChanged;
  event EventHandler SurnameChanged;
}

The CustomTool property of the IModel.cs file is set to "MacroExpander" and the Build action is set to None. This then generates a new file "under" the source file, called for example "IModel.generated.cs". This generated file contains the original interface (minus the bogus attribute) and a new class called "Model" that provides a stanard implementation of IModel. It includes private fields, a constructor, properties, events and event raising methods. The class is partial so you can still create a file called "Model.cs" alongside the interface and implement any methods. In addition, if you enter implementations of the interface properties/events in Model.cs then the generated class will not contain them. So it is easy to generate the 80% of standard members and custom write the others as required.

The sharp-minded out there will note that "AutoClass" is a parameter passed to the Macro attribute. The expansion process is able to load any IMacro implementation I care to write. The macro implementation is handed the parsed source tree and allowed to modify it as required. After all macros have expanded, the source tree is converted back to CS source text and outputted from the VS custom tool. This generated file is compiled by VS as usual.

I'm going to start using this AutoClass macro to generate most of my Model code (in the Model-View-Presenter architecture). Anywhere else I need code generation at this level I can create more macros easily.

If people are interested in seeing this product released in some way please get in contact. I will perhaps get a screen cast made up to show it in action.

Tuesday, July 31, 2007 12:04:41 PM (GMT Standard Time, UTC+00:00)      Comments [5]  .net | programming | c#

C# Code Generation

I came across http://www.codeplex.com/csparser today. This parser takes C# source code and produces in memory object tree representing the code. This object tree can be modified and the resulting source code extracted back out as a string.

I have been thinking about ways to remove the mindless plumbing code I have to write when implementing a Model-View-Presenter architectural system. For example, I define an interface for my Model. I then make a Model class that implements the Model interface. The slow bit here is implementing all the properties with fields, defining events and the OnSomeEventHappened(Args) methods to safely raise them.

Whilst there are tools that will probably do this plumbing for me, they have one flaw. I don't want to even read, let alone write, that boiler-plate code! It does not help me understand what it going on. The interface contains all the important details. I basically want the compiler to generate it for me.

C# has no syntactic macro system (unlike Boo and Nemerle) so I'm stuck with my current XML/XSLT based code generator. Whilst this is usable, it really means I'm no longer coding in C#, but rather long-winded XML. The context switch there is a bit annoying.

With the CS Parser I will be able to the following:
Write a Visual Studio Custom Tool (like my XML/XSLT code generator) that takes C# code file of an interface and generates an implementing class. This is done by parsing the interface definition, then looping through members and creating a new class definition accordingly.
If the class already partially exists I can allow the user to type specific members they need to implement in a non-standard way and not generate these automatically.
The output of the Custom Tool (new C# code) is then compiled automatically as part of the Visual Studio build process.

For example:

public interface IModel
{
  int Amount { get; set; }
  event EventHandler AmountChanged;
  void Load();
}

Generates into:

public partial class Model : IModel
{
  int _amount;
  public int Amount
  {
    get { return _amount; }
    set
    {
      _amount = value;
      OnAmountChanged();
    }
  }
  public event EventHandler AmountChanged;
  protected virtual void OnAmountChanged(EventArgs e)
  {
    EventHandler handler = AmountChanged;
    if (handler != null)
       handler(this, e);
  }
}

Leaving the developer just to write the Load method.

I'm wondering about generalising this a bit. Using magic attributes that are picked up by a tool (much like syntactic macro attributes in Nemerle) to invoke specific actions.

[AutoImplement(IModel)]
public class Model : IModel
{
   public void Load() { ... }
}

Fun times ahead!!

Thursday, July 26, 2007 4:47:58 PM (GMT Standard Time, UTC+00:00)      Comments [1]  

Moving to Bristol

Sorry, this not technically "about code", but I'm moving to Bristol on the 27th July. I'm moving into a new flat and am looking forward to working and playing in Bristol!

Hopefully I'll get lots of work done ;)

Monday, July 16, 2007 6:53:33 PM (GMT Standard Time, UTC+00:00)      Comments [0]  

Splitting Objects Across Tiers

Erik Meijer is involved in some very interesting research at Microsoft Research. This latest video on Channel 9 introduces the work his team are doing to make writing an application a single concept and then splitting it over tiers as required.

He talks about using a refactoring to split a class out into different parts for required tiers. For example, a model running on a client needs to talk to a database at some point. That part of the code needs to be running in a context that can access the database i.e. the server. The refactoring generates a service class that contains the database access code, and the client class is updated to call the service.

Apparently they are working to make this declarative. I imagine this looking something like:

[RunAtServer] void MyMethod(int id) 
{
  var people = from p in DB.GetPeople() where p.ID = id select p.Name;
  // etc...
}

Of course, the "macro" siren went off in my head. I could probably do something like this today in Boo or Nemerle. For making close-coupled systems (where data types are shared between tiers) this could be amazing. All we need is an assembly level macro that scans class for certain attributes and auto generates the required services, proxies and proxy calls.

When you have .NET running everywhere (i.e. Silverlight in the browser) this kind of magic becomes more of a reality. I'm also very interested to see the MSIL to JavaScript compiler Erik is working on.

Friday, July 13, 2007 10:22:55 PM (GMT Standard Time, UTC+00:00)      Comments [0]  

The Right Amount of Code Generation

David Hayen talks about the problem of using code generation at a large scale within software projects. The first use gives a lovely RAD hit, but over time you get more constrained and limited by the generated code. I always found this problem using any kind of data-n-drop data binding (although .NET 2.0 windows forms data binding seems almost flexible enough).

It is hard to get large scale code generation perfect - almost impossible in reality. I find using code generation at a smaller scale to actually raise the level of abstraction in code more useful. Languages such as Boo and Ruby have great syntax for defining mini domain specific languages to raise abstraction levels. Syntactic macros in Nemerle and Lisp are true compile-time code generators. The key to these methods is that the programmer has not lost the expressivity his language gives him. If a certain macro is not really fitting, you can always write out the code long-hand and refactor later if necessary.

Large scale code generation assumes software is smooth and regular. In the real-world we have to deal with special cases and, worse, changing requirements. Trying to make a code generation tool fit all of these requires it to be as expressive as a real programming language! Only now we are buried in stacks of XML config files and templates.

One area I do see a benefit for these quick-n-dirty code generators is in prototyping. You want to get something half-real in front of customers quickly to gather feedback. However, never be precious about your code. The best writing is re-writing! A lot of software hangs around for a lot longer than we expect, or even hope. It is probably best to make it as maintainable as humanly possible.

The fact that a magic tool generated thousands of lines of code for you doesn't stop them for existing. The more code that exists, more chance there is for something to be wrong. If your chosen programming language requires you to write reams of code to express something that you can conceptualise more simply, then I'm sorry you need a better language.

Sunday, July 08, 2007 12:03:08 AM (GMT Standard Time, UTC+00:00)      Comments [0]  programming | thinking

Code for the Rhino Mock DSL

I have attached the Boo code containing the Rhino Mocks DSL I'm currently working on. This is very much a work in progress release, just to get it out there. Please have a play and tell me what you think. Happy Mocking!

Dsl.boo (3.4 KB)

To use the DSL, add the following in your code to import the static methods into scope.

import Rhino.Mocks.Dsl

Friday, July 06, 2007 12:19:48 PM (GMT Standard Time, UTC+00:00)      Comments [2]  .net | boo | dsl | mock_objects | programming | rhino_mocks