title: ASP.NET MVC - Model Interfaces
body: <p>Seeing as though I've now solved all of my LINQ problems I'm not working on developing an actual model.  The thing is with this is that I <em>do not</em> want to be tied in to a single technology, I want to have freedom to implement different data access technologies and work to a single interface.</p>
  
  <p>Now, I've never done this before, but based on my OOP knowledge and experience I was coming up with an idea like the following:</p>
  
  <pre><code>using System;
  using System.Collections.Generic;
  using System.Linq;
  using System.Text;
  using System.Data.Linq;
  
  namespace Intranet.Data.Accounts
  {
    interface IContractsControl
    {
      ContractsControlViewData GetContracts(System.Nullable&lt;int&gt; contractTypeID,
                                    System.Nullable&lt;int&gt; responsibilityID,
                                    string expenseType,
                                    System.Nullable&lt;int&gt; supplierID,
                                    string businessID);
  
      ContractsControlViewData GetContract(int contractID);
    }
  }
  </code></pre>
  
  <p>I've got a few questions on how this should work.</p>
  
  <ol>
  <li>Where should the interface live, taking into account I'm using an areas lib developed by Phil Haack. For now I've created a folder called "Data" at the root level (as you can see from the namespace).</li>
  <li>Our stored procedures have spurious names because they're pooled into a database, if I'm using objects I can instead work towards an object-based solution for access to sprocs.  Do the names in my data access library have to reflect that of the stored procedure in this instance?</li>
  <li>Using a library such as this would allow me to do <code>Accounts.GetContracts()</code> in my controller.  Is this wise?</li>
  <li>Are there any design recommendations for this approach? i.e. naming schemes.</li>
  <li>Where should the actual implementation live? In the same folder as the interface?</li>
  </ol>
  
  <p>The idea is that if we ever ditch LINQ then we can instead use a different data access technology (entity framework, plain ol' SQL etc.).  I'd love to hear comments/criticisms/appraisals from those more experienced.</p>