Discussion :

[Julien_Dufour]

C'est l'utilisation d'un mapper pour convertir un objet donné en DTO pour le transferer aux couches hautes de l'appli

La "couche DTO" est-elle entre DAL et business ou entre business et présentation?

Edit: Le MVVM etant entre business et presentation, la reponse serait donc : entre DAL et business. Mais dans ce cas, c'est pas dommage de creer des objet a partir d'un ORM, pour les retransformer avant d'envoyer les infos a la couche business? N'est ce pas du ressort de la DAL (ORM dans le cas d'EF) que de donner des objets cleans?

[CUCARACHA]

C'est quoi l'adresse de l'AutoMapper, je suis assez intéresse là...

[revilo]

La "couche DTO" est-elle entre DAL et business ou entre business et présentation?

Entre la Dal et la business.
Enfin j'en fais pas vraiment une couche. plus un Helper qui transforme des Entities issues de EF en objets manipulable par la couche business et affichables.

Note : je pourrais découpler d'aventage en positionnant des DTO entre le business et la couche présentation. Mais dans mon cas ca serait "prendre le bazooka pour tuer la mouche" comme on dit !

[Philippe Vialatte]

C'est quoi l'adresse de l'AutoMapper, je suis assez intéresse là...

http://lmgtfy.com/?q=automapper

Bon, allez, comme c'est pas le genre de la maison, le mieux, c'est de commencer par un webcast

http://dimecasts.net/Casts/CastDetails/111

Et pour plus d'infos, de jeter un oeil sur le blog de Jimmy Bogard

http://www.lostechies.com/blogs/jimm...x?q=automapper

[Julien_Dufour]

Entre la Dal et la business.
Enfin j'en fais pas vraiment une couche. plus un Helper qui transforme des Entities issues de EF en objets manipulable par la couche business et affichables.

Donc si on a des beaux objets POCO avec la prochaine version d'entity (comme promis), cette partie disparaitra si je te comprends bien

Note : je pourrais découpler d'aventage en positionnant des DTO entre le business et la couche présentation. Mais dans mon cas ca serait "prendre le bazooka pour tuer la mouche" comme on dit !

Bon, je pense que le MVVM est se rapproche de ton bazooka
(histoire de binding avance mis a part)

[CUCARACHA]

Tiens au passage, j'ai pas super étudié les helpers... c'est un peu des bretelles pour un mec qui a déjà une ceinture (je fais une analogie avec un cerveau en fait)..
++

Laurent

[revilo]

@Julien : Oui et oui aussi pour le bazooka

@Laurent : N'en déplaise aux puristes, ce que j'appelle ici Helper n'en est probablement pas un.

Il s'agit, dans l'utilisation que j'en ai, de classes static la plus part du temps, proposant des outils divers, ici, conversions d'objets en autre objets.
Je suis donc super mal placé pour parler de Helper, car je connais peu le sujet.

En ce sens Automapper m'intéresse, j'ai regardé rapidement le joli podcast et il part d'un principe que je vais avoir du mal a faire passer:

Je m'explique, il semble utiliser des interfaces de POCO. Cette utilisation est possible car nous avons dans nos classes des accesseurs (get et set), qui sont des méthodes particulières en fin de compte.
Le fait de mettre un contrat sur ces méthodes est donc techniquement possible.

Ce qui me fait réagir, c'est qu'en ce moment je suis sur un projet ou le responsable ne veut pas entendre parler d'interface de POCO. Car c'est pas vraiment objet selon lui...

Pour avoir travaillé sur un projet en java ou l'architecte travaillait en mettant des contrats sur les objets échangés, je dois avouer que je ne sais pas vraiment quoi penser...

[Philippe Vialatte]

Ce qui me fait réagir, c'est qu'en ce moment je suis sur un projet ou le responsable ne veut pas entendre parler d'interface de POCO. Car c'est pas vraiment objet selon lui...

Ah...bon ???

Je ne sais pas ou il a vu ca...

[Julien_Dufour]

Pour avoir travaillé sur un projet en java ou l'architecte travaillait en mettant des contrats sur les objets échangés, je dois avouer que je ne sais pas vraiment quoi penser...

C'est exactement la question que je me pose: POCO ou économie de code? (dans le cas d'entity)

