dove va la modella?

Question

Ho una soluzione VS, con i seguenti progetti.

-gui
-DataAccess
-BusinessLogic
-BusinessObjects

ma dove dovrebbe risiedere la classe del modello principale? Di solito si tratta di una cache di un insieme di oggetti che sono i risultati del livello di accesso ai dati e della GUI che utilizza griglie virtuali per visualizzare i dati all'interno del modello. La domanda sarebbe la stessa usando MVC o MVP

pensieri?

Answer 1

Questa è una domanda soggettiva, ma spesso per imporre che i tuoi oggetti modello non abbiano dipendenze dirette con l'infrastruttura, le persone spesso li inseriscono in un progetto separato. devi anche considerare quali altri progetti potrebbero usare questi oggetti modello.

Un'altra opzione per suddividere la funzionalità in unità dispiegabili separate (assiemi) è che i team possano funzionare in modo più indipendente. Separare i progetti in base alla frequenza di implementazione e all'autonomia del team.

Infine, ho visto alcuni progetti in cui gli oggetti del modello sono stati richiamati in remoto (come con .NET remoting) e offerti su un server delle applicazioni separato dal web server. Non raccomando davvero questo approccio, ma è un'opzione.

Se non prevedi di riutilizzarli e sei consapevole del fatto che inserirli nello stesso assembly ti consente di creare dipendenze incrociate con qualsiasi altra cosa definita in quel progetto, ma sei abbastanza intelligente da non farlo, puoi metterli tutti nello stesso progetto.

Detto questo, il 99% delle volte ho questi progetti:

• UI
• Nucleo
• Persistenza
• Test

Ma devi ancora tener conto delle esigenze del tuo progetto.

Answer 2

Tendo ad avere

• Justice.Project.Core - il modello di dominio POCO - ovvero oggetti business)
• Justice.Project.Data - mapping NHibernate ecc., in cui risiede lo schema di persistenza
• Justice.Project.Services - repository, nonché logica aziendale che non può essere facilmente inserita negli oggetti business
• Justice.Project. (Web | UI)

Il modello è - oppure dovrebbe essere - gli oggetti business.

Answer 3

Le mie soluzioni hanno 3 progetti (non test)

1. UI - ovvio
2. Core: tutti gli oggetti di dominio e la logica aziendale
3. Accesso ai dati - Pattern di repository per popolare / salvare oggetti Modello

Answer 4

  

Sono d'accordo che gli oggetti del modello entrino   POCO. quindi diciamo che ho un ordine   oggetto. La mia domanda è dove devo avere   la classe che archivia una raccolta di   ordini ??

Dipende dalla tua azienda. Molto probabilmente avrai una raccolta di ordini in alcuni posti diversi ...

Sull'oggetto cliente, ogni cliente dovrebbe avere una raccolta di ordini, quindi tu ne avresti uno lì.

Se si dispone di dipartimenti, ogni reparto dovrebbe avere una raccolta di ordini che ha creato.

Se si dispone di magazzini, ogni magazzino può avere una raccolta di ordini che sono responsabili del loro adempimento.

Alcuni oggetti non hanno un genitore, e va bene. Nel mio sistema, abbiamo clienti. Il proprietario dei clienti nel mondo reale siamo noi (l'azienda), ma non ci sono " Us " oggetto nel sistema. Se stai cercando un elenco dei tuoi clienti (nel nostro caso), chiediamo al repository di farlo.

IRespoistory<Client> repository = new Repository<Client>();
IList<Client> clients = repository.GetAllClients();

Lo stesso potrebbe valere per i tuoi ordini.

Consiglio di dare un'occhiata a questo libro DDD: http: //www.amazon .com / gp / prodotto / 0321268202 / ref = s9k2a_c1_at1-rfc_p-3237_p pf_rd_m = ATVPDKIKX0DER & amp;? pf_rd_s = centro-1 & amp; pf_rd_r = 1BWAPTN787CTZXJDV5BA & amp; pf_rd_t = 101 & amp; pf_rd_p = 463.383.351 & amp; pf_rd_i = 507846