jeudi 10 octobre 2019

How to design a repository when datasource differs based on DML/READ operations?

We are starting our new application in which we using MS SQL DB for all our insert/update/delete/select ie. both SELECT and DML operations.

But, soon we will have two different sources. SQL Server DB and Elastic Search. The idea is to perform all the DML operations on MS Sql DB but will be using Elastic Search for ALL the fetch (select) operations. The data is replicated in ES from MS SQL DB.

At present our project structure looks something like this:

Controller (UI Layer)

CreateStock(Stock stock){
_serviceLayer.CreateStock(stock);
}

List<Stock> GetStocks(){
var stocks =  _serviceLayer.GetStocks()  
}

ServiceLayer

CreateStock(Stock stock){
  // business logic
_repository.CreateStock(stock)
}

List<Stock> GetStocks(){
 return _repository.GetStocks(stock)  
}

Repository

CreateStock(Stock){
    //Insert data to MS SQL DB with ADO.NET
}

List<Stock> GetStocks(){
  //Get data from MS SQL DB with ADO.NET
}

FUTURE REQUIREMENT:

Controller

Repository

CreateStock(Stock){
    //Insert data to MS SQL DB with ADO.NET
}

List<Stock> GetStocks(){
  //GET DATA FROM OTHER DATA SOURCE (ES)
}

Now of course I could create whole new repository classes for new implementation with Elastic search as the data source. Both the repositories will inherit from common interface. But problem with that approach is that I will be duplicating the DML operations in both the classes.

How can I reuse the DML code in future?

  1. Should I create two repositories? One for DML and another for SELECT? So I could create a single implementation for DML Repository and two implementation for SELECT repository?

  2. Should I create a single repository but then add another later after that?

Is there an option 3?

There is a possibility that we decide to USE SQL DB for both DML and Reads when Elastic Search is down for a few days.

Aucun commentaire:

Enregistrer un commentaire