Pour l'histoire du POCO qui serait pas un objet, j'avoue ne pas saisir non-plus...

[CUCARACHA]

Ca ne vaut plus le coup d'économiser le code... La j'ai huit coeurs, 6Go de Ram, je peux jouer en 1600x1200 à Age of Conan en detail High avec 2 VM qui tournent dans le bouzin... Si tu fais ramer ce genre de machine, il faut penser à tenter la star'ac...

++

Laurent

[Julien_Dufour]

Ca ne vaut plus le coup d'économiser le code... La j'ai huit coeurs, 6Go de Ram, je peux jouer en 1600x1200 à Age of Conan en detail High avec 2 VM qui tournent dans le bouzin... Si tu fais ramer ce genre de machine, il faut penser à tenter la star'ac...

Par économie de code, je parlais du temps de dev

[CUCARACHA]

Ben le temps de dev augmente légèrement mais le temps de test et de débogage baisse considérablement, en conséquence, à l'échelle du projet, c'est plus rapide, il faut juste trouver des codeurs mutants avec 6 doigts à chaque main...

++

Laurent

[anthyme]

Perso je suis contre ce qui a été dit plus haut ...

Avoir 2 domaines objets est une mauvaise idée. EF à été créé pour définir un domaine objet global et unique avec des fonction de mapping avancés permetant de faire abstraction de la structure de stockage de données. Ce n'est pas du tout conçu pour ré encapsuler les données dans d'autres objets...

Après si le coté non POCO d'EF t'embêtes (ce que je peux concevoir) je te conseil vivement d'utiliser NHibernate qui est POCO très puissant et plus fonctionnel qu'EF (et on peut également faire du Linq).

Perso c'est sur une solution NHibernate + Asp.net MVC sur laquel je travail actuellement

[Immobilis]

On va relancer le débat la-dessus, mais tu parles de tiers (découpage physique) ou de couches (découpage logique) ?

(et oui, j'ai probablement des exemples pour les deux, mon capitaine )

Logique. Le découpage physique est souhaitable pour ne pas s'emmeler les pinceaux. Fondamentalement il n'est pas obligatoire.

EF est une très bonne DataLayer toutefois, dans mes projets, j'encapsule tous les appels à EF dans une couche que j'appelle DataLayer qui est invoquée exclusivement par ma BusinessLayer et qui ne renvoie que des propriétés scalaires ou des objets de ma BuisinessLayer.Facades (qui sont tous sérializable au passage pour bien gérer la persistence temporaire dans le ViewState).

Tu recréés des objets de transfert? Les objets créés par EF sont parfaitement serializables.
Tu ajoutes tes entités au viewstate?

Je ne te conseille pas de l'appuyer directement sur les entités pour alimenter ta couche de présentation car elles présentent beaucoup de limitations par rapport aux objets (par exemple tu ne peux pas faire deux foreach sur la même collection résultante d'une requête EF).

Si, ça marche (en tous les cas avec VS2010 FW4).

Entre la Dal et la business.
Enfin j'en fais pas vraiment une couche. plus un Helper qui transforme des Entities issues de EF en objets manipulable par la couche business et affichables.

Note : je pourrais découpler d'aventage en positionnant des DTO entre le business et la couche présentation. Mais dans mon cas ca serait "prendre le bazooka pour tuer la mouche" comme on dit !

Ca ne vous donne pas l'impression de faire plusieurs fois le même boulot?

Dans une architecture 3 tiers les DTO sont totalement indépendants des couches car ils sont justement commun. Il sont totalement transversaux.

Avec EF c'est la DAL qui créé les entités. Ajouter une couche pour "masquer" ça me semblerait inutile voir non constructif. Si tu choisis d'accéder aux données avec EF ta DAL sera référencée dans ton IHM. Du coup tu t'éloigne du modèle 3 tiers dit en couches. Le Modèle c'est DAL + DTO, le Controleur c'est la BLL, la vue l'IHM.

