Posts in category .net - page 17

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 option mentioned which perhaps solves this, I shall have to investigate it further.

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.


Web Application Security for Developers presentation

Last nights Guernsey Software Developers Forum meeting was sparsely attended with a number of the regulars attendees absent. There were however two new faces including Kezzer who I’d been chatting to on-line for years.

Hopefully the low numbers were down to the seasonal summer holidays and the subsequent knock-on effect that we couldn’t get email out to the BCS Guernsey division to gather sufficient awareness.

I did a short presentation on Web Application Security for Developers that covered HTML injection, SQL injection and cross-site scripting including some live demonstrations on sample code. Slides and sample are available although without audio or screen cast of the demonstrations until I work out how to do that with Keynote.


I’ve come to the conclusion that putting presentations together takes me around 1 hour of preparation to 1 minute of presentation…


Multiple-inheritance, composition and single responsibility principle in .NET

.NET is often chided by C++ developers for failing to support multiple-inheritance. The reply is often Favor object composition over class inheritance – a mantra chanted from everywhere including the opening chapters of the Gang of Four’s Design Patterns book.

If the accepted mantra is that your object should expose interfaces and delegate the implementation of those interfaces elsewhere then it could really do with some better support than .NET currently offers especially where the interface comprises more than a member or two.

Consider the following fragment of a class for customer price-lists (properties and methods omitted). We decide to support IList so that consumers of our class can add, remove and iterate over the prices in a familiar manner (principle of least surprise).

public class CustomerPriceList : IList<ProductPrice> {
    private List<ProductPrice> productPrices = new List<ProductPrice>();
    public Customer Customer;

Implement interface

Visual Studio offers some assistance where you can choose Implement interface _IList_ which gives you all the method definitions with the very unhelpful body of throwing an exception of “This method or operation is not implemented”. It requires some work to fill in all these definitions to something that works:

public class CustomerPriceList : IList<ProductPrice> {
    private  List<ProductPrice> productPrices = new  List<ProductPrice>();
    public  Customer Customer;

    public int IndexOf(ProductPrice item) {
        return productPrices.IndexOf(item);

    public void Insert(int index, ProductPrice item) {
        productPrices.Insert(index, item);

    public void RemoveAt(int index) {

    public ProductPrice this[int index] {
        get { return productPrices[index]; }
        set { productPrices[index] = value; }

    public void Add(ProductPrice item) {

    public void Clear() {

    public bool Contains(ProductPrice item) {
        return productPrices.Contains(item);

    public void CopyTo(ProductPrice[] array, int arrayIndex) {
        productPrices.CopyTo(array, arrayIndex);

    public int Count { get { return productPrices.Count; } }

    public bool IsReadOnly { get { return ((IList)productPrices).IsReadOnly; } }

    public bool Remove(ProductPrice item) {
        return productPrices.Remove(item);

    public IEnumerator<ProductPrice> GetEnumerator() {
        return productPrices.GetEnumerator();

    IEnumerator IEnumerable.GetEnumerator() {
        return ((IEnumerable) productPrices).GetEnumerator();

This is a lot of effort for a cluttered solution.

Use inheritance to subclass List

public class CustomerPriceList : List<ProductPrice> {
  public Customer Customer;

Small amount of code but not an option if you have a class hierarchy in place or need to implement multiple interfaces.

Expose IList property directly

public class CustomerPriceList : IListable<ProductPrice> {
  private List<ProductPrice> productPrices = new List<ProductPrice>();
  public Customer Customer;
  public IList<ProductPrice> ProductPrices { get { return productPrices; } }

This works but means CustomerPriceList can not control any of the IList implementation such as validation.

Methods may also start accepting IList instead of CustomerPriceList because developers imagine the parts to be more decoupled than they actually are and are encouraged to code to interfaces not concrete classes.

Refactoring away from this at a later date would require a IList wrapper than delegated calls back to the containing class to prevent an interface-breaking change.

Introduce interface to declare IList available

Add an interface that signifies a IList can be obtained by calling the named method, e.g.

public interface IListable<T> {
  IList<T> GetList();

This is a similar pattern to that of IEnumerable and IEnumerator whereby one interface signifies the availability of the other. In this example our class would look like:

public class CustomerPriceList : IListable<ProductPrice> {
  private List<ProductPrice> productPrices = new List<ProductPrice>();
  public Customer Customer;
  public IList<ProductPrice> GetList() {
    return productPrices;

Which is less code, a closer adherence to single responsibility principle (SRP) and the ability to change without breaking the interface although it still does nothing to prevent passing IList or IListable interfaces where CustomerPriceList would be more suitable. An IPriceList class could be introduced although it starts to feel like abstract infinity.

Improved support from .NET

I’d really like to see .NET improve on the support for interfaces and composition, like perhaps the following:

public class CustomerPriceList : IList<ProductPrice> goto productPrice {
  private IList<ProductPrice> productPrice = new IList<ProductPrice>();
  public Customer Customer;

This would signify to the compiler that all IList interfaces should be wired up to the productPrice variable unless explicitly defined and gives goto a whole new lease of life ;-)


Typed session data in ASP.NET made easier still

Philippe Leybaert is unimpressed with Microsoft’s Web Client Software Factory approach for typed session data and offers his own Typed session data made (very) easy which still seems overkill to me comprising as it does of generics, a delegate a helper class to achieve the desired effect. (Whilst you are there check out his very interesting MVC project for ASP.NET called ProMesh)

The solution which I have been using since my .NET 1.1 days is much simpler still and involves nothing more than creating a plain class with properties for every session variable and a static get accessor that obtains or creates it on the HttpContext similar to a singleton.

Here’s an example with the important Current property (slightly cleaned up and improved for this post ;-)

public class MySession {
  public string Name;
  public int LoginID;
  public int CustomerID;

  public static MySession Current {
    get {
      MySession currentSession = HttpContext.Current.Session["_session"] as MySession;
      if (currentSession == null) {
        currentSession = new MySession();
        HttpContext.Current.Session["_session"] = currentSession;
      return currentSession;

Using the session data then simply involves operations like:

MySession.Current.Name = NameTextBox.Text;
NameLabel.Text = MySession.Current.Name;

This solution is a lot clearer however all of these solutions use HttpContext.Session which is actually supposed to be there for compatibility with ASP.

Ideally Microsoft would provide us with an option in web.config whereby we can choose our session class and it would just instantiate and track it as part of the session life-cycle.