Monthly Archives: November 2012

CA2214 & Entity Framework

I’ve just submitted a comment to the CA2214 code analysis guidance. Posting it here just in case others come across this and wonder what they should do.

There are some circumstances where, using Microsoft’s supplied frameworks this is unavoidable. For example, lets say that I am using Entity Framework:

public class Client
{
public Client(string name, User ownedBy)
{
Name = name;
OwnedBy = ownedBy;
}
protected Client()
{
}
public string Name { get; protected set; }
public virtual User OwnedBy { get; protected set; }
}

In order for Entity Framework to lazy load the OwnedBy property it needs to be marked as virtual. However we might want to stop developers constructing the object without providing the minimum mandatory information (in this case a name string, and a User instance who owns the object). When doing this the CA2214 code analysis warning is fired. The simple solution (in theory) is to mark the Client class as sealed, however Entity framework needs a default constructor to call. The way it works is by inheriting from the Client class with a default constructor which points to the protected constructor, thus allowing it to inject the code to traverse lazy loaded properties/collections etc.

I believe that whilst the guidance provided by CA2214 is valuable, it is inappropriate to say “Do not suppress a warning from this rule” because in some cases you might need to do it by design. Given the proliferation of ORM tools which use this approach for lazy loading of properties the guidance should be updated to outline some scenarios where you might want to call a virtual member.

Advertisements

C# 6.0 Suggestions: Quick Review

I’ve just posted four quick posts on three specific enhancements that I would like to see in the C# language.

Obviously I would like to see all of the above features added to the language (after they have been thought through more fully by the language designers). However I do wonder how much further investment there is going to be in C# as a language. If you look at C# 5.0 we basically got async/await (and associated plumbing) and caller info. There was some suggestion that we might get automatic property initializers but that appeared to be scrapped.

Still – the “Roslyn” project does hold some promise in terms of opening up the compiler to allow software developers to transform the syntax of the code prior to compilation thereby supporting the addition of new language features.

Time will tell whether that is a good idea in terms of source code stability because in essence those language tweaks need to be part of source tree just like anything else, otherwise you might snooker yourself if you accidentally lost your Roslyn-based source code transformation add-in.

C# 6.0 Suggestion: Backing Field Type Declaration

This is the third post which expands on two that I have already done tonight. The first was on adding an automatic property initializer syntax to C#, and the second was on adding backing field access from within the property accessors without having to separately specify the backing field.

My next suggested improvement is really just here for the purposes of completeness. Often you want to delay the creation of a backing filed instance until it is accessed. However, if you want to have a backing field which varies in type to the declared property then you need a way to specify the type of the backing field without actually instantiating it. Here is an example of the proposed syntax:

public class Customer
{
  public IEnumerable<Address> Addresses
  {
    get(field)
    {
      if (field == null) field = new Collection<Address>();
      return field;
    }
  } as Collection<Address>();
}

This code is pretty straight-forward. The backing field for the Addresses property is a Collection<Address>, but it is presented as an IEnumerable<Address>, and construction is deferred until it is accessed for the first time.

Potentially the syntax for optional arguments could be “borrowed” here to lead to a more concise syntax:

public class Customer
{
  public IEnumerable<Address> Addresses { get(field = new Customer<Address>()) }
}

In this case the type of the backing field could be inferred, the difference between the two being that the above syntax defers execution of the backing field initialization until the get accessor is called and the example from my automatic property initializer example is executed upon construction.

C# 6.0 Suggestion: Backing Field Access

I just posted on one feature that I would like to see in C# 6.0, automatic property initializers. Another that I would like to see is some kind of reserved word access to the automatic backing properties that are created. This would actually allow for more complex property initializer scenarios without actually having to create the backing field.

public IEnumerable<Address> Addresses
{
get(field)
{
return field.Where(x => x.IsActive);
}
set;
} new Collection<Address>();

This example builds on the automatic property initializer that I have proposed previously but adds a parameter to the get accessor which can then be used to operate against the backing field. The backing field type is determined by the initializer.

C# 6.0 Suggestion: Automatic Property Initializers

When automatic properties were introduced into C# as a short-cut way of declaring properties I am sure lots of developers cheered for joy. Automatic properties are a great enhancement but every-time I use them I keep thinking that they are somewhat incomplete.

What I would like to do is have a neat way initializing automatic properties without having to declare them in the constructor. The syntax would be something like as follows:

public class Customer
{
public IEnumerable<Address> Addresses { get; protected set; } new Collection<Address>();
}

There are a few subtle things going on here. First, I might want to expose a list of addresses to calling code, however I may not necessarily want to expose a collection that can be updated. The syntax above exposes a public property as IEnumerable<Address>, however the backing field would be created as a Collection<Address>.

This would remove probably the #1 reason that I have to resort to implementing a property manually.