Discussion :

[pduguet33]

Bonjour à tous!

Je suis en cours d'analyse pour la réalisation de la couche métier de mon application. Après quelques brainstorming il a été décidé de partir sur une architecture DDD. J'aimerais avoir l'avis de ceux qui ont déjà utilisé cette architecture et quelques conseils d'amélioration éventuellement.
L'achitecture du projet est en pièce jointe (screen de l'arborescence dans VS).



Pour la décrire brièvement, elle comprends:

• Une couche DAL qui contient mon modèle entity ainsi que mon ObjectContext généré à partir d'un template T4
• Une couche DTO qui contient des DTO générés à l'aide d'un template T4 à partir du modèle entity du type:
  

  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
  45
  46
  47
  48
  49
  50
  51
  52
  53
  54
  55
  56
  57
  58
  59
  60
  61
  62
  63
  64
  65
  66
  67
  68
  69
  70
  71
  72
  73
  74
  75
  76
  77
  78
  79
  80
  81
  82
   
  public partial class Album
  {
       #region Primitive Properties
   
          public virtual int IdAlbum
          {
              get;
              set;
          }
   
          public virtual string Name
          {
              get;
              set;
          }
   
          #endregion
          #region Navigation Properties
   
          public virtual ICollection<User> User
          {
              get
              {
                  if (_user == null)
                  {
                      var newCollection = new FixupCollection<User>();
                      newCollection.CollectionChanged += FixupUser;
                      _user = newCollection;
                  }
                  return _user;
              }
              set
              {
                  if (!ReferenceEquals(_user, value))
                  {
                      var previousValue = _user as FixupCollection<User>;
                      if (previousValue != null)
                      {
                          previousValue.CollectionChanged -= FixupUser;
                      }
                      _user = value;
                      var newValue = value as FixupCollection<User>;
                      if (newValue != null)
                      {
                          newValue.CollectionChanged += FixupUser;
                      }
                  }
              }
          }
          private ICollection<User> _user;
   
          #endregion
          #region Association Fixup
   
          private void FixupUser(object sender, NotifyCollectionChangedEventArgs e)
          {
              if (e.NewItems != null)
              {
                  foreach (User item in e.NewItems)
                  {
                      if (!item.Album.Contains(this))
                      {
                          item.Album.Add(this);
                      }
                  }
              }
   
              if (e.OldItems != null)
              {
                  foreach (User item in e.OldItems)
                  {
                      if (item.Album.Contains(this))
                      {
                          item.Album.Remove(this);
                      }
                  }
              }
          }
   
          #endregion
  }

• Une couche POCO qui contient des POCO créés par inclusion comme ci-dessous:
  

  Code :

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

  1
  2
  3
  4
  5
  6
  7
  8
   
  public class AlbumPOCO
  {
          public Album Album { get; set; }
   
          // Diverses méthodes métier
          // ...
   }

  J'aimerais avoir un retour concernant la création des POCO (manière de les implémenter, génération auto?).
• Une couche Repo qui contient des repositories contenant des méthodes CRUD. Ce n'est pas encore le cas là, mais une abstraction sera faite à ce niveau avec création d'interfaces pour rendre tout ça testable

Merci d'avance de vos avis et conseils sur cette architecture!

[Invité]

Salut,

Je ne sais pas trop à quoi sert ici tes classes POCOs. De plus elles ne représentent même pas la véritable définition POCO. À ce que je vois tu crées un wrapper pour tes classes DTOs. Des DTOs étant implicitements des POCOs alors pourquoi les encapsuler dans un objet POCOs ? Bref je pense que tu t'es perdu dans la fonction de ces types de classes.

À ce que je vois tu as utilises la génération de code POCO qui est une fonctionnalité qui a été ajoutée à EF4 pour permettre d'avoir des objets POCOs et c'est que tu utilises ici sauf que tu l'utilises mal en supposant qu'il s'agit de DTO alors que non.

[meziantou]

A vouloir trop séparer les concepts on arrive facilement à un un modèle anémique qui n'est pas pratique à utiliser (et qui ne sert en général pas à grand chose). 2 liens sur le sujets (tu en trouvera surement d'autres sur internet)
http://martinfowler.com/bliki/AnemicDomainModel.html

[pduguet33]

En réalité je me suis fié aux définitions DTO/POCO pour réaliser l'architecture.
* DTO = objets de données contenant uniquement des propriétés
* POCO = ces mêmes objets mais avec les méthodes métier en plus