A+

[CUCARACHA]

Salut,

Tu as raison sur toute la ligne toutefois si demain mon client souhaite virer entity framework au profit d'un autre système, il ne perd pas toute sa couche data et sa couche Business demeurera intacte (en l'occurrence elle est très complexe).

Je note que tu précises toi même que le coup des boucles fonctionnes sur FW4 alors que nous sommes sur le FW2 avec C# 3.5. Hors de question de livrer en prod une appli développée sur la base d'un FW en beta.

Bien que cette fois-ci je sois assez convaincu par l'outil, je sais qu'il sera éphémère comme tout ce que Microsoft propose. Non pas qu'il va disparaitre mais être remplacé par une version plus puissante ce qui entrainera forcément du recodage.

Lorsqu'on développe, il ne faut pas uniquement penser aux performances et aux règles de l'art. Il faut être pragmatique et intégrer les enjeux et les retombées économiques dans son raisonnement.

Donc, les conseils que je donne n'engagent que moi, tes constats sont certes fondés mais je ne suis pas certain qu'ils intègrent toutes les contraintes liées à l'environnement technico commercial.

++

Laurent

[Immobilis]

Tu as raison sur toute la ligne toutefois si demain mon client souhaite virer entity framework au profit d'un autre système, il ne perd pas toute sa couche data et sa couche Business demeurera intacte (en l'occurrence elle est très complexe).

C'est le principe du découplage. C'est un peu aussi ce que j'ai dit quand j'ai fait mon architecture 3-tiers avec un objet de connexion utilisant les "DbProviderFactories". Maintenant d'un point de vue pragmatique justement, qu'elle est la probabilité de changer de SGBD (nous sommes sous SQL Server)? Chez nous elle est quasie nulle parce que au moment où elle est là elle marche. C'est moins couteux de repartir de 0 que de modifier. A mon avis cela est du au fait que la nouvelle techno qu'on souhaite utiliser pour en remplacer une autre est beaucoup plus efficace si on utilise les nouvelles méthodes de développement associées avec.

Mais cela n'engage que moi.

Je note que tu précises toi même que le coup des boucles fonctionnes sur FW4 alors que nous sommes sur le FW2 avec C# 3.5. Hors de question de livrer en prod une appli développée sur la base d'un FW en beta.

J'ai du mal à croire qu'on ne puisse pas faire deux boucles successives sur un "IQueryable" sous VS2008 et FW 3.5. Dslé, j'ai pas VS2008 sous le coude mais je vais essayer avec VS2010 et FW3.5.
==> VS2010 et FW3.5

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
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Data.Objects;
 
namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            using (ECommEntities entities = new ECommEntities())
            {
                ObjectQuery<ANNOUNCE> qr = new ObjectQuery<ANNOUNCE>("ANNOUNCE", entities);
 
                foreach (ANNOUNCE item in qr)
                {
                    Console.WriteLine("ANNOUCE {0}", item.ANN_TEXT);
                }
 
                foreach (ANNOUNCE item in qr)
                {
                    Console.WriteLine("ANNOUCE {0}", item.ANN_STARTDATE);
                }
            }
            Console.ReadLine();
        }
    }
}

A+

[CUCARACHA]

Je ne parlais pas de changer de SGBD mais de connecteur relationnel objet.

[Immobilis]

Je ne parlais pas de changer de SGBD mais de connecteur relationnel objet.

Pareil, changer une couche quoi...
Sinon, avec LINQ la var est un objet "ObjectQuery" ça marche aussi:

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
namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            using (ECommEntities entities = new ECommEntities())
            {
                var toto = from c in entities.ANNOUNCE where c.ANN_ID < 4 select c;
 
                foreach (ANNOUNCE item in toto)
                {
                    Console.WriteLine("ANNOUCE {0}", item.ANN_TEXT);
                }
 
                foreach (ANNOUNCE item in toto)
                {
                    Console.WriteLine("ANNOUCE {0}", item.ANN_STARTDATE);
                }
            }
            Console.ReadLine();
        }
    }
}