Spécification des Interface dans la couche Business et DataAccess

Salut,

J'aimerais bien voir un exemple concret car personnellement, je n'utilise pratiquement pas les interfaces. Uniquement les classes abstraites.

La dernière fois que j'ai été confronté à un architecte interfacien, on ne s'est pas vraiment entendu , le plus rigolo c'est que je viens d'apprendre que 4 ans après (avec un dépassement de budget de l'ordre du million d'euros) il sont encore en train d'essayer de maintenir son projet que lui semble avoir été capable de comprendre.

Note que cette remarque n'est pas du tout un reproche, j'aimerais apprendre ce type de technique au cas où j'y serais confronté à nouveau.

Juste pour info, je crée des classes d'entrée et de sorties (façades) qui sont (normalement) passives. Elles permettent de passer les paramètres aux méthodes STATIQUES de la couche business dont les méthode qui ne renvoient des valeurs ne renvoient QUE des façades.

Les façades sont toujours sérialisables.

Je pourrais peut être créer une interface IBusiness dont les méthodes pourraient toujours renvoyer un membre de IFacadeOutput (dont tous les membres de facade hériteraient) et prendre en entrée IFacadeInput.

Mais je n'arrive pas à voir la valeur ajoutée de cette technique...

A tous, notez qu'un très bon moyen de ne pas avoir un gros boxon dans un projet et d'encapsuler chaque couche dans une DLL différente et d'avoir un DLL Domain qui contient toutes les façaces.

Après si ta couche présentation ne référence que la couche business et pas la couche data, tu es tranquille. Ca marche bien avec les using mais on peut être tenté de faire des écarts.

Dans VS 2010 il y a un analyseur de référence qui fait apparaitre les boulettes genre je remplis direct un datacontrol avec une query sans passer par la couche data... C'est assez simple et du peu que j'ai vu, ça a l'air assez efficace.

++

Laurent

Interessant tous ca.

Peux tu me donner un exemple :

Citation:

---

Envoyé par Laurent Jordi

Juste pour info, je crée des classes d'entrée et de sorties (façades) qui sont (normalement) passives

---

Car pour l'instant j'utilise une couche DAL et BLL. La BLL referencie la DAL et appelle les methodes static de chaque class.
Quel est l'utilite de passer par une facade ?

Merci

L'intérêt des façades est de toujours véhiculer des données fortement typées et surtout d'avoir ce typage centralisé. Ainsi, si jamais tu changes un int en décimal dans la façade, tu es certain que tout ton programme prendra cette modification en compte.

J'essayerais de te passer un exemple simple un peu plus tard, là je bosse je n'ai pas le temps...

++

Laurent

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 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40

