I modelli di domini nel database possono essere una soluzione sostenibile?

13

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?

    
posta krystah 13.11.2015 - 17:36
fonte

1 risposta

16

Stai descrivendo una Piattaforma interna.

Il problema con le piattaforme interne è che reinventate tutti i meccanismi di una piattaforma o di una tecnologia (in questo caso, un database relazionale) che sono stati affinati e perfezionati in decenni di evoluzione e sforzo, ma reinventandoli male. Stai bypassando tutte le ottimizzazioni disponibili per coloro che scelgono un design più convenzionale e scambiano la semplicità iniziale e l'eleganza per la complessità e le difficoltà future.

Detto questo, se il prodotto finale di questo processo è reale tabelle e real classi che modellano real oggetti del dominio aziendale, non lo faccio vedere molto danno in questo approccio, a parte l'immaturità degli strumenti. Stack Exchange utilizza effettivamente il proprio ORM homegrown e sembra aver funzionato per loro. Quindi so che questo tipo di approcci "cottage" può funzionare.

Si noti che la maggior parte degli ORM che adottano l'approccio "table-first" semplicemente guardano la struttura della tabella nel database per creare le classi. Le tabelle "tabella" e "riga" create dal tuo amico sono solo metadati che esiste già nelle tabelle di sistema dei più moderni sistemi di database relazionali.

Ulteriori letture
Il progetto "Vision", una ammonizione sull'effetto piattaforma interna
(Puoi saltare il preambolo e iniziare a leggere nel sottotitolo "Presentazione di Vision")

    
risposta data 13.11.2015 - 17:59
fonte

Leggi altre domande sui tag