J’imagine que tu parles de MS Enterprise Library 4.1
[quote]Tout d’abord, j’ai deux tables : PRODUCT_TYPE (id_type, name);
PRODUCT (id_product, name, id_type#);
Dans ma Business Object Layer, je veux créer 2 classes : PRODUCT_TYPE and PRODUCT.
Est-ce que je dois respecter la base de données et mettre la propriété id_type dans ma classe PRODUCT ou est-ce que je dois mettre une instance de PRODUCT_TYPE dans PRODUCT ? C’est quoi le mieux ? Comment vos faites dans vos applications ?[/quote]
La méthode la plus respectueuse de la modélisation objet, mais qui nécessite l’emploi d’un ORM (ADO.NET Entity Framework, LinqToSql, NHibernate, etc. mais pas Data Access Application Block) serait celle qui te permettrait d’utiliser les propriétés et masquerait les IDs.
La méthode la plus rapide, demandant le moins de code d’infrastructure serait de laisser les identifiants numériques et de créer ces objets en tant que « conteneurs de données ». Et là je te renvoie sur les « Anemic Domain Model » et les problèmes de conception que cela soulève.
[quote]J’ai aussi une question pour ma Data Access Layer. Quand j’ajoute un Employé dans ma base de données, je peux aussi (mais c’est pas une obligation) référencer son contrat (j’ai deux tables : CONTRACT and EMPLOYEE).
Dons, dans ma DAL, j’ai 2 méthodes : CreateEmploye(Employe unEmploye) et CreateContrat(Contrat contrat, Employe unEmploye).
J’aimerais créer une méthode CreateEmployeAvecContrat qui insèrerait dans ma base de données un employé et son contrat en même temps.
Pour faire ça, je pensais utiliser les transactions SQL (commit et rollback).
Je ne sais pas comment je dois faire…
Est-ce que je crée une méthode dans ma Business Logic Layer qui crée la transaction et qui appelle CreateEmploye et CreateContrat (en passant la transaction en paramètre) ? Ou est-ce que je fais dans ma DAL la méthode CreateEmployeAvecContrat qui exécutera la requête et s’occupera de gérer la transaction ?
Est-ce qu’un BLL peut avoir accès à la transaction SQL (dans le cas où je la créerais dans la BLL) ? Est-ce qu’elle peut ouvrir une connection à une base de données ? Je ne pense pas…
Qu’est ce que vous en pensez ? Comment vous feriez ?[/quote]
Deux méthodes là aussi :
- Méthode rapide, tu découvres TransactionScope, disponible dans System.Transaction et qui permet de gérer une transaction automatique qui sera utilisé par ta DAL. Tu gardes tes deux méthodes de DAL et tu démarres un TransactionScope dans ton code BLL.
using (var scope = new TransactionScope())
{
dal.CreateEmployee(employee);
dal.CreateContract(contract, employee)
scope.Commit();
}
- Méthode plus poussée : tu t’intéresses au pattern UnitOfWork qui masque l’utilisation du TransactionScope pour le rendre plus générique (et moins lié à l’accès aux données.
[code]using (IUnitOfWork unitOfWork = UnitOfWork.Create())
{
dal.CreateEmployee(employee);
dal.CreateContract(contract, employee)
unitOfWork.Complete();
}[/code]
La nuance avec l’exemple précédent, c’est que c’est toi qui décide ce que tu souhaites faire dans ton commit. Pour encapsuler ton premier développement, tu appelles scope.Complete(). Dans un autre cas (utilisation d’un ORM), tu valides les opérations sur la session (NHibernate) ou le DataContext (LinqToSql), etc. sans modifier ton code métier.
Tout cela devrait te fournir assez de mots-clés pour quelques recherches Google.
!