These are the famous words Martin Sheen opened Apocalypse Now! with. That is an extremely underrated movie. I believe it is Coppola's best movie {incidentally, I love cooking with your wine FFC}. It should be on the short-short list of what is the best movie of all time with Casablanca and Dr. Strangelove.
In short, the mission is to replace an outdated and outmoded FoxPro 7 application with with a nice new shiny .NET application. It is a pretty simple crud app, with reports. Nothing special. So what is my plan of attack? Good question. Since they want a fully modern upgrade, I thought I would cook up the following for them:
- A nice shiny 5th normal form database schema in SQL Server 2008
- Visual Studio 2010
- C# 4.0
- Silverlight 4.0
- Windows Communication Foundation (WCF) data layer
- I am seriously toying with the notion of using net.tcp protocol.
- Reactive Extensions (Rx)
- An MVVM pattern UI application
Of course, everything begins with the database upgrade. The DB upgrade is the sin qua non, it is that without which nothing else is possible. We have to get rid of the DBF files. This needs to become a fully-relational SQL Server 2008 database.
If you want to code in C# 4.0, you better use VS2010, which is the homefield. If you want to write a Silverlight 4.0 database app, you have to be fed by web services of some kind. WCF has garnered high praise from a number of authorities I respect. They believe the architecture has been very well crafted.
The first close-call is whether or not to use the net.tcp extensions to WCF, which are fresh and new in Silverlight 4.0. There are pros an cons to this approach. What are they?
Pros
- Excellent performance
- Duplex communication. The server can initiate a communication to the client.
What are the cons? So far there is just one I know of: You can only operate inside the firewall, in an Intranet environment. This is not good. I was hoping to craft a fully web-borne app for these fellows. I don't think they are looking for such a web-borne app, but this is only because they lack foresight. The whole world is going to a flex-corp architecture where many workers in many places will telecommute to work. They may not know this yet, but in a year or two they will raise the question if I don't provide for it ahead of time.
Think ahead of the power curve.
Now for the Reactive Extensions (Rx) for the .NET Framework. Knowing that Silverlight data apps must be fed through web services of some sort, and knowing that a RIA application like Silverlight allows the end user to drive the process through a series of events, we are placed in a difficult position. All events that do CRUD ops must be asynchronous. You must send away your results, allow the user to continue, and then pickup the results when they are returned.
How then shall we handle this problem in threading on events? Microsoft has constructed a new framework precisely for this problem. It is the Reactive Extensions (Rx). Think of it as Linq to events. You write a Linq like lambda syntax over your event queue saying "from event X to Y do the following". It is very declarative. You don't manage how Rx does things. You tell it what to do, and it figures out how to do it for you.
This is a gold mine. I am excited. This is one of the golden keys to the future. The present is multicore. The future is extremely parallel. This declarative asynchronous event handling methodology will be the future of .NET event based programming.
I pity the VB6 fools who have not yet updated to the present. You will find yourself so outdated, there will be no pathway forward for you into this new world. I know a VB consultant we'll call DP, whose Kung-Fu treachery knows no bounds, who is just such a programmer. He's dead. The future will kill him.
About a year ago, I helped Rico here at work finish up a large scale WPF application. Rico had chosen the MVVM pattern for the interface. It was good. I only regret I came to the project so late, and did so little. I would have been a much better experience if I had learned it from square one.
I learned enough about the pattern to understand that this is the key to avoiding all forms of .NET code behind the WPF form. This is an important goal, and one we should shoot for. Everything should be handled by a XAML trigger which invokes methods on a class implementing ICommand. In this way, you obtain a full separation of skin and CRUD guts. This allows you to construct a fully-skinable app. That is desirable, given how many cosmetic design changes users demand.
Now, the first key design problem is to weld together the MVVM pattern with the Reactive Extensions. It turns out great thinkers have already thought this through. Great minds think alike. The solution is surprising simple.
You implement a base class which implements both the IObservable and the ICommand interface. You can call it an IObservableCommand object. This becomes the base of all CRUD and event handlers in your application. Now isn't that nice?
You can read about it here.
using System;
using System.Windows.Input;
namespace Jesperll
{
class ObservableCommand : Observable, ICommand where T : EventArgs
{
bool ICommand.CanExecute(object parameter)
{
return true;
}
event EventHandler ICommand.CanExecuteChanged
{
add { }
remove { }
}
void ICommand.Execute(object parameter)
{
try
{
OnNext((T)parameter);
}
catch (InvalidCastException e)
{
OnError(e);
}
}
}
}
