Monday, March 22, 2010

Binge and Purge

A recent refactoring effort has caused me to reflect on the therapeutic nature of the ‘delete’.  As developers we’re continuously creating, building, adding and enhancing.  Pride and accomplishment are achieved through the act of creation.  We’re builders.  But like any builders sometimes in the course of building we have to tear down what was there before, and who doesn’t enjoy demolition?

I’m not sure exactly when it happened, but I’ve definitely felt a shift in the parts of my job that I enjoy.  Maybe its because for years I’ve stumbled around the debris and vestiges of features and functionality scattered throughout systems, not knowing why they are there or what they are for.  Maybe its because, similarly, I’ve too often encountered complexity and duplication in those systems but not felt like I had the time to do anything about it.  For those reasons and maybe others I find that I now relish the opportunity to drop a table, remove a method, combine or eliminate files and even, (darest I dream) remove whole projects.

Never again

There is definitely something therapeutic about the finality of deleting.  Removing some piece of complexity, redundancy or just plain deadwood, permanently, never to stumble across and ponder its purpose again.  Never again having to explain to anybody why its there, never having to be afraid to touch it because I don’t know the ramifications.  Sure, tools and techniques, like unit testing, have definitely made me more fearless in this endeavor, but its the delete itself that I savior.

Everybody dances with the Grim Reaper

I highly recommend taking out your scythe, in my case that is Refactor’s “safe delete”, and start cutting.  You’ll feel better.

Wednesday, March 17, 2010

Like I need another connectionstring

One of the annoyances with Entity Framework v1 is that it requires a specialized connection string. This is particularly annoying if you are introducing EF to an existing code base that already uses ADO.NET in some capacity. If you are, you already have a connection string in your app.config, web.config or machine.config that looks like this:

<connectionStrings>
    <add name="EFDb" connectionString="Data Source=.;Initial Catalog=EF;Integrated Security=True"/>   
</connectionStrings>

Now say you want to create an Entity Model against the same database. When you create that model you get a second connection string for EF.

<connectionStrings>
<add name="EFDb" connectionString="Data Source=.;Initial Catalog=EF;Integrated Security=True"/>
<add name="EFEntities" connectionString="metadata=res://*/NoConnectDb.csdl|res://*/NoConnectDb.ssdl|res://*/NoConnectDb.msl;provider=System.Data.SqlClient;provider connection string=&quot;Data Source=.;Initial Catalog=EF;Integrated Security=True;MultipleActiveResultSets=True&quot;" providerName="System.Data.EntityClient" />
</connectionStrings>

Strings attached
This new connection string gives you some ‘metadata’ gobbledygook plus the “provider connection string” which is a duplication of the connection string information already present in your ADO.NET connection string. As far as I can tell, this is just unnecessary connection string proliferation, and another deployment setting to manage and keep in sync. It’d be nice if the EF connection string could just get its info from the ADO.NET connection string by referencing it like:

<add name="EFEntities" connectionString="metadata=res://*/NoConnectDb.csdl|res://*/NoConnectDb.ssdl|res://*/NoConnectDb.msl;provider=System.Data.SqlClient;provider connection string=EFDb" providerName="System.Data.EntityClient" />

I’m not sure if a facility like this exists, I couldn’t find how to do it if it does. Regardless, if I could do something like this, wouldn’t it make that very same EF connection string superfluous? The metadata portion is pretty static, so I’m not sure why that’s stored in configuration to begin with, and if the database connection info is already stored in another setting, what’s the point, why not just get rid of it entirely?

Good riddance

As it turns out, that’s pretty easy to do. This isn’t the only way, but the one that happened to best suit my needs. I inherited from the ObjectContext generated by the model, and then built the Entity Connection String by concatenating the static metadata portion with the pre-existing connection string in the ContextWrapper constructor.

public class ContextWrapper : EFEntities
{
private const string CONNECTION_STRING = "metadata=res://*/NoConnectDb.csdl|res://*/NoConnectDb.ssdl|res://*/NoConnectDb.msl;provider=System.Data.SqlClient;";

public ContextWrapper()
: base(new EntityConnectionStringBuilder(CONNECTION_STRING){ProviderConnectionString = ConfigurationManager.ConnectionStrings["EFDb"].ConnectionString + ";MultipleActiveResultSets=True;"}.ConnectionString){}
}

As long as I use the ContextWrapper instead of the EFEntities objectcontext when working with the model, I don’t need the Entity Connection string in my config at all.