Modèle de référentiel et logique métier

Question

J'ai un référentiel ( CustomerRepository ) qui extrait les données de la couche de données. La majeure partie de la logique applicative se trouve dans la classe d'entités ( Client ) que le référentiel accepte ou renvoie.

Cependant, où placez-vous la logique commerciale de l'entité globale (qui s'applique à tous les clients)?

Par exemple, je ne souhaite peut-être pas renvoyer tous les clients à certains utilisateurs. Je ne veux pas mettre cette logique dans le référentiel.

Answer 1

Je suis d'accord avec Robert Munteanu.

En gros, vous transformez votre logique métier non inhérente à votre modèle en un niveau intermédiaire. Le niveau intermédiaire est le niveau métier, les objets métier, la couche de logique métier, etc., mais est simplement appelé niveau de service. Il n’est pas nécessaire qu’il s’agisse d’un service Web, c’est une utilisation large du terme service car elle regroupe les fonctionnalités d’un domaine d’application spécifique.

Vous disposerez d’une classe CustomerService contenant la référence du référentiel. Votre couche présentation ferait référence à la classe de couche service.

Il existe une distinction supplémentaire qui peut être faite en supposant que votre nom utilise le .net et que vous utilisiez probablement LINQ to SQL comme référentiel, comme indiqué dans NerdDinner.

Le référentiel renvoie généralement IQueryable à la couche de service, ce qui permet à la couche de service de chaîner plusieurs requêtes pour créer différents ensembles de résultats. Le service évalue ensuite l'expression à l'aide de ToList ou d'une autre méthode similaire et la renvoie à la couche de présentation.

Answer 2

Enveloppez-le derrière un service.

Answer 3

Placez-le dans un autre référentiel (BusinessRuleRepository) et demandez à CustomerRepository de l'utiliser.

OU

Si la logique métier ne fait que limiter les résultats visibles par l'utilisateur, vous pouvez utiliser un motif de façade avec une fabrique. Dans ce cas, vous aurez un ICustomerRepository qui gère votre CustomerRepository et votre LimitedCustomerRepository (qui peut encapsuler CustomerRepository), et un CustomerRepositoryFactory qui retourne le ICustomerRepository approprié pour l'utilisateur.

Answer 4

Je pense que la séparation de ces types de fonctions dans une couche de service est la voie à suivre.

J'ai récemment construit un système permettant d'effectuer des prévisions complexes avec de nombreuses entités utilisant des données historiques. Mettre tous les bits d'accès aux données dans le référentiel pour chaque entité. La logique de prévision complexe que je conservais dans une couche de service et transmettais les objets de référentiel selon les besoins.

En outre, j’avais un moyen simple d’exposer toute la logique de prévision aux systèmes externes en créant simplement une couche d’API Web.