Creé una aplicación con la misma arquitectura de datos detrás de ella; tenemos una base de datos SQL in situ que contiene la mayor parte de la automatización y la información interna diaria, y luego un servicio en la nube de terceros utilizado para ventas, administración de cuentas, personal de campo, etc. El servicio de asistencia necesitaba información de ambos con respecto a las ubicaciones físicas de los clientes y equipo, y lo había estado obteniendo de dos aplicaciones diferentes hasta que entré.
En resumen, una fuente de datos debe tener una referencia a los registros de la otra. En nuestro caso, los datos de la nube de terceros contienen referencias a los datos en el sitio porque ese es el acuerdo sobre el que teníamos más control. Ahora, con una ID para un registro de cualquier fuente de datos, podemos obtener datos de ambos; con una ID de nube, extraemos el registro de la nube, obtenemos la ID en el sitio y extraemos los datos en el sitio. Con una identificación en el sitio, encuestamos ambas fuentes de datos en función de esa identificación.
En mi sistema, no hice que ninguno de los objetos fuera hijo del otro en la capa de dominio; Cualquier uso de los datos de ambas tiendas debe mantener dos instancias de objeto. No se garantiza que ninguno exista, por eso lo hice así; la aplicación puede funcionar solo con datos en la nube, o con datos en el sitio, o ambos, con más limitaciones cuanto menos datos tenga.
Sin embargo, eso no es difícil de cambiar, especialmente si está seguro de que siempre existirá un lado; simplemente incluya una propiedad en el objeto que represente el lado para el que siempre existirán datos, que es del tipo de objeto que representa el registro del otro almacén de datos. Es posible una "fusión" más avanzada de los dos gráficos en uno.
Este tipo de arreglo necesariamente debe estar acoplado en algún nivel. Puede tener un DAL que pueda interactuar con ambos almacenes de datos, o puede segmentar los DAL, uno por almacén de datos, y hacer que una capa superior, como un Controlador, obtenga los datos de cada uno y los junte. Pero, en algún nivel, su programa tiene que tener la inteligencia para juntar estas dos fuentes de datos dispares.
Puede reducir el acoplamiento requerido en la mayoría de los casos abstrayendo detalles de dónde provienen los datos exactamente. Si obtiene datos de un servicio web, que se le proporciona como instancias de clases generadas, coloque un convertidor para hacer una copia profunda de la clase de servicio en algo que controle, que no tendrá que cambiar si los datos la fuente lo hace (solo si el esquema lo hace).
Ahora, esto puede ser una gran empresa; la nube que utilizamos tiene docenas de clases de dominio, algunas de las cuales tienen cientos de campos de datos y, aquí está el truco, es muy fácil que tengas que hacer grandes cambios en el tipo de datos abstractos para acomodar un movimiento a una nube diferente u otro control remoto fuente de datos. Por esa razón, no me molesté; Utilizo el dominio del servicio web generado directamente, y ahora que se avecina un cambio de la nube a un almacén de datos externo (pero bajo nuestro control), cuyos detalles aún no sé, simplemente estoy planeando cambiar los formularios y código detrás de la aplicación, que es donde los datos se "combinan", para reflejar el nuevo esquema y / u objetos de datos. Es un gran trabajo de cualquier forma que lo corte.
