Spécification des Interface dans la couche Business et DataAccess

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