Quels sont les objets que vous devez retourner à la couche d'accès aux données à la couche d'affaires un système n-tier

Question

Si vous avez, par exemple, une table de base de données appelée personne (ID, nom, etc.) quel type d'objet si le retour de couche d'accès aux données au niveau de l'entreprise? Je pense quelque chose comme ceci:

//data access tier
public class DataAccess{

   public interface IPerson{
      int ID{ get; set; }
      string Name{ get; set; }
   }

   internal class Person : IPerson{
      private int id;
      private string name;

      public int ID{ get{return id; } set{ id=value; } }
      public int Name{ get{retutn name; } set{ name=value; }
   }

   public static IPerson GetPerson(int personId)
   {
      //get person record from db, populate Person object
      return person;  
   }
}

//business tier
public class Person : IPerson{
   private int id;
   private string name;

   public int ID{ get{return id;} set{id=value;} }
   public string Name{ get{return name;} set{name=value;} }

   public void Populate(int personId){
      IPerson temp = DataAccess.GetPerson(personId);
      this.ID = temp.ID;
      this.Name = temp.Name;
   }
}

Mais tout cela semble un peu lourd? Y at-il une solution plus élégante à ce problème? Dois-je retourner un DataRow de la couche d'accès aux données à la couche d'affaires à la place?

Answer 1

Vous n'avez pas besoin de répéter la définition de classe dans votre couche d'accès aux données (DAL).

Vous pouvez créer vos entités commerciales comme des conteneurs « muets » dans un ensemble séparé, par exemple votre classe Person peut être juste: -

public class Person
{
    int ID { get; set: }
    string Name { get; set: }
}

Ensuite, vous pouvez donner à votre DAL une référence à la couche d'entités commerciales. Vos objets de contrôleur, si elles sont dans une couche logique métier séparée, ou dans votre couche d'interface utilisateur, peut alors il suffit d'appeler le DAL, ce qui peut créer une entité commerciale, le remplir à partir de la base de données et le retourner à votre contrôleur.

Cet article par Imar Spaanjaars a une bonne explication de ce modèle.

Answer 2

Votre couche d'affaires ne veut pas vraiment savoir sur les lignes de données - essayez de laisser des classes spécifiques données dans la couche de données. Cela réduit le couplage et vous libère pour changer votre couche de persistance à une date ultérieure sans gros re-architecting.

Pour résoudre votre problème, vous pouvez:

• Créer des objets de base de données / entités dans votre couche de données et les remettre à votre couche d'affaires à la consommation.
• Ou, comme il semble que vous faites, créer DTO (objets de transfert de données) qui existent uniquement comme un moyen de transfert de données de la couche de données à une mise en œuvre plus riche de votre objet métier dans une couche supérieure. Vous pouvez le faire dans le cadre d'un modèle référentiel dans un riche modèle de domaine.

L'autre chose que vous voudrez peut-être penser à couches sont les niveaux v - il fait une différence que vous pensez de ces choses. Sont généralement physiques niveaux, autrement dit, ils définissent les limites entre les processus. Les couches sont généralement logiques, ils séparent les fonctionnalités d'un programme en unités déconnectées. Vous visez pour les couches dans ce cas.

Answer 3

Si vous créez des interfaces à vos classes DAO et de les placer au sein de votre niveau d'entreprise, vous pouvez référencer votre niveau d'affaires du niveau d'accès aux données. Les classes DAO dans le retour de niveau de données objets à partir du niveau de l'entreprise.

Votre niveau d'entreprise fait référence aux interfaces au lieu de référencer directement les objets d'accès aux données. L'injection de dépendance au moyen d'un conteneur IoC (comme le château de Windsor, par exemple) vous permettra d'y arriver.

Cette technique est appelée séparée interfacé et est décrit ici:

http://www.martinfowler.com/eaaCatalog/separatedInterface.html

La meilleure explication de cette technique que je l'ai vu se trouve dans cet article sur les meilleures pratiques NHibernate, écrit par Billy McCafferty.

http://www.codeproject.com/KB/architecture/NHibernateBestPractices.aspx

L'article a beaucoup d'informations qui est spécifique à NHiberbate, mais une bonne moitié est tout simplement des informations solides sur la conception d'applications à couplage lâche et facilement unité testée.

Answer 4

Cette règle que chaque couche doivent faiblement couplée à la couche supérieure, en ajoutant BL référence à DAL n'est pas une bonne idée. Son mieux définir le modèle de données DAL avec une interface et faire sous forme d'une entité commerciale dans BL. comme mes expériences, de son mieux dans l'utilisation du référentiel DAL et l'accès à votre entité d'affaires ou Business Process.