Herencia EFCore entre múltiples soluciones.
Tengo el siguiente problema:
Estoy utilizando EF Core 6 y el enfoque de código primero. Deseo tener una herencia TPT (Tabla por Tipo) para una de mis clases “Item” que tiene subclases “ItemA” y “ItemB”, etc. (habrá más subclases en el camino). Todo esto se admite fácilmente utilizando toTable() en el método “onModelCreating”, pero mi problema surge porque quiero que cada una de mis subcategorías se implemente en diferentes soluciones, por lo tanto, no puedo definir las DbSets de todas mis subcategorías en mi clase AppDbContext (que por cierto hereda de DbContext). Así que “ItemA” tiene su propia solución al igual que “ItemB” y así sucesivamente para que puedan implementarse por separado e incluirse como DLL en el proyecto principal una vez que se implementen, pero no sé cómo asegurarme de que sus tablas se creen dinámicamente mediante EF Core si se incluyen en la publicación final. ¿Esto es posible o tal vez estoy yendo por mal camino?
Editar:
La razón por la que estoy tratando de usar múltiples soluciones es para que los nuevos elementos puedan ser desarrollados por equipos diferentes completamente separados de otros elementos. Una vez que se completa un nuevo elemento, debería “conectarse” a la solución principal. Como Mark dice correctamente en los comentarios, estas soluciones probablemente serán muy similares. Por supuesto, tendrán muchas de sus propias clases, pero desde una perspectiva de datos, al menos heredan de “Item” que a su vez utiliza algunas otras clases.
EDITAR 2:
Esta es más o menos la estructura (simplificada) de las “clases” en mi proyecto.
[Tiene una imagen adjunta mostrando la estructura de las clases]
Tengo un “Producto” que tiene una lista de “Item”. Cualquier subtipo de “Item” debería poder estar en esta lista. No es importante que sea una lista, pero es importante que “Producto” pueda hacer referencia a “Items” sin conocer todos los subtipos de “Item” que se están creando.
Los “Items”, por otro lado, tendrán referencias a componentes (y otras cosas) que serán los mismos para cada clase de “Item”. Luego, por supuesto, “ItemA” y “ItemB” pueden tener referencias a sus propias cosas también.
La razón por la que estoy un poco preocupado por una arquitectura de microservicios es que no sé cómo hacer un seguimiento de la relación “Producto” -> “Item”. ¿Cómo puede el proyecto “principal” almacenar referencias a “Items” que están en bases de datos completamente separadas? Duplicar bases de datos o mantener la consistencia a través de eventos parece un poco exagerado ya que puede haber MUCHAS clases de “Item”.
\ Peter
davy.ai
Solución
Una posible solución es utilizar una arquitectura de microservicios para tu proyecto. Esto permitiría que cada subclase (por ejemplo, ItemA, ItemB) sea desarrollada e implementada como un servicio separado con su propia base de datos. Por lo tanto, no sería necesario definir DbSets para los subelementos en tu AppDbContext principal.
El proyecto principal puede comunicarse entonces con los servicios de subelementos a través de sus APIs, las cuales pueden ser RESTful, GraphQL, gRPC o cualquier otro protocolo adecuado. De esta manera, el proyecto principal puede acceder a los datos requeridos de cada servicio de subelementos sin estar fuertemente acoplado a ellos.
Otra posible solución es utilizar una arquitectura modular, donde cada subclase (por ejemplo, ItemA, ItemB) sea desarrollada como un módulo separado que pueda cargarse dinámicamente en tiempo de ejecución. Cada módulo puede definir su propio DbContext que hereda del AppDbContext principal y registrar sus propios DbSets. Cuando los módulos son cargados, sus tablas se crearán dinámicamente por EFCore si no existen previamente.
El proyecto principal puede utilizar la reflexión para descubrir y cargar los módulos de subelementos disponibles en tiempo de ejecución. De esta manera, nuevos subelementos pueden ser desarrollados e implementados por separado sin necesidad de modificar el proyecto principal.
En ambos casos, debes asegurarte de que los subelementos estén implementados de manera compatible, de modo que puedan ser cargados y accedidos por el proyecto principal. También debes asegurarte de que se mantenga la consistencia de los datos en las diferentes bases de datos si es necesario.