Le sugiero que eche un vistazo al patrón de repositorio. Con el uso de un patrón de repositorio, puede abstraer su aplicación de la infraestructura. Esto luego le permitiría comunicarse con una o más bases de datos, servicios web, el sistema de archivos o cualquier otra fuente de datos que esté fuera de su dominio y con el control directo de las aplicaciones. Con esto, podría tener una infraestructura que detrás de escena pueda comunicarse con múltiples fuentes de datos. Un ejemplo de esto fue una aplicación de comercio electrónico en la que trabajé recientemente que me permitió hablar con mi base de datos local para el catálogo directo del producto, pero también conversé con SAP detrás de escena para registrar nuevos pedidos/compras.
Con esto es posible que tenga código que llama en el repositorio que se ve algo como esto:
AccountRepository _repository = new AccountRepository();
Account account = _repository.GetAccountByID(32);
o se puede decir algo en la línea de:
Account account = new AccountRepository().GetAccountByID(32);
La idea básica detrás de una repositorio es que su aplicación puede realizar llamadas para obtener los datos que necesita. Devolvería objetos de dominio reales (como una cuenta en el ejemplo anterior). O podría devolver IEnumerable<Account> si se necesita una lista de cuentas.
Una implementación de este donde agarrar los datos de dos fuentes de datos podría ser similar (aunque no sugiero preocupaciones co-mezcla de este tipo):
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;
}
}
Mi preferencia por una situación como esto sería para crear una capa de servicio de aplicación que maneje la lógica de la aplicación. Un repositorio debería estar técnicamente relacionado con una fuente de datos. A continuación, puede tener un repositorio diferente para la pareja diferentes fuentes de datos. En su capa de aplicación, entonces se actualizaría la instancia de GetAccountByID del repositorio 1 (base de datos 1) y si era nula ... la capa de aplicación se sumergiría en el segundo repositorio (base de datos 2, por ejemplo). El repositorio debe seguir los principios SÓLIDOS si es posible. ¡Donde mi ejemplo claramente rompe el enfoque SÓLIDO es que hay más de una razón para que la implementación de GetAccountByID cambie!
Pero ... si esto es lo que necesita ... ¡hay una manera de hacerlo!