I am finally fed up of having to install Microsoft Money and set up syncing of the data file, so I’ve decided to try and build a web based version. Mint.com does not support non-US markets and apparently does not even support adding your own transactions that have not been downloaded from a bank. “Private Money” is the codename and it looks a bit like this at the moment:
- ASP.NET MVC 3 as the application framework
- Entity Framework 4.1 for ORM
- NInject for a modular design with dependency injection
- MigratorDotNet for database versioning with some tweaks to get it to work over different modules
I am planning on replicating the parts of MS Money that I use the most, mainly the transaction logging, reports and cashflow chart (which should be fun to make on a canvas element). Visually I am going for the Windows Live/Metro motif.
Microsoft have now released an update to ASP.NET MVC3 imaginatively called “ASP.NET MVC3 Update”. This update upgrades NuGet, bundles Entity Framework 4.1 with all new templates, adds HTML5 template support and splits the jQuery libraries off into NuGet packages so they can be upgraded individually.
The bundling with new MVC projects is a sign that Microsoft has selected Entity Framework as the “chosen” ORM layer from now on. Linq2SQL is not flexible enough when dealing with pre-existing database schemas and third party solutions such NHibernate are difficult to get pointy-haired boss approval. EF 4.1 adds “code first” support where you define a very simple CLR object and it will automatically create the database tables for you. At first your eyes will light up thinking “finally! Rails’ ActiveRecord for .NET! Blessed by Microsoft!” until you find several missing pieces:
- No migration support. The only option that EF provides when the “code first” objects behind your schema change (for instance, you add a new property) is to drop the entire database and start again. Rails has had this for years.
- No code first support on real databases. That’s right, code first only works on SQL Compact file-based databases. This is fine for development but you can forget about just dropping the files onto a clients webserver and have it create your database for you.
There are a couple of ways around the limitations. I am having great success with a combination of MigratorDotNet and Entity Framework to provide an ActiveRecord style schema migration path. Hopefully I can write about this soon.
Just to hammer the point home about how important it is to upgrade to .NET 4.0 if you are using WPF, here are some comparison screenshots of the text rendering in WPF 3.5 and 4.0:
Pay attention to the difference between the text rendering on lines 2 and 3.
Line 2 shows the new Display formatting mode available in WPF 4.0. This renders the text the same way as the rest of Windows – the shape of the font is distorted so that lines fall on pixel boundaries. For small text this should be used for consistency with the rest of Windows or users will most likely complain that your text looks “blurry” (even though it is technically rendered correctly). Large font sizes or high DPI screens can stick to the standard WPF rendering mode.
Line 3 shows what Japanese Windows XP users will see if they use your application as they don’t have Meiryo installed. In WPF 3.5, Asian text is a mess at small font sizes because WPF 3.5 does not support bitmap fonts – instead it scales down the large vector font data in the font file. WPF 4.0 supports bitmap fonts so that Japanese text now is rendered the same way as the rest of Japanese XP.
It is worth being reminded that it took Microsoft themselves to dogfood WPF 4.0 when developing Visual Studio 2010 before these problems were solved.