Confusion entre DTO (linq2sql) et des objets de classe!

Question

Je travaille avec succès linq2sql et les DTO LINQ (les classes qui sont créés par linq2sql) ....

Je suis confus, j'ai la tâche de mettre à jour une ancienne application et je peux voir que mes DTO seront utilisés comment ils devraient être .... pour le transport de la date

J'utilise le modèle référentiel donc je suis transmettre des données du référentiel au service via les dtos de linq2sql ... une fois que je suis dans la couche de service (ce qui est fondamentalement ma logique métier), alors je dois passer autour d'objets de classe ..

ces objets de classe sont basiquement une image miroir (plus ou moins) des dtos - il y a quelques changements dans un endroit, mais en général les mêmes ..

Pour revenir à la question à la main! - est-ce une bonne pratique d'utiliser dtos uniquement aux données de transport à partir du dépôt de la couche de service ... et une fois dans la couche de service (logique métier) je devrais mais CARTOGRAPHIE tous mes dtos là aux contre-parties d'objets de classe (bien sûr en utilisant automapper! !)

Mon autre alternative est de continuer à utiliser les DPDT comme des objets de classe et les passer autour d'une méthode à et que les types de retour, etc, mais je pense que c'est une mauvaise pratique et je continue à tourner en rond se demander quelle méthode je devrais appliquer?

Toute aide vraiment apprécié

Merci

Answer 1

Voici mon avis: Lorsque vous traitez avec une application non trival. En utilisant vos objets linq2sql comme modèle de domaine est une très mauvaise idée. Je vois linq2sql comme ORM et rien de plus. Base de données (qui linq2sql a une correspondance directe avec) est une normalisation des données . Les classes (au sens de OOAD) sont une normalisation du comportement (pas de données).

  

[ces objets de classe sont basiquement une image miroir] ...

Je rencontrais quand la construction d'applications avec linq2sql. Soyons réalistes .... plus d'applications en ligne d'affaires sont glorifiés applications CRUD. Il est donc pas hors de question qu'un grand pourcentage des entités de votre application correspond directement aux tables de base de données. Je ne voulais pas être lié directement à celui du DTO qui ont été générés, mais en même temps je ne voulais pas les classes dupliquées jonchaient dans mon application.

Alors, voici ma solution:
I "programmé à une interface".

Disons que j'ai un PersonDto (DTO debout pour objet de transfert de données) avec des propriétés de FirstName, LastName, Age (qui se rapportent directement aux colonnes de base de données).

Je créé une interface IPerson et a mon PersonDto mettre en œuvre.

  [Table(Name="Persons")]
  internal class PersonDto : IPerson
  {
      ....
  }

Et ma méthode référentiel prendrait et récupérer IPerson par opposition à la classe Linq2Sql.

    IPerson somePerson = _repository.Get(someGuid);
    somePerson.FirstName = "SomeName";
    _repository.Save(somePerson);

Cette approche a vraiment bien fonctionné pour moi. Chaque fois que je sens que je dois écarter de la DTO, je peux le faire assez facilement en raison de l'interface qui représente mon objet par opposition à la DTO.

Quelques indications générales: Construisez vos DTO à la main ... Je sais que ça semble fou, mais vous verrez que cela fonctionne très bien avec un haut vers le bas, le test approche de développement axée. Votre objets de DTO (linq2sql) seront extrêmement léger et seront ouverts à des changements en dehors du concepteur .dbml.

Gardez interne à celui de votre DTO et DataContext. Il n'y a aucune raison de votre DTO être publiquement exposé (étant donné que vous avez des interfaces publiques pour vous des référentiels et des objets de domaine). Faire cela forcera une séparation logique entre votre modèle de domaine et l'accès aux données.

Mettez toute votre couche d'accès aux données dans un projet distinct (encore une fois pour faire respecter cette séparation).

Mettez vos déclarations d'interface dans un projet distinct (cela vous permettra de ne pas exécuter en toute référence circulaire).

Hope this helps ...

Answer 2

J'ai eu en fait une question similaire sur ce sujet, bien que mon intention était légèrement différente. La recommandation était d'utiliser les classes linq2sql comme les objets de domaine et de tirer parti des classes partielles comme d'autres l'ont mentionné. Ma principale préoccupation est venu avec la forme de ces objets (par exemple noms de propriété) et l'accessibilité des membres de la classe (c.-à-V.S. privée protégée par exemple).

La forme des objets et même l'accessibilité peuvent être traités à l'aide des modèles de garde où Damien t4 a mis en place un modèle T4 pour vous permettre de contrôler la forme des classes qui Linq2Sql engendrerait pour vous. Cela peut être vu ici T4 modèle Linq2SQL.

Ceci est l'approche que je vais examiner et voir si elle répond à mes préoccupations. En outre, si votre couche de service peut accepter des interfaces aux arguments de la méthode, vous pouvez également contrôler ce que la couche de service a accès à l'interface par les enveloppes autour de votre Linq2SQL DTO.

Hope this helps.

Answer 3

Ceci est l'une des meilleures discussions sur le sujet que je l'ai vu:

http://blog.wekeroad.com/ blog / LinqToSql-Momma-dit-toc-vous-out /

En fin de compte, le couplage et les décisions de cohésion sont la situation et vous devez décider ce qui est le mieux à votre situation.

Lorsque votre application devient trop LinqToSql, comment il sera facile de tirer sur des LinqToSql et insérez une autre ORM à sa place? C'est quelque chose que vous devez réfléchir sérieusement à.

En général, minimiser la connaissance de votre couche d'affaires a environ LinqToSql. LinqToSql doit être complètement caché de votre couche d'interface utilisateur (votre couche métier fait une bonne partie de ce bouclier). Il est très facile d'aller sur le chemin architectual mal avec LinqToSql et il peut être très difficile de se remettre sur le droit chemin après le fait.

Answer 4

Les classes générées par le concepteur linq2sql sont des classes partielles, de sorte que vous pouvez les étendre et de mettre votre logique métier directement en eux. L'idée est que LINQ est utilisé pour persister / reconstruire ces entités de sorte que vous pouvez éviter le genre de cartographie que vous parlez.