Investigating MonoRail
Fighting WinForms
I hate fighting with a technology to get it to do what I want because it means I either have the wrong expectation or wrong technology.
With web development I expect strict web standard support and clean code that is easy to maintain.
I am, therefore, tired of fighting with WebForms and seeing as I’m not prepared to change my expectation then the technology must change.
Looking at MonoRail
Ruby on Rails is very fast, elegant and powerful but comes with a bunch of unknowns. The IDE’s I’ve tried have been so-so, there is no support for IntelliSense so I’m forced to remember exact property and method names. There are concerns about performance and scalability and I find the Ruby language itself cryptic.
My current .NET environment has all these things, so what I’m really looking for is an alternative to the WebForms element itself. It also has a powerful framework, tons of samples, and C# is not only enjoyable but very in-demand :)
MonoRail seems to be just what I am looking for but there are a number of things keeping me away. I decided to spend an hour watching a screen cast on WinForms and MonoRail from Ayende @ Rahien’s blog. It calmed some concerns but raised a few others…
NHibernate mapping files
NHibernate provides the core ORM system within MonoRail and normally requires XML mapping files to do so.
I really don’t want or need another abstraction layer here – my tables are freshly modeled and represent my domain classes very well. Rails, Subsonic and LINQ to SQL are all happy to just do it/
Thankfully a project called ActiveWriter gives you a very LINQ to SQL-like experience in dragging tables off, changing names and properties if you want and doing the magic for you.
ActiveRecord template
I still don’t like this mix of static and instance methods providing some sort of split between what should really be two classes but I can live with it.
There is also a Repository
View engines
There are a number of view engines available for MonoRail but the primary ones are NVelocity and Brail.
As I already have C# and JavaScript in my project and I have no desire to add another language unless there is a good reason to do so. If they want to stop people writing too much view code then what is wrong with a subset of C#?
The template engines also mean giving up strong typing (everything is passed to the view in a type-less property bag accessed with a string key!) and a complete lack of IntelliSense (the demo stalls as fields are mistyped on occasion proving just how useful this is).
HTML injection
Yes, in this day and age HTML injection should be a long-dead concern and yet even the built in SmartGridComponent will happily squirt out data without encoding it and thus allowing data from anywhere to contain HTML ready to be injected into an unsuspecting page.
Ayende has investigated the issue now and is working on getting a fix into the tree.
[)amien
2 responses