Stored procedure, ORM e altri livelli dell'applicazione

Suppongo che tu stia utilizzando .NET per lo sviluppo poiché hai menzionato MSSQL come database ma i miei consigli si applicano anche agli O / RM disponibili per altre piattaforme.

Elimina e verifica CRUD Soft

Per il tuo primo numero, operazioni CRUD e filtraggio di "soft delete". Lo stesso O / RM fornisce una base che consente di ottenere scenari più complessi. Molti sviluppatori utilizzano i modelli e i principi di Domain Driven Design quando sfruttano un O / RM.

Uno schema che aiuterà nel tuo scenario è il schema del repository . L'idea del modello di repository è che agisce come una raccolta di entità (oggetti che sono supportati dal database). È possibile passare filtri (nelle espressioni LINQ .NET) e restituisce gli oggetti che corrispondono al filtro. La bellezza dell'implementazione .NET è che quando si esegue il backup con Entity Framework o NHibernate, le espressioni LINQ vengono convertite in SQL ed eseguite sul database anziché in memoria.

"Allora, come mi aiuta con le eliminazioni soft?" chiedi.

Il tuo repository può fornire un filtro che viene aggiunto ad ogni query per impostazione predefinita. E chiamare eliminazione sul repository può essere implementato impostando la proprietà "IsDeleted" sull'entità anziché eliminarla dal DB.

Le tabelle di controllo possono essere implementate da trigger, se necessario. In alternativa, per una soluzione più avanzata, è disponibile il design Event Sourcing . Con Event Sourcing, si mantiene un conto corrente degli eventi che si verificano nell'applicazione. Ad esempio, se vuoi scoprire perché il prezzo di un prodotto nel tuo inventario è cambiato, puoi guardare la cronologia degli eventi e vedere quando e perché è stato modificato e da chi.

Exposing Services

Una volta creato il modello di dominio, non vi è nulla che impedisca di creare un wrapper attorno ad esso per fornire accesso basato sul caso d'uso al modello. Questo è chiamato Livello servizio applicazioni . Fornisce un'interfaccia semplificata per il tuo modello di dominio in modo che la tua applicazione possa rimanere protetta dalle modifiche che non influiscono direttamente su di essa.

Livelli