using System; using System.Collections.Generic; using System.Linq; using System.Web; namespace BOODS.Objects.BusinessLayer.Facades { /// <summary> /// Classe facade de manipulation des droits /// </summary> [Serializable] public class Droits : _FacadesBase { /// <summary> /// EF:DROITS.Id /// </summary> public int Id { get; set; } /// <summary> /// EF:DROITS.Nom /// </summary> public string Nom { get; set; } /// <summary> /// Constructeur neutre /// </summary> public Droits() { } /// <summary> /// Constructeur actif /// </summary> /// <param name="id"></param> /// <param name="nom"></param> public Droits(int id, string nom) { this.Id = id; this.Nom = nom; } } }

---

Voilà,

L'intérêt de rendre cette classe sérialisable est de pouvoir s'en servir comme unité de stockage dans les objets comme le ViewState, la session ou l'application.

Ca facilite aussi les échanges lorsqu'on travaille avec des web service.

D'ailleurs, on pourrait comparer une façade au DataContract d'un webservice.

++

Laurent

Merci mais pour moi c'est un business object (objet metier).
C'est quoi la difference ?

Oui c'est un objet métier...

Par exemple, un client peut avoir une partie de ses caractéristiques dans une table et une partie dans une autre. Dans ce cas, l'objet métier, encapsule
l'ensemble des informations dans une seule classe.

++

Laurent

je suis d'accord avec toi. Pour moi une facade c'etait autre chose que ca.
Je ne savais pas que objet metier == facade.

Pas de pb alors :P

Non un objet métier n'est pas une façade, une façade ne comporte que des propriété, pas de méthode.

La couche métier contient les méthodes qui permettent d'obtenir les objets métiers qui sont défini par leur façade.

++

Laurent

je parle d'object metier et non de la BLL (business logic layer).
Pour moi un object metier est une class avec que des proprietes et constructeurs. La plus part du tps une table de la base de donnee == 1 object metiers.

la BLL ou DAL ou meme UI manipule les objects metiers

Dasn ce cas nous sommes d'accord à ceci près que mes objets métiers sont scindés en deux : BLL (méthodes statiques) Facades (Propriétés). Effectivement la DAL génère des objets de type façade qui sont consommés ou retournés par la BLL.

++

Laurent

Notes qu'étant autodidacte, il est possible que je n'utilise pas toujours les bon termes pour désigner les choses...

++

Laurent

y a pas de pb.

Pour ma part j'essaye de comprendre les design pattern.

Je te donne un lien expliquant la facade : http://www.dofactory.com/Patterns/PatternFacade.aspx

Ben le lien que tu cites c'est exactement ce que je fais mais c'est en anglais...

++

Laurent

Je pense que les façades de Laurent sont en fait ce qui est communément appelé des DTO (data transfert object).

La différence avec des objet business et qu'il ne contiennent aucune logique business. Ils ne servent qu'à transférer des données d'une couche à l'autre.

En DDD (Domain Driver Design) les objets business (domain objets) n'ont pas vocation à être exposés en dehors de la couche business. On passe par des DTO pour transférer des portions de données aux autres couches. Par exemple, si une interface graphique a besoin d'afficher le nom et le prénom d'une personne, on ne lui passe pas l'objet Personne en entier (ta couche business ne souhaite pas forcément que l'UI puisse accéder aux propriétés NuméroCarteCrédit et CodeSecret de Personne...). On ne lui passe qu'un DTO contenant deux propriétés: Nom et Prénom.
Les Domain Objects contient des données (propriétés) mais aussi de la logique métier (méthode).

Le terme façade fait plutôt référence au pattern façade qui permet de masquer la complexité (niveau logique applicative) d'un sous-système.

Ok ok... j'apprends... M'enfin, même avec ma terminologie, cettre structure est particulièrement solide et évolutive.

Niveau stats, sur un projet de 5 mois avec environ 300 classes (toutes couches confondues) je n'ai fait que 60 bugs dont 40 n'étaient que des bugs type css ou des features de présentation.

++

Laurent

Pour ma part c'est la couche metier (BLL) qui possedent tous traitements et comportements (methodes) afin de remplir des objects metiers qui eux n'ont que des proprietes afin d'etre transportés de couche en couche.

Bon, on fait tous la même chose mais on s'exprime différemment...

++

Laurent

Salut Laurent,

Les interfaces c'est vachement utile pour les tests unitaires, car sans il est difficile de mocker pour isoler des couches

l'IOC est une utilisation intéressantes des interfaces un peu de lecture si ça t'interesse :

http://martinfowler.com/articles/injection.html

Salut,

Les interfaces sont avant tout un "contrat" qui permet de determiner avec certitude la liste des propriétés et méthodes disponibles dans les classes qui implémentent l'interface.

Les interfaces permettent d'utiliser le pattern "Factory", comme par exemple la fabrique d'objet de connection "DbProviderFactory". Il suffit de regarder ce code: http://dotnet.developpez.com/faq/asp...onet_procstock, pour comprendre l'intérêt. Ce code fonctionnera quelque soit la base de données, il suffit de changer la chaine de connexion. Grace aux interfaces on généralise le code.

N'y aurait-il pas confusion entre "abstract" et "interface"?

Citation:

---

Indicate that a class is intended only to be a base class of other classes.

---

Qui permettent de factoriser des méthodes et des propriétés communes par héritage. Dans ce cas l'implémentation des méthodes est la même pour toutes les classes qui héritent sauf si tu fais un override, mais je ne vois pas l'intérêt. Ce qui n'est pas le cas des interfaces puisque aucune méthode n'y est implémentée.

A+

Salut

Notez que je savais ce quétait une interface et les rares fois où je les utilisais c'était dans WCF.

Merci pour ces infos. Utilisant le générateur automatique de tests unitaires de VSTS je n'ai jamais été confronté à ce cas d'utilisation.

++

Laurent

Citation:

---

Envoyé par Laurent Jordi

J'aimerais bien voir un exemple concret car personnellement, je n'utilise pratiquement pas les interfaces. Uniquement les classes abstraites.

---

L'implémentation du CRUD peu être contractualisé pour les classes de la BLL et de la DAL. Ainsi, tu es certain que chacune des classes de tes couches présenteront des méthodes "normalisés".

Citation:

---

Envoyé par Laurent Jordi

Juste pour info, je crée des classes d'entrée et de sorties (façades) qui sont (normalement) passives. Elles permettent de passer les paramètres aux méthodes STATIQUES de la couche business dont les méthode qui ne renvoient des valeurs ne renvoient QUE des façades.

Les façades sont toujours sérialisables.

---

Ce bien sont des objets de transfert de données. On dit aussi le Model, Entité ou Business Objects. Le projets dans lequel ces classes sont développées est transversal, référencé par la DAL et BLL pour pouvoir traverser toutes les couches. On en avait un peu discuté déjà.

http://www.developpez.net/forums/att...e/3-tiers.jpg/

Citation:

---

Envoyé par Laurent Jordi

Je pourrais peut être créer une interface IBusiness dont les méthodes pourraient toujours renvoyer un membre de IFacadeOutput (dont tous les membres de facade hériteraient) et prendre en entrée IFacadeInput.

---

On ne parle pas d'héritage pour les interface mais d'implémentation. Utiliser un "IFacadeInput" implique que tous tes DTO auront les mêmes propriétés que celles présentes dans l'interface. Ce qui n'est rarement le cas. Sauf pour une classe abstraite qui doit être hérité. Il vaut mieux utiliser la "gérénicité" ainsi:

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 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44

/// <summary> /// This Interface should be implemented by all Bll classes that manage objects from the model. /// These methods are from the basic CRUD concept. /// </summary> /// <typeparam name="T">Generic type</typeparam> public interface IBasicBll<T> {   #region Members   /// <summary> /// Method used to insert/create an entity in the database /// </summary> /// <param name="obj">The entity to create</param> /// <returns>Integer: the unique id of the record</returns> int Create(T obj);     /// <summary> /// Deletes an entity in the database /// </summary> /// <param name="obj">An <c>Entity</c> of which unique identifier is set</param> /// <returns>True if success. False if fails.</returns> bool Delete(T obj);     /// <summary> /// Updates an entity in the database /// </summary> /// <param name="obj">The entity to update</param> /// <returns>True if success. False if fails.</returns> bool Update(T obj);     /// <summary> /// Returns an entity from the database /// </summary> /// <param name="obj">An <c>Entity</c> of which unique identifier is set</param> /// <returns>The requested entity</returns> T Load(T obj);   #endregion }

---

Citation:

---

Envoyé par Laurent Jordi

Mais je n'arrive pas à voir la valeur ajoutée de cette technique...

---

Ce code permet d'implémenter le CRUD sur la BLL et la DAL. Le "T" pour "Type" (mais on peu utiliser n'importe quelle lettre) remplace n'importe quel objet DTO à faire passer pour traiter les données.

Citation:

---

Envoyé par Laurent Jordi

A tous, notez qu'un très bon moyen de ne pas avoir un gros boxon dans un projet et d'encapsuler chaque couche dans une DLL différente et d'avoir un DLL Domain qui contient toutes les façaces.

Après si ta couche présentation ne référence que la couche business et pas la couche data, tu es tranquille. Ca marche bien avec les using mais on peut être tenté de faire des écarts.

---

C'est le schéma "classique" d'une architecture en couches. Perso j'ajoute même un projet console qui me permet de tester ma BLL avant de créer mon interface web. Ainsi, je sais que les couches sont indépendante du choix du type d'interface.

A+

Citation:

---

Perso j'ajoute même un projet console qui me permet de tester ma BLL avant de créer mon interface web. Ainsi, je sais que les couches sont indépendante du choix du type d'interface.

---

Et pourquoi pas un projet de test à la place de la console ?

Pourquoi pas. Mais j'ai pas mal travaillé sur VS 2005 sur lequel ce type de projet n'est pas disponible.

Moi j'utilise Nunit avec VS 2005 et je continuerai à l'utiliser avec VS 2008 je pense ;)

Pour ma part, j'ai un peu fait l'impasse sur VS2005. A 2 missions près, je suis passé directement de VS2003 (ASP.net / VB.Net 1.1) à VS2008 (ASP.net / C# 3.5).