2009-06-18 10 views
9

Ho un repository (CustomerRepository) che recupera i dati dal livello dati. La maggior parte della logica aziendale si trova nella classe di entità (Customer) che il repository accetta o restituisce.Schema del repository e logica aziendale

Tuttavia, dove si inserisce la logica aziendale dell'entità globale (applicabile a tutti i clienti)?

Per esempio, potrei non voler restituire tutti i clienti a determinati utenti. Non voglio mettere quella logica nel repository.

risposta

19

Sono d'accordo con Robert Munteanu.

Fondamentalmente si imposta la logica aziendale che non è inerente al modello in un livello intermedio. Il livello intermedio è il livello aziendale/oggetti business/livello logico aziendale/ecc., Ma viene semplicemente definito livello di servizio. Non deve essere un servizio web, è un ampio uso del termine servizio in quanto aggrega funzionalità di un'area applicativa specifica.

Si dispone fondamentalmente di una classe CustomerService che contiene il riferimento del repository. Il tuo livello di presentazione farebbe riferimento alla classe del livello di servizio.

C'è un'ulteriore distinzione che può essere fatta come ipotesi dal nome che si sta usando .net, e probabilmente usando LINQ to SQL come repository come delineato in NerdDinner.

Il repository restituisce in genere IQueryable al livello di servizio, consentendo al livello di servizio di concatenare più query per creare set di risultati diversi. Il servizio valuta quindi l'espressione utilizzando ToList o un altro metodo simile e lo restituisce al livello di presentazione.

+1

MVC Storefront di Rob Conery è ciò che mi ha trasformato nel modello di repository, ma sfortunatamente ha rifattorizzato il livello di servizio senza spiegare veramente quella decisione nei video. Quindi ero preoccupato che forse non era il modo migliore. –

+11

Mi sono trovato di fronte a un problema simile, è questa la migliore architettura? Ho smesso di preoccuparmi delle interfacce con i contratti di livello superiore con le fabbriche e mi sono concentrato sul farlo funzionare. Trovo troppo spesso che le persone siano in grado di superare le soluzioni di architetti. Lo scopo è costruire questo momento di un codice base, un tributo alla propria potenza e alla perfezione di livelli e livelli? Penso che finché conservi i tuoi dati nel tuo repository, la tua "logica di business" nei tuoi servizi aziendali e la tua interfaccia utente nelle tue Views sei a posto. Realizzare ciò che il software dovrebbe fare, refactoring come si va – blu

+0

e realizzare l'obiettivo del software. – blu

5

Avvolgere dietro un servizio.

+4

Che cosa significa in questo caso? –

+0

Penso ai servizi come a un posto per tutto il resto nel modello di dominio. – Min

+1

Accetto. Crea CustomerService con un metodo, dove il tuo aggiornamento è rivolto a tutti i clienti. – Gengzu

4

Inserirlo in un altro repository (BusinessRuleRepository) e utilizzarlo come CustomerRepository.

O

Se la logica di business sta limitando solo i risultati di un utente può vedere si potrebbe desiderare di utilizzare un modello di facciata con una fabbrica. In questo caso, si disporrà di un repository clienti IC che gestisce il proprio repository clienti e il repository clienti limitati (che potrebbe incapsulare il repository clienti) e una customer repository factory che restituisce il repository clienti appropriato per l'utente.

0

Penso che separare questi tipi di funzioni in un livello di servizio sia la strada da percorrere.

Ho recentemente creato un sistema per eseguire previsioni complesse con molte entità che utilizzano dati storici. Mettere tutti i bit di accesso ai dati nel repository per ciascuna entità. L'intricata logica di previsione che ho tenuto in un livello di servizio e ho inoltrato gli oggetti del repository in base alle necessità.

Il bonus aggiuntivo era che avevo un modo semplice per esporre tutta la logica di previsione a sistemi esterni semplicemente creando un livello API web.

Problemi correlati