Conception de couche métier/service n-couche

Question

J'essaie de réévaluer notre architecture n-couche et j'aimerais avoir quelques suggestions basées sur vos expériences. Voici notre conception typique n-couche .NET (parfois n-tier).

Project.UI 
Project.Services 
Project.Business 
Project.Model 
Project.DataAccess 

DataAccess se compose généralement de Entity Framework 4 et Repository classes. Je tente de suivre le concept Aggregate Root afin d'éviter d'avoir un référentiel pour la table, plus facile à dire qu'à faire dans mon expérience. J'ai tendance à avoir une correspondance d'environ 70% entre les dépôts et les tables.

Le modèle se compose généralement de mes entités Entity Framework 4, j'utilise avec succès les entités EF Self-Tracking.

Business est ce que je lutte avec le plus. J'ai généralement une classe Manager pour chaque Repository. Cette classe contiendra des méthodes telles que .Add() qui effectuera une validation métier avant de les transférer vers repository.Add().

Services, typiquement je ne mettrai en œuvre que si en fait je cherche à créer une solution basée sur le service Web. Cette couche sera chargée de marshaler les demandes/réponses entre les DTO et les entités. Et surtout fournir l'interface plus coarse grained. Par exemple, un TradingService.SubmitTrade(), qui est vraiment un facade pour une transaction commerciale qui pourrait inclure AccountManager.ValidateCash(), OrderManager.SubmitOrder(), etc.

Préoccupations
Ma couche d'affaires est très entité centré, c'est vraiment le lien entre les entités et le référentiel, avec validation entre les deux. J'ai vu de nombreuses conceptions où le Service Layer est ce qui contient une référence aux dépôts (en ignorant par essence la "couche de gestion"). En substance, il sert le même but que ma couche d'affaires, il effectue la validation, mais sa responsabilité (et son nom) est un niveau plus élevé, une transaction commerciale plus grossière. En utilisant l'exemple ci-dessus, TradingService.submitTrade() ne délèguera pas à des classes de business manager, il interrogera lui-même les dépôts nécessaires, effectuera toutes les validations, etc.

J'aime mon design dans le sens où je peux réutiliser une entreprise méthode de couche dans plusieurs appels de service, mais je déteste le fait que pour chaque référentiel, j'ai un gestionnaire de couche de gestion correspondant, ce qui crée des tonnes de travail supplémentaire. Peut-être que la solution est un type différent de regroupement au niveau de la couche Business? Par exemple, combinez des classes Manager individuelles telles que PhoneManager et EmailManager (notez que j'ai les entités Phone et Email) dans une classe Logical Manager telle que ContactsManager (notez que je n'ai pas de type d'entité "Contact"). Avec des méthodes telles que ContactManager.GetPhones() et ContactManager.GetEmail(), etc.

Je suppose plus que tout que je me demande comment les autres organisent et délèguent des responsabilités, qu'ils aient la couche de service, la couche de gestion, les deux, etc. Ce qui contient la référence de contexte ORM, etc.

Answer 1

J'ai tendance à faire ce que vous avez décrit à la fin de vos préoccupations, et au niveau de la couche de gestion, regroupez les choses dans des gestionnaires qui ont plus de sens logique d'un point de vue commercial.

En utilisant les contacts par exemple, je n'aurais certainement pas PhoneManager ou EmailManager. "ContactsManager" est un regroupement plus utile pour moi, accomplissant à peu près la même chose seulement avec beaucoup moins de gestionnaires à traiter. D'un point de vue commercial, les numéros de téléphone et les courriels ne sont que de petits morceaux d'un Contact. Juste parce qu'ils ont leurs propres tables et entités ne signifie pas qu'ils ont besoin de leur propre gestionnaire. Cela ne signifie pas que vous ne pouvez pas les réutiliser.Si vous avez besoin de travailler avec des adresses e-mail à plusieurs endroits, ContactsManager peut avoir les méthodes appropriées. Ce que nous avons tendance à avoir dans notre environnement est une couche base de données/entité, puis une couche métier qui se trouve sur le serveur et gère les règles métier et la logique métier. Cette couche de gestion est exposée en tant que service via le WCF au client (ou du moins, ce qui est pertinent pour les clients). Il semble que vous sachiez déjà ce que vous voulez faire, donc je vous suggère de faire un peu de travail de prototypage et de voir comment cela fonctionne pour vous. :)