Entity framework e Eager loading e enterprise application con approccio TDD

3

Stiamo provando a creare un'applicazione ASP.NET MVC 4 utilizzando il framework di entità con un approccio basato sul modello di stile di sviluppo basato sul dominio. Come puoi vedere nella nostra parte del livello dominio, abbiamo un design complesso. Dobbiamo caricare l'entità con metodi pigri e desiderosi. Sfortunatamente abbiamo un grosso problema con questi metodi nel framework di entità.

Come comprendiamo, per il carico entusiasmante in EF dobbiamo usare il metodo Include e dare una stringa di proprietà e proprietà delle proprietà ecc. (In Hibernate e java potremmo usare annotation top of member per caricare con entusiasmo ed è stato molto più facile di questo approccio). Ma il problema orribile è che abbiamo strutture ereditarie e un pesante polimorfismo, in questi stati non abbiamo quella stringa che dovremmo includere perché non sappiamo quale classe di classe derivata sia selezionata per capire quali proprietà dovrebbero includere.

Ad esempio, come puoi vedere un risultato ha una collezione di elementi e poi decide di aggiungere un gruppo a questa raccolta e ognuno di questi gruppi ha alcuni gruppi e campi (come il modello di composizione). Ora immagina di voler caricare un risultato come quello parlato sopra. Quando voglio scrivere una stringa di data include non so quali elementi di questo risultato sono gruppi. Perché non possiamo prevedere che questi elementi siano gruppi e quindi questi gruppi hanno una raccolta di elementi che dovrebbero essere caricati.

this.Items = new List<Item> 
            {
                new Group(
                    a,
                    new List<Item>
                    { 
                        new Field(b),
                        new Field(c),
                        new Field(d),

Finalmente abbiamo una domanda critica: la struttura delle entità è progettata per le applicazioni aziendali con un dominio complesso e un approccio DDD? In caso negativo, come seguiamo l'approccio di Martin Fowler e Eric Evans nell'ingegneria del software e nell'applicazione aziendale in C #?

    
posta sorosh_sabz 15.11.2013 - 09:33
fonte

1 risposta

3

is entity framework designed for Enterprise Applications with a complex domain and DDD approach?

Questo potrebbe essere solo io, ma devo ancora trovare un ORM che ti permetta di creare un modello DDD pulito e di farlo mappare perfettamente al modello di dati relazionali. Hai sempre bisogno di un certo livello di modifica del tuo DDD per supportare la mappatura ORM. Il carico pigro è uno di questi. Ho notato che il requisito per le proprietà pubbliche o per i costruttori senza parametri è

If not, how we follow the approach of Martin Fowler and Eric Evans in software engineering and enterprise application in C#?

Penso che l'idea originale di DDD fosse che c'era uno strato di persistenza su DDD specificamente adattato per quel modello specifico. Abbastanza spesso andando al livello più basso di puro SQL. Gli ORM essendo framework generici non hanno il lusso di quel modo specifico di mappatura. Alcuni, come ibernato, si avvicinano semplicemente per via della loro scala e della quantità di funzioni. Ma continuo a pensare che i mapper ORM non possano generalmente essere utilizzati per mappare il DDD progettato correttamente per relazionale senza modifiche al modello DDD.

    
risposta data 15.11.2013 - 09:48
fonte