ORM e architettura basata su componenti

Sembra un layout relativamente pulito e incapsulato delle strutture di dati sottostanti.

Mentre ci sono argomenti da fare contro l'incapsulamento, non sono sicuro che nessuno di loro sia valido in questo caso. (Né sono validi in ogni caso, ma sto cercando di essere generoso qui e non mostrare il mio pregiudizio.)

Ecco alcuni dei vantaggi che vedo ottenere:

• Facile capacità di identificare le strutture necessarie per assemblare le informazioni. In questo modo si traduce in una curva di apprendimento più breve nella comprensione dell'applicazione.
• Ambito chiaramente definito per ciò che deve essere testato quando si verificano cambiamenti.
• Flessibilità di adattare la logica aziendale mentre l'azienda cambia alle strutture dati sottostanti.

Comprensibilmente, non puoi fornire tutti i dettagli dello stack di applicazioni. Quindi, presumibilmente, stai incontrando problemi e / o ti sembra ingombrante apportare cambiamenti a livello di business logic. Hai preso in considerazione l'aggiunta di un livello intermedio che fornisce gli oggetti composti che stai cercando?
In altre parole, avere un oggetto che combina fatture + informazioni sul cliente in modo che la vista o il modello di visualizzazione possano manipolare quell'oggetto invece di avere due oggetti diversi con cui lavorare.
Lo svantaggio di questo approccio è che è più codice da scrivere e mantenere. Potrebbe valere o meno lo sforzo aggiuntivo.

La mia regola generale quando si tratta di ORM è di mantenere un componente per schema di database, se si dispone di componenti separati per gestire lo stesso database, sarei d'accordo sul fatto che manchi dei vantaggi di ORM.