ASP.NET MVC - Model Interfaces

Question

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 do not 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.

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:

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<int> contractTypeID,
                                  System.Nullable<int> responsibilityID,
                                  string expenseType,
                                  System.Nullable<int> supplierID,
                                  string businessID);

    ContractsControlViewData GetContract(int contractID);
  }
}

I've got a few questions on how this should work.

1. 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).
2. 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?
3. Using a library such as this would allow me to do Accounts.GetContracts() in my controller. Is this wise?
4. Are there any design recommendations for this approach? i.e. naming schemes.
5. Where should the actual implementation live? In the same folder as the interface?

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.

Answer 1

The IMultipleResults to me sticks out like a sore thumb. It doesn't exactly advertise the real return type to the caller.

If you want true repository abstraction, you could have a separate Contract type that is nothing to do with your ORM tool, and return an array/list of those. Some frameworks (NHibernate, LINQ-to-SQL if you work hard enough, EF in 4.0) support POCO usage, allowing you to use your simple (non-ORM) objects via the ORM tool. So my preference would be:

• interface-based repository, returning arrays/lists/etc of...
• ...concrete POCO types

The extra abstraction of an interface data type plays havoc with some data-binding setups (it can't create new records, for example).

Answer 2

Your approach looks much like the Repository Pattern, praised by many ASP.NET MVC tutorial writers... =) Here's a tutorial which describes how to make an existing application loosely coupled, and one thing (among others) it shows is how to implement the Repository Pattern in ASP.NET MVC.