Factory Database with Multiple Databases

Question

I am creating a factory database template for an application that should work with SqlServer and Oracle. I used a similar approach suggested in the following article:

http://www.primaryobjects.com/CMS/Article81.aspx

Now the problem is that my application communicates with multiple databases on the same server. For example: I perform several queries against the DB1 database and several queries against DB2, as on SqlServer. Using the above article, I could create an instance of one database. How can I use the same approach for working with multiple databases. Can anyone help me with this? Thanks.

Answer 1

I would advise you to take a look at the repository template. Using the repository template, you can abstract your application from the infrastructure. This allows you to communicate with one or more databases, web services, the file system, or any other data source that is outside your domain and direct-control applications. With this, you could have an infrastructure that can be linked to multiple data sources behind the scenes. An example of this was the e-commerce application that I recently worked with, allowed me to talk to my local database for a direct product catalog, and also spoke to SAP behind the scenes to register new orders / purchases.

With this, you can have code that calls into a repository that looks something like this:

AccountRepository _repository = new AccountRepository(); Account account = _repository.GetAccountByID(32); 

Or you can say something like:

 Account account = new AccountRepository().GetAccountByID(32); 

The main idea of ​​the repository is that your application can make calls to get the data it needs. It will return the actual domain objects (for example, the account in the above example). Or it can return an IEnumerable<Account> if you need a list of accounts.

An implementation of this method, in which you can get data from two data sources, may look like (although I do not suggest similar problems):

 public class AccountRepository { public Account GetAccountByID(int accountID) { Account result = null; using(MyDataContext dc = new ConnectionFactory.GetConnection(Databases.DB1)) { result = dc.Accounts.Where(a=>a.AccountID == accountID).FirstOrDefault(); } //result is null...go to the other database to get an Account if(result == null) { using(MyDataContext dc = new ConnectionFactory.GetConnection(Databases.DB2)) { result = dc.Accounts.Where(a=>a.AccountID == accountID).FirstOrDefault(); } } return result; } } 

My preference for such a situation would be to create an application service level that handles the application logic. The repository must be technically linked to one data source. Then you can have several different repositories for a couple of different data sources. In your application level, there would be a new instance of GetAccountByID from repository 1 (database 1), and if it were zero ... then the application level will drop into the second repository (for example, in database 2). Whenever possible, storage should follow SOLID principles. Where my example clearly violates the SOLID approach, there is more than one reason for changing this GetAccountByID function!

But ... if this is what you need ... there is a way to do it!