Ho appena iniziato un nuovo lavoro come sviluppatore di database per un'azienda di dimensioni medio-piccole basata sulla tecnologia Microsoft. Ho notato fin da subito quanto le pratiche si discostano da ciò che mi è stato insegnato a scuola per quanto riguarda le migliori pratiche, i modelli di progettazione, i test e la gestione dei progetti.
Ciò che mi infastidisce di più è il modo in cui il nostro principale sviluppatore di database (d'ora in poi chiamato "John") mantiene lo schema del modello nel database! Lo facciamo avendo 3 tabelle "magiche"; uno per gli schemi di database, uno per le tabelle e uno per le colonne.
Inserendo un record nella tabella " Tabelle " - la tabella genera (tramite un trigger del database), la tabella effettiva e corrispondente. Inserendo una riga nella tabella " Righe " - la tabella di riferimento viene aggiornata con quella riga. Questi sono a loro volta letti dal suo programma in C # fatto in casa per generare modelli C #, che sono usati dagli sviluppatori di frontend per i controller e verso l'esterno.
Oltre a questo, la maggior parte dello sviluppo è fatto secondo ASP.NET MVC framework.
Vedo un paio di difetti con questo approccio:
- Abbiamo bisogno che mantenga l'ORM e raramente ha il tempo di farlo (la sicurezza del lavoro è buona!)
- I trigger per la tabella "Tabelle" e "Righe" sono difettosi. Non supportano gli aggiornamenti delle tabelle, né i vincoli di controllo o più funzionalità "avanzate". Mentre potremmo sicuramente migliorarli, non sono ancora sicuro se questa è la strada da percorrere.
- Mantenere la logica programmatica nel database è strano e restrittivo (sebbene sia possibile estendere i suoi modelli attraverso C #).
- Il suo generatore di modello C # deve essere eseguito manualmente da una delle 3 persone (tra le quali io sono uno) e non è ancora abbastanza maturo per essere incluso in un processo di compilazione automatizzato.
Diverse persone hanno suggerito di introdurre gradualmente un prodotto vero e testato come Entity Framework , ma lo rifiuta , clamando che mantenere la logica di business nello strato di codice è adatto solo per applicazioni su piccola scala e progetti di bootstrap per le startup.
Questo post sta portando a qualcosa che potrebbe sembrare una discussione supponente, ma non è mia intenzione. Voglio solo alcuni chiarimenti riguardo al nostro approccio architettonico.
È possibile mantenere i modelli di dominio nel database come una soluzione sostenibile per un'azienda in crescita?