I’m currently trying to use Linq to SQL to model and persist some very simple domain objects. Not having used Linq to SQL before, I’m muddling through, but have quickly run up against a couple of things that have me puzzled:
- Entity classes require a public default constructor
- There’s no support for user-defined value types
My ignorance? Limitations in the framework? You tell me.
Default Public Constructors for Entity Classes
I’m attributing my entity (domain) classes with TableAttribute, and their members with ColumnAttribute. TableAttribute maps a class to a table in the database; ColumnAttribute maps its members to the table’s columns.
To ensure that an object behaves as a good citizen from the moment it’s instantiated, I prefer to set up its state in its constructor. To further guarantee an object can’t be created in an ill-formed state, I tend not to include a default, parameterless constructor for such classes.
Now unless I’m mistaken, I can’t define a Linq to SQL entity class that lacks a public default constructor:
System.InvalidOperationException: The type 'xxx' must declare a default (parameterless) constructor in order to be constructed during mapping.
Nor can I use a private parameterless constructor:
System.MissingMethodException: No parameterless constructor defined for this object.
I can make my members private, so that only Linq can call the setters during object initialisation, which is great; but I can’t make the constructor private or otherwise accessible only to Linq. Seemingly a small issue, but it means that some objects could end up being created in an invalid state.
No Support for User-Defined Value Types
As far as I’m aware, Linq to SQL doesn’t support user-defined value types. Value types are types that lack identity, much as an integer doesn’t have any identity: this 3 is as good as that 3. Value types serve as attributes of entities - which do possess identity. In a database, value types are often stored in the table of the entity that owns them; in an object model, they’re usually surfaced as a dependent object of the parent class they help describe.
To illustrate what I mean by value type, imagine we are modelling a Picture with Description, Border Thickness and Border Style attributes. We might store the Picture in the database like this:
- but represent it in code like this:
Here the Border class constitutes a user-defined value type.
One of the things I want to do with one of my domain objects is store a hash of a string member (a Uri in this instance) with that object’s corresponding database record. I can then index the hash, and lookup records based on the hash rather than a long (500) nvarchar value (which in any case can’t be indexed because it exceeds 900 bytes).
The hashing algorithm isn’t a concern of the entity class that exposes the hash value, so I’ve encapsulated the algorithm in a separate class, effectively making it a user-defined value object:
public class UriHash
{
private readonly int value;
public UriHash(string uri)
{
value = uri.GetHashCode();
}
public UriHash(int value)
{
this.value = value;
}
public int Value
{
get { return value; }
}
}
As you can see, I’m simply calling GetHashCode() on the relevant string member, but it may be that in the near future I’ll want to change this to use, say, an MD5 hash. When (if) that happens, I’ll have to make changes in several places: in the database schema (int to nvarchar), and in any code that gets or sets an int value. What I’m keen to do, even from the outset, is maintain my encapsulation of the hashing algorithm, but at the same time keep to a minimum the number of places where knowledge of the hash type (int versus string/nvarchar) is baked into the code.
Because Linq to SQL doesn’t currently support user-defined value types, my entity class exposes the hash as a plain old int, as follows:
[Table(Name = "MonitorableResource")]
public class MonitorableResource
{
// Constructors omitted
private UriHash uriHash;
[Column(DbType = "Int NOT NULL", CanBeNull = false)]
internal int UriHash
{
private set { uriHash = new UriHash(value); }
get
{
if (uriHash == null)
{
uriHash = new UriHash(Uri);
}
return uriHash.Value;
}
}
[Column(DbType = "NVarChar(500) NOT NULL", CanBeNull = false)]
public string Uri { get; private set; }
// Other code omitted
}
The problem here is that whilst the hashing algorithm is nicely encapsulated in the UriHash class, the hash type (an int in this instance) is smeared all over the code. The database schema knows it’s an int, and so does the UriHash class. That’s fine: there’s a one-to-one mapping between the OO and the relational worlds. But on top of that, MonitorableResource knows that the type is an int, and that its UriHash member maps to the UriHash column in the database. That’s one place too many for my liking.
Ideally I’d like to expose the MonitorableResource’s UriHash member as a UriHash, and push the ColumnAttribute mapping onto the UriHash type’s Value member - something like this (note, this code isn’t valid Linq to SQL):
[Table(Name = "MonitorableResource")]
public class MonitorableResource
{
// Constructors omitted
private UriHash uriHash;
[ValueObject]
internal UriHash UriHash
{
private set { uriHash = value; }
get
{
if (uriHash == null)
{
uriHash = new UriHash(Uri);
}
return uriHash;
}
}
[Column(DbType = "NVarChar(500) NOT NULL", CanBeNull = false)]
public string Uri { get; private set; }
// Other code omitted
}
public class UriHash
{
public UriHash() {}
public UriHash(string uri)
{
Value = uri.GetHashCode();
}
public UriHash(int value)
{
Value = value;
}
[Column(Name = "UriHash", DbType = "NVarChar(500) NOT NULL", CanBeNull = false)]
public int Value { get; set; }
}
Interestingly, the forthcoming Entity Framework does support value objects, which it calls Complex Type Objects. NHibernate, of course, has long supported custom value types.