How can I effectively map one application to two database backends during a conversion to a new vendor?

Question

Okay. I've started a new project using MVC3. I've implemented EF4.1,Automapper, Ninject, PagedList from NuGet.

I've spent two days fleshing out my patterns, setting up IOCs and interfaces. I am injecting my service into my controller, my repository into my service, and my DbContext into my Repository.

What I'm left with is an application that runs and all is good. The problem I'm having is that we are in the process of changing vendors for agency's main system. This means the Database structure will be significantly changing.

Would it be correct for me to create two concrete implementations of ICamaContext and two Concrete implementations of ICamaRepository? One for each Database? Then in each repository, I would map my corresponding dbsets to my types to match the contract defined in ICamaRepository?

I'm not sure if that makes any sense. So in other words, I don't want to rewrite anything in my service regardless of which DB backend is being used.

namespace search.Common.Repositories
{
    public interface ICamaRepository
    {
        IQueryable<Parcel> GetParcels();
    }

    public class AssessProCamaRepository : ICamaRepository
    {
        ICamaContext _db;

        public AssessProCamaRepository(ICamaContext dataContext)
        {
            _db = dataContext;
        }


        public IQueryable<Parcel> GetParcels()
        {
            return from c in _db.DataProperty
                   select new Parcel
                   {
                       AccountNumber = c.AccountNumber                      
                   };

        }
    }
}

I'm not sure, I just was following an online article. I actually modified the code to inject the context directly into the Service. — Doug Chamberlain, Feb 09 '12 at 19:50

score 1 · Accepted Answer · answered Feb 09 '12 at 21:01

1

It sounds like a reasonable approach. However, since the database structure will be significantly changing, it could be challenging to come up with a repository layer that is common between the old and new database structures.

Additionally, depending on the differences in databases, you might not be able to return an IQueryable for all of your repository methods.

answered Feb 09 '12 at 21:01

CodeThug

3,054
1
21
17

I need to rethink my approach. But, Ultimately I don't want to have to change the names/purpose of my Service Methods, I can handle the mapping Models to View Models using AutoMapper. I don't know...maybe I ultimately need to write two Services? – Doug Chamberlain Feb 09 '12 at 21:17
+1 FWIW, here's more about the potential issues of basing an interface on IQueryable: http://stackoverflow.com/questions/1699607/asp-mvc-repository-that-reflects-iqueryable-but-not-linq-to-sql-ddd-how-to-que/1699756#1699756 – Mark Seemann Feb 09 '12 at 23:26
BTW, I think the keyword here is 'challenging'. I agree, but it's not impossible. The key lies in defining the data access API in terms of Role Interfaces instead of Header Interfaces. – Mark Seemann Feb 09 '12 at 23:27

score 0 · Answer 2 · answered Feb 09 '12 at 21:12

I don't think abstracting dbContext in repositories would give you any benefit, in fact using an abstracted data-layer in repositories don't make sense so much.

IMO it's almost impossible to create an abstraction layer which would be usable (implementable) by different data access technologies (or even different ORMs), so abstracting data-layer just adds more useless complexity. Finally I suggest creating two versions of each repository, one for the new structure and another for the old one, and then your DI units decide to use the right one.

How can I effectively map one application to two database backends during a conversion to a new vendor?

2 Answers2