Discussion :

[CUCARACHA]

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

[topolino]

Interessant tous ca.

Peux tu me donner un exemple :

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

[CUCARACHA]

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

[CUCARACHA]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[topolino]

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

[CUCARACHA]

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

[Immobilis]

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".

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à.

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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	
}

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.

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+