Discussion :

[trihanhcie]

Salut a tous !

Je suis en train de travailler sur une site asp.net mvc 5 + wepapi2.
Je m'interroge sur l utilisation de Domain-driven development avec un generic repository.

J'ai 3 projects dans ma solution
- Infrastructure avec le context de la bdd + repository
- Core avec les entities
- site web asp.net mvc + angular.

Ma question est la suivante ... Creeriez vous un autre project (comme domain service) ou vous faites les appels du controller seront fait? ou appeleriez vous les methodes de votre repository directement de votre controller? Cette derniere solution me parait un peu dangeureuse dans la mesure ou toute la logique est dans le controller...

[Pragmateek]

Le repository est déjà une abstraction métier de haut niveau donc aucun souci pour taper "directement" dedans.
C'est manipuler directement les DbContexts comme des repository qui peut être discutable.

Mais comme toujours, et comme c'est loin d'être la règle en informatique, c'est le pragmatisme qui doit primer et il faut se poser les bonnes questions : pourquoi concrètement veux-tu découpler ?
Si comme argument tu ne vois que des avantages théoriques, des mots, alors c'est que tu n'en as sûrement pas besoin.
Si en revanche tu VAS (j'ai bien dis "VAS" pas "éventuellement en cas d'alignement de Saturne et Uranus un jour de pleine lune" ) réutiliser ta logique applicative alors oui crée cette couche.

Après ce n'est pas tout ou rien : si tu as des règles métiers bien définies, aussi basiques que la complexité des mots de passe, ou bien aussi complexes que des processus métiers alors tu devrais les isoler dans des composants dédiés dès maintenant.
Si plus tard (typiquement dans quelques années si tout n'a pas été refait from scratch) tu as besoin de réutiliser tu auras fait l'essentiel et il te restera à sortir le reste pour constituer une vraie couche service.

[trihanhcie]

Merci !

Oui je pense que, pour le moment, je vais eviter la couche service supplementaire pour le moment.
Autre question... Je ne vois pas trop l'interet du Lazy Loading...
Je m explique... Si je comprends bien, le lazy loading permet d effectuer une requete qu au moment desire....
Example, si un user a plusieurs roles, les roles ne seront "load" qu'au moment ou la propriete Role de User sera acceder...

Sur le principe, je le comprends bien et cela permet de charger une entite sans les associations si elles sont inutiles... Mais ne perdons nous pas en controle de ce qui est fait derriere par rapport au eager loading? En eager loading, les roles ne serait binde que si un include a ete fait...
De plus, avec le lazy loading, on se retrouve a faire une requete par role pour chaque user... result, si un user possede 4 roles, il y aura 4 acces a la DB pour recuperer les details de chaque role...
A l inverse avec le eager loading, tout sera charge en une fois et en une requete... N'est pas mieux d utiliser le eager loading dans tous les cas afin d avoir plus de controles sur les acces a la bdd?

Personnellement, je vois plus d inconvenients que d avantages a utiliser le lazy loading... quelqu un peut m eclairer sur les gros avantages du lazy loading?

Merci

[Pragmateek]

Tout dépend du pattern d'utilisation de ces données :
- s'il est déterministe, i.e. tu sais que tu as besoin de telle ou telle donnée alors en effet charger en différé n'a pas d'intérêt et coûte pour rien
- s'il est aléatoire, i.e. tu ne sais pas à l'avance celles que tu utiliseras le lazy-loading de permet de payer juste pour ce que tu utilises, avec un premium cependant (un aller-retour par donnée)

Quand tu as peu de données tout charger tout le temps même si tu t'en sers rarement n'a pas un gros impact.

Le lazy-loading est surtout pertinent quand tu as des gros objets : e.g. tu es Flickr et tu ne veux surtout pas charger les photos de suite donc tu as typiquement une entité qui stocke les métadonnées de la photo et qui pointe vers les données binaires de la photo qui ne seront chargées qu'à la demande.

Et n'oublie pas que tu as un 3ème mode d'accès moins connu qui se situe entre les deux : le Load à partir de l'entrée de suivi de l'entité : c'est à la fois explicite et différé.

[trihanhcie]

Merci !
Je ne comprends pas trop ... pour moi, le mode Load est celui par defaut de EF non?
Ou alors j'ai mal compris le fonctionnement...
Imaginons que j'ai une table User et une table Role.
Si le Lazy Loading dans EF n'est pas actif, que se passe-t-il si je fais User.ToList() ?
Vais-je avoir la liste des users et, pour chaque user, son role directement meme si je n'accede pas a son role? ou dois-je faire User.Include(x => x.Role).ToList() pour avoir les roles lies a chaque user en une seule requete?

[katkiller]

Salut,

Voici un petit exemple pour tester le LazyLoading...

"Schéma" :


Et voici le code de test :

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
        static void Main(string[] args)
        {
            using (var db = new KatBlogEntities())
            {
                List<Post> posts;
                //On test le mode de LazyLoadingEnabled pour effectuer la bonne requête.
                if (db.Configuration.LazyLoadingEnabled)
                {
                    posts = db.Posts.Take(10).ToList();
                }
                else
                {
                    posts = db.Posts.Include("Category").Take(10).ToList();
                }
 
                foreach (var post in posts)
                {
                    //Si on est en "LazyLoadingEnabled = false" et que l'on utilise "posts = db.Posts.Take(10).ToList();";
                    //Alors nous aurons une erreur (NullReferenceException)
                    Console.WriteLine("Post titre : {0} - Categorie Name : {1}", post.Title, post.Category.Name);
                }
 
            }
            Console.ReadLine();
        }

En espérant que c'est quelques lignes pourront t'éclairer.

[Pragmateek]

Merci !
Je ne comprends pas trop ... pour moi, le mode Load est celui par defaut de EF non?
Ou alors j'ai mal compris le fonctionnement...

Par défaut le lazy-loading est activé, i.e. EF tentera de l'utiliser.
Mais il faut aussi que tes entités s'y prêtent, i.e. que les propriétés de navigation soient virtuelles.
Si ce n'est pas le cas alors c'est au développeur d'indiquer explicitement de charger les données via Include et/ou Load.

Imaginons que j'ai une table User et une table Role.
Si le Lazy Loading dans EF n'est pas actif, que se passe-t-il si je fais User.ToList() ?
Vais-je avoir la liste des users et, pour chaque user, son role directement meme si je n'accede pas a son role? ou dois-je faire User.Include(x => x.Role).ToList() pour avoir les roles lies a chaque user en une seule requete?

Sans lazy-loading les listes de rôles seront null et il te faudra en effet indiquer le chargement soit :
- lors de la remontée initiale via Include
- plus tard via Load.

[trihanhcie]

Mais il faut aussi que tes entités s'y prêtent, i.e. que les propriétés de navigation soient virtuelles.
Si ce n'est pas le cas alors c'est au développeur d'indiquer explicitement de charger les données via Include et/ou Load.

Merci, j'ai enfin compris la maniere dont cela fonctionne maintenant grace a ces 2 phrases

Et n'oublie pas que tu as un 3ème mode d'accès moins connu qui se situe entre les deux : le Load à partir de l'entrée de suivi de l'entité : c'est à la fois explicite et différé.

Un lien pour cela? ou s'agit il simplement de ce qui a ete mentionne ci-dessus? A savoir lazy-loading utilise le "Load" ou "Include" au besoin?

Merci !

[Pragmateek]

Un lien pour cela? ou s'agit il simplement de ce qui a ete mentionne ci-dessus? A savoir lazy-loading utilise le "Load" ou "Include" au besoin?

C'est ce qui a été mentionné au-dessus.

Pour résumer voici la typologie des politiques de chargement :
- immédiat : via Include
- différé :
....- automatique : via le lazy-loading
....- manuel : via Load

[katkiller]

Voici un petit lien :

Loading Related Entities

[trihanhcie]

Merci !