CODEWITHSUNDEEP
c#entity-frameworknhibernatearchitecturen-tier-architecture
LostInComputer
LostInComputer

Reputation: 15410

Repository pattern to query multiple databases

This is a very weird architecture. Please bear with me.

We have an existing tiered application (data, logic/service, client). The latest requirement is that the service layer should access two data sources!!!! (no other way around) These two data sources have the same DB schema.

As with most tiered architectures, we have read and write methods like:

IEnumerable<Product> GetAllProducts(),
Product GetProductById(ProductKey id),
IEnumerable<Product> FindProductsByName(string name)

the product DTOs are:

class Product
{
    public ProductKey Key { get; set;}
    ...
}

class ProductKey
{
    public long ID { get; }
}

We narrowed it down to two possible solutions:

Alternative 1: Add a parameter into the read methods so that the service knows what DB to use like so: Product GetProductById(ProductKey id, DataSource dataSource) DataSource is an enumeration.

Alternative 2 (my solution): Add the DataSource property to the key classes. this will be set by Entity Framework when the object is retrieved. Also, this will not be persisted into the db.

class ProductKey
{
    public long ID { get; }
    public DataSource Source { get; } //enum
}

The advantage is that the change will have minimal impact to the client.

However, people dont like this solution because

Which solution is more sound? Do you have other alternatives?

Note: these services are used everywhere.

Upvotes: 1

Views: 5623

Answers (1)

Travis J
Travis J

Reputation: 82297

What I would suggest is door number 3:

[||||||||||||||]
[|||||||||s!   ]
[||||nerics!   ]
[  Generics!   ]

I use a "dynamic repository" (or at least that is what I have called it). It is setup to be able to connect to any datacontext or dbset while still being in the same using block (i.e. without re-instantiation).

Here is a snippet of how I use it:

            using (var dr = new DynamicRepo())
            {
                dr.Add<House>(model.House);
                foreach (var rs in model.Rooms)
                {
                    rs.HouseId = model.House.HouseId;
                    dr.Add<Room>(rs);
                }
            }

This uses the "default" dbcontext that is defined. Each one must be defined in the repository, but not instantiated. Here is the constructor I use:

    public DynamicRepo(bool Main = true, bool Archive = false)
    {
        if (Main)
        {
            this.context = new MainDbContext();
        }
        if (Archive)
        {
            this.context = new ArchiveDbContext();
        }
    }

This is a simplified version where there are only two contexts. A more in depth selection method can be implemented to choose which context to use.

And then once initialized, here would be how the Add works:

    public void Add<T>(T te) where T : class
    {
        DbSet<T> dbSet = context.Set<T>();
        dbSet.Add(te);
        context.SaveChanges();
    }

A nice advantage of this is that there is only one spot to maintain the code for interacting with the database. All the other logic can be abstracted away into different classes. It definitely saved me a lot of time to use a generic repository in this fashion - even if I spent some time modifying it at first.

I hope I didn't misunderstand what you were looking for, but if you are trying to have one repository for multiple data sources, I believe this is a good approach.

Upvotes: 4

Related Questions