In che modo un processo agile interagisce con ORM?

1

Questa domanda è stata richiesta da questa risposta , dove cito," agile + ORM su un grande database in continua evoluzione è brutale ".

Quindi, come può un processo agile gestire un database in costante cambiamento? Sono interessato a entrambi i casi:

  1. Dove verrà stabilita la progettazione del database, dopo averlo usato per un po 'di tempo per vedere come funziona
  2. Dove gli schemi di dati in costante evoluzione richiedono che il database cambi spesso

Un paio di idee che ho avuto sono state:

  • Utilizza un database NoSQL
  • Creazione di tabelle chiave / valore per diverse classi di dati. Questo potrebbe creare tabelle più grandi, ma potrebbe funzionare bene per i dati che non sono intrinsecamente relazionali.
posta Michael K 31.01.2011 - 16:29
fonte

2 risposte

5

Innanzitutto, la risposta elenca due "problemi" che non hanno quasi nulla a che fare con Agile o ORM.

When it's not nice and simple, the SQL will be garbage.

Questo significa che il database è stato mal progettato fin dall'inizio. Molte persone non riescono a pensare chiaramente a come SQL deve funzionare, a progettare database scadenti e quindi a modificare l'SQL per farlo funzionare.

ORM richiede un pensiero molto chiaro sugli oggetti, le loro relazioni e la navigazione tra gli oggetti. La progettazione del database è qui il problema, non l'ORM e non i metodi Agile.

Our database is constantly changing. That means every couple of days someone needs to spend an hour updating the model to add a table or change datatypes that are changing (agile + ORM on a large constantly changing database is brutal).

L'alternativa senza ORM potrebbe essere settimane per cambiare il modello e correggere tutte le query SQL. Il fatto che sia solo un'ora ogni due giorni è un girone di approvazione.

Tutti i cambiamenti possono essere "brutali". Questo è un dato di fatto. Agile è una risposta di gestione (non una risposta tecnica). Il cambiamento è ancora molto lavoro. Un ORM spesso riduce al minimo tale lavoro. Questo "problema" è la prova che ORM ha un buon ritorno sull'investimento.

So, how can an Agile process deal with a constantly changing database?

Si occupa molto bene.

Where the database design will stablelize, after using it a while to see how it works

Non c'è dubbio qui. Questo è il caso ideale. Il cambiamento rallenta.

Where constantly changing data schemas require that the database changes often.

Agile è una risposta di gestione a un cambiamento costante. Non una risposta tecnica. La risposta tecnica al cambiamento costante è - beh - cambiamento costante. Siamo spiacenti.

La gestione agile riconosce che il cambiamento è costante e pianifica i progetti di conseguenza. Una gestione non agile richiede che tutti i progetti vengano completati prima di qualsiasi implementazione, e tutte le modifiche comportano complesse procedure di controllo delle modifiche e straordinari straordinari per evitare ritardi dei progetti e molte altre cattive pratiche di gestione.

Le pratiche tecniche sono le stesse. Correggi il modello. Correggi il livello ORM.

    
risposta data 31.01.2011 - 16:52
fonte
0

Penso che l'uso di strumenti che automatizzano il database da entità di dominio è la strada da percorrere in molti casi (ad esempio, Fluent NHibernate). Quindi ti rimane la possibilità di creare convenzioni / sostituzioni in cui l'automapping non fa ciò che vuoi.

    
risposta data 31.01.2011 - 17:08
fonte

Leggi altre domande sui tag