Service dans Enterprise level application architecture

Bonjour ,
je travaille sur une Enterprise level application architecture avec Web APIs et Entity Framework, Generic Repository pattern et Unit of Work.
mon projet consiste à créer une application de gestion de budget familial.
j'ai conçu mon architecture comme suit :

couche de la base de donnée : contient la base de donnée.

couche modele de donnée : contient les objets générés avec entité framework + un repository générique et unit of work .


couche service et couche de ApiController.


ma question est la suivante :

est ce que je dois créer une classe service pour chaque entité c-à-d : UtilisateurService,PortefeuilleService ..etc ?

ou:


un service pour chaque opération métier ex : Créer un portefeuille engendre a création de l'utilisateur +les comptes ect ?



merci d'avance

Salut,

Je ferai un service pour chaque responsabilite metier, donc plutot la seconde solution. Le premiere solution n'apportant que peu de plus value metier et ressemblant a un wrapper mal fichu.

Fais quelques tests,sans implementer les methodes

le problème est qu'au niveau du controlleur , on appelle le service pour effectuer des get, post ,..etc

si on fait un service par responsabilité métier comme vous dites, comment gérer alors les routes au niveau des controlleurs?

hmm je pense qu'il y a un soucis de communication.


De ce que j'ai compris t'as une archi avec:
database
dal via entity
une couche pour faire du crud supplementaire ?

Deja ou se situe pour toi le unit of work (bon en partant du principe que tu fais reference au pattern du livre de enterprise architecuture...) ?

Couche service et de ApiController
on parle ici de controller type mvc ou autre chose ?

Et la derniere remarque:

Citation:

---

si on fait un service par responsabilité métier comme vous dites, comment gérer alors les routes au niveau des controlleurs?

---

Les controlleurs (asp.mvc) n'ont jamais a gerer le routing c'est a une classe specifique (RouteConfig) de le faire. Mais a nouveau je crains de ne pas comprendre ce que tu veux dire.

euh dis moi dans ton archi ou se trouve la couche business alors ?

Voici l'architecture de mon projet :

Pièce jointe 204694

au niveau des service , j'ai pensé à faire un service par responsabilité métier example CréationPortefeuille: créer un nouveau portefeuille, on doit créer son utilisateur et les comptes par défaut de cet utilisateur :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

class CreationService : BusinessService.Services.ICreationService {   private readonly UnitOfWork _unitOfWork;   public int CreatePortefeuille(BusinessEntities.Portefeuille portefeuilleEntity) { using (var scope = new TransactionScope()) { var p = new PorteFeuille { designation = portefeuilleEntity.designation }; _unitOfWork.PortefeuilleRepository.Insert(p); //on rajoute l'user //ses comptes //..etc _unitOfWork.Save(); scope.Complete(); return p.id; } } }

---

maintenant , si on veut faire appel à ce service au niveau du controlleur , on fait comment ? sachant que cette méthode requiert plusieurs POST ?

Alors premier point d'interrogation tu creer une transaction, je pense qu'il faut la passer/utiliser dans les autres appels a la base de donnees:

Code:

---

_unitOfWork.PortefeuilleRepository.Insert(p);

---

De plus apparement tu fais de l'ioc, why not, mais dans ce cas, en profiter pour injecter aussi le scope/transaction. :roll:

Pour repondre a la derniere question:

Citation:

---

maintenant, si on veut faire appel à ce service au niveau du controlleur, on fait comment ? sachant que cette méthode requiert plusieurs POST ?

---

• Sois au fur et a mesure de la navigation tu creer un porteufeille temporaire ( en session de l'utilisateur par exemple)
• Sois tu creer le porteufeille en bdd avec un statut brouillon pa exemple.
• Sois tu te trimballes les informations du porteufeille de post en post via des champs caches

• via la premiere solution tu risques d'avoir une grosse session (si tu as de tres nombreux utilisateurs ca va piquer)
• via la seconde cela impacte la bdd donc risques potentiels d'impacts
• via la troisieme il ya deja pas mal de code a produire pour realiser la tache.

Perosnnellement j'opterai pour la premiere.

est ce que tu peux m'expliquer la première solution stp?

C'est bien de penser à bien structurer son application, d'utiliser les design pattern etc mais il ne sert a rien de complexifier une application qui est à la base simple.
Si ton projet de budget familial est vraiment complexe alors ok c'est mieux de passer par toute une série de couche mais si au final ton application n'est pas complexe il vaut mieux s'affranchir de toutes ces couches et de faire plus simple.

alors pour la premiere solution c'est assez simple:

imagonons que tu as 3 etapes pour creer ton portefeuille:
au premiere post :

Code:

---

1 2 3 4

var tmpPortefeuille = new tmpPortefeuille(); //remplissage des proprietes Session["Portefeuille"] = tmpPortefeuille;

---

au second post:

Code:

---

1 2 3

var tmpPortefeuilleSession["Portefeuille"] as tmpPortefeuille; //remplissage des proprietes suivantes Session["Portefeuille"] = tmpPortefeuille;

---

au troisiemepost:

Code:

---

1 2 3 4

var tmpPortefeuilleSession["Portefeuille"] as tmpPortefeuille; //remplissage des proprietes suivantes Session["Portefeuille"] = tmpPortefeuille; monService.CreeProtefeuille(tmpPortefeuille);

---