Modello di deposito e logica aziendale

Question

Ho un repository ( CustomerRepository ) che recupera i dati dal livello dati. La maggior parte della logica aziendale appartiene alla classe di entità ( Customer ) che il repository accetta o restituisce.

Tuttavia, dove metti la logica di business dell'entità globale (che si applica a tutti i clienti)?

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

Answer 1

Sono d'accordo con Robert Munteanu.

Fondamentalmente arrotoli la tua logica aziendale che non è inerente al tuo modello in un livello intermedio. Il livello intermedio è il livello aziendale / oggetti business / livello di logica aziendale / ecc., Ma viene appena chiamato livello di servizio. Non deve essere un servizio Web, è un ampio uso del termine servizio in quanto aggrega la funzionalità di un'area specifica dell'applicazione.

In pratica si avrebbe una classe CustomerService che contiene il riferimento al repository. Il livello di presentazione farebbe riferimento alla classe del livello di servizio.

Esiste un'ulteriore distinzione che può essere fatta come un'ipotesi dal tuo nome che stai usando .net e probabilmente usando LINQ to SQL come repository come indicato in NerdDinner.

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

Answer 2

Avvolgilo dietro un servizio.

Answer 3

Inseriscilo in un altro repository (BusinessRuleRepository) e utilizzalo per CustomerRepository.

OPPURE

Se la logica aziendale limita solo i risultati che un utente può vedere, potresti voler utilizzare un modello di facciata con una fabbrica. In questo caso avresti un ICustomerRepository che gestisce il tuo CustomerRepository e LimitedCustomerRepository (che potrebbe incapsulare CustomerRepository) e un CustomerRepositoryFactory che restituisce l'ICustomerRepository appropriato per l'utente.

Answer 4

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

Di recente ho creato un sistema per eseguire previsioni complesse con molte entità utilizzando dati storici. Inserimento di tutti i bit di accesso ai dati nel repository per ciascuna entità. La complessa logica di previsione che ho conservato in un livello di servizio e in cui ho passato gli oggetti del repository secondo necessità.

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