MVVM, DDD e WPF Guida alla struttura del progetto dell'applicazione stratificata

Question

MVVM, DDD e WPF Guida alla struttura del progetto dell'applicazione stratificata

#1 da (5 voti)
#2 da (2 voti)
#3 da (1 voti)

17

Sto provando a configurare la struttura della mia applicazione in VS e voglio "provare" e provarlo a un livello ragionevole. Questa applicazione sarà una riscrittura WPF di una vecchia app Winform che non ha seguito alcuna convenzione. Nessun livello, livello, acronimi, ecc.

È un'applicazione Enterprise piuttosto ampia. Ho pianificato di usare Linq To SQL come sono i miei DB e molto probabilmente sarà sempre MS SQL. Inoltre ho già un set di abilità esistente.

Voglio seguire MVVM e DDD il meglio che posso, ma mi confondo sulla struttura della mia applicazione quando li combino. Lasciatemi provare e illustrare con alcuni esempi.

Quando seguo MVVM, la struttura della mia cartella potrebbe essere simile a questa:

Views
Models
ViewModels
Helpers

ma come si inserisce in un semplicistico approccio a strati DDD in cui la mia struttura del progetto potrebbe assomigliare a questa:

MyApp.UI
MyApp.Domain
MyApp.Data

Metto il Models nel livello Dominio o ho 3 versioni di say Person ? Questo porta a un'altra domanda su dove metterei il mio repository e le mappature di oggetto DB su oggetto dominio? Supporrei Dati ...

Views I get entrerebbe nell'interfaccia utente ma anche ViewModels ?

Infine, dove inserirò la mia Business Logic?

Ho trovato quanto segue su CodePlex, Esempio DDD , ed è stato di aiuto, ma sembra essere per un'applicazione Web anche se potrebbe non avere importanza ed è la mia ignoranza a splendere.

Non fraintendermi, so che posso avere tante cartelle e chiamarle come voglio. Sto cercando di capire dove posizionare le cose in modo che questo possa essere scalabile, non è quello che vengono chiamati necessariamente quei luoghi.

Il cuore della mia domanda potrebbe essere mostrato in questo modo.
Ho tblPerson oggetto generato da *.dbml . Questo è ovvio e dovrebbe appartenere al mio livello "Dati".
Ora dovrei avere Model, DTO, Domain Model, o qualunque cosa si chiami in un layer separato (progetto?) Chiamato Person . Avrei bisogno di un Mapper per Person in tblPerson che non sono sicuro di dove mettere.
Quindi, avrò un ViewModel per, diciamo, EditPerson che avrebbe le sue proprietà che estrae da Person ma forse anche di più.
Finalmente avrei avuto una vista che era legata a quel ViewModel ....

Per essere chiari che il paragrafo è RIEMPITO con le mie supposizioni e congetture e spero che qualcuno mi aiuti a chiarire l'aria per me o offrirti intuizioni così da 6 mesi a un anno da ora non mi sto prendendo a calci più del necessario .

domain-driven-design .net wpf project-structure mvvm

posta Refracted Paladin 02.08.2012 - 21:46

fonte

3 risposte

Leggi altre domande sui tag domain-driven-design .net wpf project-structure mvvm

NP completo o NP hard problemi nella vita reale Se il tuo compagno di lavoro lascia il suo lavoro, vorresti avvisare il tuo capo? [chiuso]

score 5 · Answer 1

MVVM è un pattern dell'interfaccia utente e viene utilizzato in un client.

Le parti del dominio in DDD utilizzate nel client sono probabilmente (una parte del) Modello

View e ViewModel sono solo client.

Metto i Repository nel (o vicino) il Modello perché sincronizzano il Modello con il back-end.

Sì, molte volte questo risulterà in più classi Person in spazi dei nomi diversi. Potrebbero iniziare in modo molto simile ma potrebbero risultare molto diversi dopo un paio di iterazioni o versioni.

Modifica

Per chiarire la parte relativa ai repository e spiegare meglio il posizionamento di Business Logic

Se si sta creando un sistema che contiene un client separato e i repository lato server / back-end possono essere utilizzati nel client e nel server. Nel client per fornire un'astrazione del server (s) e nel server per fornire un'astrazione di altri server e origini dati. È solo uno schema.

