Sto cercando delle indicazioni su come progettare un'app per quanto riguarda la modularità, la separazione delle preoccupazioni e la riutilizzabilità.
Sto lavorando su un'applicazione (ASP.Net, C #) che presenta blocchi di funzionalità distintamente generici, che mi piacerebbe poter estrarre, tutti i livelli, in componenti riutilizzabili. Ciò significa che il modulo gestisce lo schema del database, l'accesso ai dati, l'API, tutto in modo tale che la prossima volta che voglio usarlo posso semplicemente registrare il modulo e collegarlo.
Sviluppare moduli di funzionalità riutilizzabili è un gioco da ragazzi, ma quello che mi confonde veramente è cosa fare quando si tratta di gestire uno schema di database riutilizzabile principale che serve le funzionalità del modulo.
In un mondo ideale, registrerei un modulo e faremo in modo che lo schema del database associato esista nel DB, creando lo schema se non lo fosse già. Vorrei codificare la mia funzionalità dipendente supponendo che esistano le tabelle chiamando la funzionalità del modulo attraverso la DLL, agnostico del livello del database. Un po 'come il blocco applicazione di memorizzazione nella cache / registrazione di Enterprise Library, che può creare uno schema DB nel DB di destinazione da utilizzare come archivio dati.
Le mie domande sono: quale pensi sia il modo migliore per ottenere questo, in primo luogo, in termini di architettura del design e in secondo luogo di struttura della soluzione. Quali schemi / strutture conosci che esistono e amp; supportare questo genere di cose?
I miei pensieri finora:
Uso principalmente Entity Framework e progetti DB SQL Server. Ho pensato ad un approccio 'black box' ai moduli di funzionalità. Potrei usare un approccio code-first in EF4 e utilizzare ObjectContext per creare un database quando il modulo è inizializzato. Tuttavia, ciò significa che tutte le entità incapsulate dal mio modulo sarebbero disconnesse dal resto dell'applicazione perché appartenevano a un ObjectContext astratto. Inoltre, la creazione di indici e riferimenti appropriati tra entità di dominio e entità del modulo sarebbe praticamente impossibile.
Ho pensato di adottare Enterprise Library e creare i miei blocchi applicativi. Non sono sicuro di come sarebbe bello con Entity Framework (se non del tutto). Mi piace l'idea di costruire su modelli e ampli provati; pratiche per incapsulare funzionalità consolidate e riutilizzabili.
Ho pensato di abbandonare Entity Framework per il modulo e di creare semplicemente uno schema DB separato per il modulo con il suo insieme di stored procedure e amp; ADO.Net. Quindi distribuire lo script in fase di esecuzione se l'interrogazione mostra che non esiste. Ma ancora una volta, per sviluppare funzionalità al di fuori del modulo, vorrei usare Entity Framework e dovrei usare il modulo separatamente, disconnesso dal dominio ObjectContext.
Qualcuno ha avuto esperienza nello sviluppo di questo tipo di moduli full stack? Che consiglio puoi offrire? Sto mordendo più di quanto possa masticare?