C'est pour ça que mes POCO sont en fait des wrappers. Donc il faut que j'évite les couches inutiles d'après toi (et tes sources) meziantou?
Mon but final étant de pouvoir manipuler des objets déconnectés côté client et de centraliser les méthodes d'accès aux données pour éviter les grosses répercutions quand il y a un changement au niveau du modèle de données.

Ma question devient donc, comment gérez vous vos POCO alors qu'ils sont générés automatiquement par mon template T4. Je fais des classes partielles correspondant à mes POCO avec les méthodes dont j'ai besoin?

[meziantou]

Pour moi (et apparemment h2s84) tes DTO n'ont aucun n'intéret. Tes POCO peuvent contenir toutes les propriétés + les méthodes métiers.

Oui les classes partielles permettent de générer une partie du code et de le personnaliser ensuite dans une autre classe partielle.

[pduguet33]

Ok j'adopte ça alors. Merci pour vos réponses je mets en résolu

[Invité]

Pour moi (et apparemment h2s84) tes DTO n'ont aucun n'intéret. Tes POCO peuvent contenir toutes les propriétés + les méthodes métiers.

Voilà c'est ça. Il a utilisé le mauvais nom pour ses DTOs. Il s'agit en fait de POCOs générés par EF 4. Il faut qu'il supprime la couche POCO qu'il a créé et renommer la couche DTO par POCO.

Oui les classes partielles permettent de générer une partie du code et de le personnaliser ensuite dans une autre classe partielle.

+1

[pduguet33]

J'aimerais vous demander un peu plus de précisions concernant la couche DTO. Dans quel cas peut-elle être utilisée sans anémier notre architecture. Je comprends bien votre avis concernant la lourdeur inutile d'une architecture telle que je l'ai montrée, mais si elle a été créée c'est qu'elle doit correspondre à un besoin particulier. Quel est-il?

[Invité]

J'aimerais vous demander un peu plus de précisions concernant la couche DTO. Dans quel cas peut-elle être utilisée sans anémier notre architecture. Je comprends bien votre avis concernant la lourdeur inutile d'une architecture telle que je l'ai montrée, mais si elle a été créée c'est qu'elle doit correspondre à un besoin particulier. Quel est-il?

Les DTOs (Data Transfer Objects) comme le nom l'indique sont utilisés pour simplifier la communication enter deux applications ou entre deux couches d'une même application. L'avantage apporté est la simplification des informations partagées. Par exemple :

• si tu as une fonction recevant 10 paramètres il serait plus simple de créer une classe DTO qui regrouperait ces différents paramètres en tant que propriétés et au final ta fonction aura un seul paramètre qui sera du type de la classe DTO.
• Avec ce pattern on peut aussi fournir au client un objet DTO contenant le résultat de deux fonctions qu'on a l'habitude d'appeler l'une après l'autre (parce qu'une fonction ne peut avoir qu'une seule valeur de retour donc DTO évite de faire plusieurs appels de fonctions successives pour réunir les donnnées nécessaires et nous permet d'effectuer un seul appel donc d'écrire une seule fonction).

DTO est de plus en plus utilisé avec les objets DAO (Data Access Layer) en mettant en place entre les deux classes un Assembler (qui est un convertisseur) qui se chargera de faire la conversion entre les deux types. les DTOs seront utilisés côté client et les DAO côté couche d'accès aux données. Cela pour éviter que le GUI soit dépendant des objets de la couche d'accès aux données.

Si on en revient à Entity Framework dans sa version 3.5 les entités dérivaient tous de EntityObject et sont en quelque sorte considérées comme des objets DAO d'où la plupart des projets qui utilisaient cette version d'EF ont adopté le pattern DTO pour que les couches soient indépendantes. Mais les versions 4.x apportent la facilité de l'utilisation des objets POCO et aussi une nouvelle approche appelée Code First. Ces solutions offrent la possibilité d'utiliser des classes qui ne sont pas trop dépendant d'une classe particulière comme EntityObject etc. D'où ma réponse concernant la non utilité du pattern DTO dans ton projet à toi vu que ut utilises des classes POCOs générées par EF (mais que toi tu appelles DTOs )

Bref j'espère que j'ai été clair.

[pduguet33]

Tu ne pouvais pas être plus clair
En effet je prenais pour des DTOs les classes POCO générées par EF car elles avaient l'air de simple conteneurs de propriétés. Et ça me perturbait parce que je ne voyais pas trop la distinction DTO/POCO. Normal puisqu'il n'y en a pas dans mon cas ^^ J'utilise juste des POCOs.

Merci de ta réponse détaillée en tout cas!