Come per le regole aziendali: se le usi nel client assicurati di applicarle anche sul server. Non fidarti mai di un cliente. Le regole aziendali nel client consentono una rapida convalida dell'input e impediscono il round-trip al server.

Penso che DDD sia sul lato server e "perdite" al client.

score 2 · Answer 2

Hai giusta direzione nella scelta del modello di progettazione MVVM per l'applicazione WPF.

Do I put the Models in the Domain layer?

Sì, i tuoi modelli possono essere inseriti nel dominio

Where would I put my Repository and mappings of DB Object to Domain Object?

I repository possono essere posizionati nel livello in cui è posizionato il dominio. I tuoi oggetti di mappatura (detti anche DTO - oggetti di trasferimento del dominio) dovrebbero essere collocati nel tuo livello di servizio e potresti utilizzare un potente strumento di mappatura AutoMapper per mappare facilmente i tuoi oggetti di dominio su DTO.

ViewModels also?

I tuoi ViewModels dovrebbero essere posizionati sul lato client (livello). Puoi costruire i tuoi modellini visivi da uno o più DTO, a seconda delle tue visualizzazioni.

Riguardo a DDD , ti suggerisco di leggere su questo e chiarire che è necessario avere un Dominio guidato Design pattern. ecco una discussione che il 95% di tutte le applicazioni software rientra nelle categorie "non così buono per l'utilizzo di DDD".

Modifica: il riferimento è stato aggiunto sopra e grazie a @Den!

score 1 · Answer 3

Prima di approfondire cosa va dove, parliamo di cosa dovrebbe fare ogni strato.

Il punto di forza di MVVM è il legame tra la vista e il modello di vista. L'obiettivo qui è eliminare la logica all'interno della vista.
Come la vista, il modello dovrebbe essere abbastanza leggero e utilizzato solo per accedere alle informazioni (dati) necessarie per il funzionamento del modello di visualizzazione. Il modello può integrare l'accesso a diverse origini dati, ma non dovrebbe avere una logica aziendale. Nella maggior parte dei casi, hai un singolo archivio dati da colpire. In alcuni casi non lo fai. In caso contrario, è opportuno utilizzare il modello per oscurare l'origine dei dati dalla VM.

Un punto implicito di MVVM è che i dati sono già archiviati e il tuo progetto non è responsabile del mantenimento della sua organizzazione. Alcuni progetti hanno la fortuna di farla franca con questa ipotesi, la maggior parte dei progetti su cui ho lavorato non sono stati così fortunati. Basti dire che Data è un altro livello con cui dovremo fare i conti.

Disporrei il mio progetto in questo modo:

 project.Views
 project.ViewModel
 project.Model
 project.DataStructs

e questo livello può essere aggiunto in base alle esigenze:

 project.Helpers

Sto separando gli Helper dal resto dello stack in modo che non venga confuso come un livello dello stack di applicazioni.

Dichiarazione di non responsabilità: non sono un esperto di DDD, ma capisco l'essenza generale e vedo il valore nell'approccio.

Il tuo dominio sarà il set di problemi che stai prendendo in considerazione.
I Modelli di dominio corrisponderanno principalmente ai ViewModel che crei; un po 'all'interno dei Views; e un piccolo blocco all'interno del modello / DataStructs.

Quindi come andrà a finire?
SE hai la possibilità di modificare le strutture dei dati esistenti, quindi i nuovi che crei dovrebbero essere correlati al problema che stai provando risolvere. Hai un oggetto cliente? Quindi dovresti avere una / alcune tabelle relative al Cliente. Hai fatture o prodotti? Stessa storia: le tabelle e le strutture che si associano a quegli oggetti di business dovrebbero essere create.

Il Dominio verrà espresso tramite gli oggetti ViewModel e le Viste presenti di quegli oggetti. Se hai bisogno di modificare i record dei clienti, allora avrai una VM per la gestione di tale attività.

Rispondi alle tue domande:

Non provare a sovrapporre DDD su MVVM. Semplicemente non funzionerà. DDD non è un modello di layout, è un approccio per visualizzare il tuo problema generale.
Repository e Mappings vivranno in entrambi i project.Data o project.Model come appropriato.
Non hai un livello chiamato UI a meno che non sia quello che vuoi chiamare project.Views.
Business Logic andrà nel Modello di visualizzazione.