title: .NET and database layers
body: <p>When I last worked in programming, we were trying to move away from <code>DataReaders</code> and the traditional ADO.NET API toward Object Relational Mapping (ORM).</p>
  
  <p>To do this, we generated a <code>DataContext</code> of our DB via <code>sqlmetal</code>. There was then a thin data layer that made the <code>DataContext</code> <code>private</code>, and any code needing to access the database would have to use a <code>public</code> method in this thin data layer. These methods were basically stored procedures; they would perform queries on the database via LINQ to SQL.</p>
  
  <p>Is this a common approach today? I mean, is everyone whose using the .NET 3.5 framework really running sqlmetal in their build process, or what? It almost seemed like a hack at the time.</p>
  
  <p>Basically, I'd like to know if LINQ to SQL and sqlmetal is what to expect if I'm go to write a DAL today at a .NET 3.5 shop that doesn't employ a third-party, open-source ORM.</p>