Le persone sono ossessionate da architetture complicate ... per me ci sono tre semplici elementi per l'interfaccia utente di un'applicazione, Business Logic, Storage. Potresti decidere di suddividerli in diversi livelli concettuali (ad esempio, l'interfaccia utente mobile deve accedere a un servizio ospitato attorno alla tua logica aziendale) ma per la maggior parte si tratta di dividere i capelli.

Che cos'è la logica aziendale?

Questo è stato per me un concetto difficile da cogliere quando ho spostato da una mentalità incentrata su database a Domain-Driven Design. La logica aziendale vive nelle tue entità. Quali sono mappati al database.

La differenza tra il solo mapping delle classi in tabelle / oggetti in righe e il Domain-Driven Design, è che le Entità DDD sono oggetti ricchi nel senso orientato agli oggetti. Uno dei principi della programmazione orientata agli oggetti è l'incapsulamento, ovvero i dati e la logica che circonda i dati sono collegati tra loro in una classe.

Prendi ad esempio la regola che un cliente deve avere almeno un indirizzo. Nel gergo DDD, questo sarebbe chiamato invariante. Fondamentalmente, il Dominio non ti permetterebbe di costruire un Cliente senza che tutti i suoi invarianti siano validi. Come sarebbe? Avresti un costruttore per la tua entità cliente che prende un indirizzo e qualsiasi altra informazione che è obbligatoria per un cliente valido. Ci sono alcuni buoni post sul blog sul concetto (questo fornisce un buona discussione con link che entrano in ulteriori dettagli).

Per farla breve, la logica aziendale va con i dati che stai memorizzando.

Gli sviluppatori

Tutto ciò è soggettivo. Più importante del modo in cui lo storage è la tua metodologia di sviluppo, come ottenere informazioni agli sviluppatori su cosa costruire. Progettazione architettonica generale, come funzionano i vari pezzi della soluzione. Una volta che hai stabilito una chiara direzione per queste cose, come lo spazio di archiviazione non dovrebbe avere importanza.

Nota finale

Una cosa che non mi piace delle stored procedure è che devi duplicare la tua logica. Scrivi lo sproc nel database, quindi devi scrivere il codice che interagisce con lo sproc e traduce i risultati nei tuoi oggetti. È un lavoro noioso (e soggetto a errori) che l'O / RM gestisca se possibile.

Prima di tutto, indipendentemente da ciò che si sceglie, si vuole il più possibile la logica di business al di fuori del proprio database. Ci sono molte ragioni per questo, la coppia più importante è che sei legato al tuo database, quindi se hai bisogno di passare a Oracle o SQL Server diventa un compito molto più difficile, SQL non è progettato per gestire la logica di business con grazia, il che si traduce in un enorme archivio procedure e funzioni che avrebbero potuto essere solo alcune righe di codice.

Inoltre vorrai un livello che gestisca tutti gli accessi ai dati tra la tua app e il database, indipendentemente dal fatto che tu scelga un ORM o stored procedure. Uno dei motivi è che potrebbe essere potenzialmente utilizzato per più app, inoltre rende l'app meno dipendente dal database reale, rendendo anche più facile la modifica.

Per decidere se utilizzare o meno un ORM, probabilmente nell'app non c'è nulla che possa esporre un punto debole di un ORM. La tua preoccupazione sull'eliminazione hard vs. soft non è un problema, i passaggi sono sostanzialmente uguali in entrambi i casi, hai inserito un'istruzione update nella procedura DeleteRecord o hai cambiato la proprietà eliminata nell'oggetto record nel metodo DeleteRecord che hai creato. Il deficit di ORM è in genere sempre una performance, e stanno migliorando costantemente su questo fronte. Gli orms iniziano il lsoing quando inizi ad avvicinarti al territorio dei Big Data (milioni di righe e forse anche decine di milioni) o sei a livelli estremi di traffico (Amazon, HFT).

Ci sono sviluppatori che si sentono a proprio agio con entrambi gli stili, che dicono che gli ORM sono più popolari ora e avrai sicuramente un pool di talenti più grande disposto a lavorare con un ORM, questo non è necessariamente un miglior pool di talenti.

Hai preso in considerazione l'ipotesi di assumere i tuoi sviluppatori e poi lasciarli decidere quale architettura usare? In questo modo ti assicurerai di non escludere gli sviluppatori dal processo di selezione semplicemente perché non gradiscono l'architettura che hai scelto. Ottenere il miglior team di sviluppatori possibile è la cosa più importante per garantire che il tuo progetto abbia successo, e con più opzioni tra cui scegliere potresti trovare sviluppatori migliori con cui stai lavorando.

Le persone sono più importanti dell'architettura.

Si desidera creare un database con tutto il codice di accessibilità e la logica aziendale e quindi assumere gli sviluppatori per creare una sorta di interfaccia utente. Stai assumendo molte responsabilità di sviluppo qui e non dando agli sviluppatori abbastanza spazio per svolgere il loro lavoro. C'è qualche ragione per cui non pensi di assumere personale competente che possa aiutarti a capire tutto questo?

Ecco le risposte alle tue domande:

1. O le persone che assumi sanno come seguire i requisiti utilizzando un ORM o non lo fanno. Si chiama delete, ma è davvero un aggiornamento del record cancellato / cancellato.
2. I livelli intermedi non consentono solo ad altre app di condividere il codice, ma compiono una separazione di preoccupazioni. Se un nuovo sviluppatore vuole sapere dove si trova la logica di business, probabilmente guarderà al livello intermedio, ma nel tuo caso sarà sorpreso di trovarlo nel tuo database.
3. Non utilizzo più livelli / astrazioni riguarda la gestione di set di dati di grandi dimensioni. Riguarda anche la manutenibilità. Si presume che i set di dati di grandi dimensioni siano più complessi, ma non è sempre il caso.
4. Gli sviluppatori non sono d'accordo, ma se scegli i proc memorizzati su un orm, è meglio sapere cosa stai facendo da quando gestisci la logica di business. Potrebbero aver avuto brutte esperienze con un DBA che non l'ha fatto. Inoltre, puoi tenere il passo con le loro richieste o sarai un collo di bottiglia. In tua assenza, sono bloccati a lavorare con procs, quindi a loro non piacerà a lungo termine.

1. Chiama il metodo di eliminazione, che imposta il flag di cancellazione e aggiorna l'oggetto. Gli ORM hanno alcune funzionalità notevoli oltre alle semplici operazioni CRUD. E consentono ancora SQL come ripiego.

2. Se con "l'applicazione" intendi l'interfaccia utente, la vera ragione del livello intermedio è che non hai un design "Smart UI" che diventa sempre più difficile da mantenere e migliorare. Invece, ora hai separato le preoccupazioni. La possibilità di aggiungere un nuovo front end è uno dei vantaggi di separare le preoccupazioni.

3. Attacca con 3 per iniziare. Persistenza dei dati (aka, database). Modello di dati Interfaccia utente. Andando oltre, all'inizio, a meno che tu non sappia veramente quello che stai facendo, lo stai ipnotizzando.

4. Questo dipende dal motivo per cui lo stai dicendo. Per un sistema nuovo di zecca, non ancora costruito, se non eri onesto con questo e stai dettando legge, sarà preso come microgestione e spaventerà gli sviluppatori che hanno altre opzioni (e quelli sono quelli che più voglio mantenere). Se non si dice ORM perché abbiamo un'applicazione di produzione aziendale senza uno e sarà troppo lavoro per aggiungerlo, ma si rimane aperti ad essere convinti altrimenti in futuro, sarà meglio.

Se prevedi di assumere gli sviluppatori dall'inizio, prendili e invitali a fare queste chiamate. Se vuoi ottenere un prodotto da solo e sei preoccupato di crearlo una volta che diventa un successo e avrai bisogno di una squadra più grande, archivialo sotto "Problemi che voglio avere" e scegli ciò che mai sarai più probabile ottenere un progetto di lavoro con.