title: Modernising a 'Hand Rolled' Data Access Library
body: <p>There's this web app, which relies on a sort of data access library (simple data objects and associated objects to perform CRUD operations on them) which is generated  directly from the database.</p>
  
  <p>So from a Person table</p>
  
  <p><code>ID<br>
  Forename<br>
  Surname<br>
  DoBirth</code></p>
  
  <p>you'd get a generated Person class with fields:  </p>
  
  <p><code>ID, Forename, Surname, DoBirth</code> typed from their db columns.</p>
  
  <p>And a helper class PersonPersister</p>
  
  <p>with </p>
  
  <pre><code>Create(Person p)  
  Update(Person p)  
  Delete(Person p)  
  </code></pre>
  
  <p>methods.</p>
  
  <p>It will also create the necessary CRUD sprocs on the database.</p>
  
  <p>I felt uneasy about this when I started as, aside from brief flirtations with nHibernate and MEF I'm used to handcoding my dataaccess layer. All my worries appear to be coming to fruition now, a year on as we're doing another phase of development with a larger team of devs and the cracks have started to appear.</p>
  
  <p>The basic problem is that as developers we have no control over whats generated and there is no way to version the DAL.</p>
  
  <p>Everytime we do a release we much time hand-configuring the app, dal and databse to get it working. Often the scenario is one in which the DAL has been generated off the dev db and then applied to the live db which of course lacks the tables/sprocs etc. created during development.</p>
  
  <p>At these times, I often find myself heading over to jobserve.com, even though this issue aside I rather like working here. </p>
  
  <p>Ideas I've had include modding the codegenerator so it overwrites source files in an explicit DAL-handling Visual Studio project - these would then be trackable in a CVS and also hand-editable. Does anyone have any positive experiences of such a strategy? At the moment the only artifact the build generates is a dll so seeing the history of changes is not possible.</p>
  
  <p>Aside from using an ORM (management is not a fan - yes, I know) what are our options as far as rationalising this to give ourselves control? We still need an element of automation but the amount we have is unworkable at present.</p>
  
  <p>We are very lucky to have MSDN subscriptions here, so we're running TFS 2010 with automated builds, the latest Visual Studio etc. etc., but because of this aspect of our development environment, it feels like we're a decade or more behind the times.</p>