Tag Archives: csharp

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 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.