Le prove attuali supportano l'adozione di Modelli di dati canonici contestuali?

Question

Le prove attuali supportano l'adozione di Modelli di dati canonici contestuali?

#1 da (5 voti)

7

L'idea "canonica" è pervasiva nel software; modelli come Modello canonico , Canonical Schema , Canonical Data Model e così via, sembrano venire ancora e ancora in sviluppo.

Come molti sviluppatori, ho seguito spesso, acriticamente, la saggezza convenzionale secondo cui hai bisogno di un modello canonico, altrimenti ti troverai di fronte a esplosione combinatoria di mappatori e traduttori. O almeno, io ho usato per farlo fino a un paio di anni fa quando ho letto per la prima volta il famigerato EF voto di non fidarsi :

The hypotheses that once supported the pursuit of canonical data models didn’t and couldn’t include factors that would be discovered once the idea was put into practice. We have found, through years of trial and error, that using separate models for each individual context in which a canonical data model might be used is the least complex approach, is the least costly approach, and the one that leads to greater maintainability and extensibility of the applications and endpoints using contextual models, and it’s an approach that doesn’t encourage the software entropy that canonical models do.

Il saggio non presenta alcuna prova a supporto delle sue affermazioni, ma mi ha fatto dubitare dell'approccio CDM abbastanza a lungo da provare l'alternativa, e il software risultante non è esploso, letteralmente o in senso figurato. Ma questo non significa molto in isolamento; Potrei essere stato solo fortunato.

Quindi mi chiedo, sono state fatte serie ricerche sugli effetti pratici a lungo termine di avere un modello canonico rispetto a modelli contestuali in un sistema o un'architettura software?

Oppure, se è troppo presto per chiederglielo, chiedi a sviluppatori / architetti di parlare di esperienze personali passando da un CDM a modelli contestuali indipendenti, o viceversa, e quali sono stati gli effetti pratici su cose come produttività, complessità, o affidabilità?

Quali sono le differenze a diversi livelli, ovvero utilizzando lo stesso modello in una singola applicazione o utilizzandolo in un sistema di applicazioni o in un'intera azienda?

(Solo fatti, per favore: storie di guerra sono benvenute ma nessuna speculazione.)

architecture design-patterns domain-model data

posta Aaronaught 27.04.2011 - 18:39

fonte

1 risposta

Leggi altre domande sui tag architecture design-patterns domain-model data

Spostamento tra gli schemi XML e le classi C # in modo ragionevole Esiste una risorsa canonica su ERP? [chiuso]

score 5 · Answer 1

In risposta all'articolo EF Vote of No Confidence , scrive Tim Mallalieu:

We are not recommending that folks return to the days where we were evangelizing the use of XSD for “canonical schemas”. I don’t believe that people think that this is tractable. What we do believe, however, is that it is desirable to have a single meta-model (EDM if you will) with which you can describe many domain models and that by having a single grammar we can provide a set of common services on any given domain model.

For example, consider an application that is to be written against a database with 600 tables. Do I believe that this app should have a single model with 600 Entity Types in it? No… Furthermore, do I believe that any given domain entity (say Customer) has only one shape in that app and that this shape must be the canonical shape for the entire Enterprise?… Heck no.

L'articolo di Wikipedia per il modello canonico fa riferimento a Enterprise Service Bus , Architettura orientata ai servizi e CORBA , cose che sembrano come loro ' di cui non abbiamo più parlato. Sono stati tutti posti come soluzione per la proliferazione dei dati e le sfide di comunicazione dell'impresa, il One Ring to Rule them. ^TM hanno avuto successo? Oppure sono crollati sotto il loro stesso peso?

Hai chiesto esperienze personali, quindi te ne darò una. Nell'industria aerospaziale usiamo molto la telemetria. Una delle sfide con i sistemi di telemetria è trovare un modo per diversi intervalli di test per comunicare i dati di test l'uno con l'altro in modo significativo. Questo problema sembra abbastanza semplice, finché non provi a definire un dizionario di dati di termini comuni.

Che cosa significa "altitudine"? E 'l'altezza sopra il terreno, o è l'altezza sopra il livello del mare? Cosa succede se stai parlando di un sottomarino? Quindi la sua profondità, non l'altitudine. Per l'esercito, la parola "trasmissione" ha un significato diverso quando ti riferisci a un radar piuttosto che a un veicolo terrestre. La superficie dell'ala che fa rotolare un aereo è chiamata "alettone" su alcuni piani e un "elevone" su altri.

Questo è solo un suggerimento sulla montagna dei problemi che seguono. Sebbene esistano standard per le comunicazioni di dati, ogni intervallo di test è diverso e ha esigenze, obiettivi e priorità diversi. Gli standard possono differire anche tra diversi progetti della stessa gamma. Per questo motivo, le gamme di test comprendono che la soluzione non verrà sostituendo tutto con un unico sistema monolitico, ma concordando semplici protocolli di comunicazione e fornendo modi per tradurre dal vocabolario di una gamma a un'altra.

I problemi che affrontano le grandi aziende sono simili. Microsoft tende a pensare in termini monolitici, ma questo perché la loro azienda è, nel complesso, monolitica. Non appena hai bisogno di comunicare tra diverse aziende con culture e modi di fare business molto diversi (o anche tra reparti eterogenei della stessa azienda), One Ring to Rule them. ^TM inizia immediatamente a scomparire.