Linq To SQL intérêts

Version imprimable

20/06/2011, 11h37
sheitancrew

Linq To SQL intérêts

Bonjour,

( C#, framework 3.5, VS 2008)

J'ai à faire une présentation dans le cadre de mes études sur Linq to SQL, sachant que je travaille actuellement avec des DataSets typés.

Seulement, malgré mes longues recherches j'ai vraiment du mal à dégager un intéret à cette technologie, ses points forts par rapport aux Datasets...

J'ai cru comprendre que l'atout majeur de LINQ était de garder une même requete, un même "Fill", adaptable à plusieurs sources de données.
Donc dans l'hypothèse ou ma base de données migre de SQL Server vers autre chose, mon code sera toujours viable tandis que ma requête stockée dans mon Dataset elle serait obsolète ??

Je dois également la comparer à ses concurrentes, à savoir visiblement Hibernate.

Tout ceci est encore très flou pour moi...

Je vous remercie d'avance pour les précisions et réponses que vous pourriez m'apporter.

Marc
20/06/2011, 11h45
sheitancrew

Linq to Entities

J'ai aussi la possibilité d'étudier Linq to Entities à la place de Linq to SQL mais j'ai les mêmes difficultés à assimiler ce concept....

Encore merci d'avance, je suis au fond la ...!
20/06/2011, 13h33
Er3van

Je pense que tu auras la réponse à la plupart de tes questions ici, on en a débattu très récemment.

Et c'est plutôt NHibernate en .Net, mais ce n'est pas forcément un "concurrent".

Disons que tu as plusieurs approches :
- Procédure stockées
- Linq to SQL (pour moi sur la voie de l’obsolescence)
- Linq to Entities (Entity Framework)
- NHibernate
- ...

Qui se justifient en fonction de pas mal de critères :
- Taille du projet
- Volume et structure de la base données
- Orientation performance forte ou faible
- Délais/planning du projet
- Compétence de l'équipe en SQL et/ou ORM
- ...
20/06/2011, 13h42
tomlev
Linq to SQL est un ORM, c'est à dire qu'il fait le lien entre un modèle objet (des classes) et un modèle physique de données (la base de données).

Linq to SQL tire partie de Linq (Language INtegrated Query), une fonctionnalité de C# qui permet d'effectuer des requêtes sur des modèles objet. Linq to SQL convertit la requête C# "objet" en requête SQL, exécute la requête sur la base de données, et matérialise le résultat sous forme d'objets.

Les DataSets typés n'ont pas grand chose à voir avec ça, malgré les apparences... Quand tu fais un Fill d'un DataSet, ça exécute une requête SQL prédéfinie (habituellement générée par le designer), et ça charge le résultat dans les DataTables. Ensuite tu travailles sur ces données en mémoire, et c'est seulement quand tu as fini de travailler dessus que tu appliques les changements à la base de données : c'est ce qu'on appelle le mode déconnecté.

Avec Linq to SQL, on travaille en mode connecté. On manipule directement la base de données, pas une copie en mémoire des données. Ca s'utilise de façon beaucoup plus naturelle : ton code C# représente la requête qui sera exécutée en base (alors qu'avec un DataSet tu fais simplement appel à Fill, pour voir à quoi ça correspond il faut que tu ailles voir la définition du DataAdapter).

Soit dit en passant, Linq to SQL est obsolète (ou en passe de le devenir ; il me semble que MS a annoncé que c'était abandonné) : il faut utiliser Entity Framework (aka Linq to Entities). Le principe est le même, mais il y a au moins 2 avantages importants :
- ça peut marcher avec n'importe quel SGBD, pas seulement SQL Server ; il faut juste qu'il existe un provider Entity Framework pour ce SGBD, mais la plupart des éditeurs en fournissent un (Oracle est encore à la bourre, mais je crois qu'ils travaillent dessus)
- on peut modéliser les données de façon beaucoup plus souple que dans Linq to SQL, notamment pour les associations N-N et l'héritage
20/06/2011, 15h17
sheitancrew

Merci à vous.
Après avoir consulté le post suggéré ainsi que vos remarques, j'en conclue que je vais plus m'orienter vers une présentation et une utilisation de Linq to Entities.

Pour ma part ces informations très interessantes auraient méritées d'être un peu plus vulgarisées.

Je n'ai en revanche pas trouvé de points forts par rapport à NHibernate..

Merci
20/06/2011, 15h33
Nathanael Marchand

Citation:

Envoyé par tomlev

Oracle est encore à la bourre, mais je crois qu'ils travaillent dessus

Il est actuellement en beta publique :)
Un éditeur tiers en propose un (j'ai plus la référence sous la main).
20/06/2011, 15h34
Er3van

Citation:

Envoyé par sheitancrew

Pour ma part ces informations très interessantes auraient méritées d'être un peu plus vulgarisées.

Lesquelles ? Etant donné la complexité réelle de cache un ORM, difficile de rentrer dans le détail et de parler des avantages/inconvénients sans utiliser les termes "code généré" ou "plan d'exécution"...

Citation:

Envoyé par sheitancrew

Je n'ai en revanche pas trouvé de points forts par rapport à NHibernate.

NHibernate c'est l'ORM des "gros projets".
Entity Framework, c'est l'ORM des "petits projets".

Entity Framework est facile à implémenter/utiliser, intégré dans le framework et donc interfacé dans Visual Studio, pratique pour faire des lectures à la volée, mais mauvais pour faire des opérations de masses (lecture/écriture/suppression de plusieurs dizaines de milliers de lignes).

NHibernate est plus configurable, plus "robuste" (encore que...), plus performant (encore que ça dépende de l'utilisation).
20/06/2011, 16h38
sheitancrew

Merci pour les différences NHibernate vs Linq to Entities, c'est ce que j'avais cru comprendre, j'en ai confirmation.

Concernant la vulgarisation, c'est par exemple pour moi qui utilise depuis 1 an les Datasets, qu'est ce qui pourrait me convaincre de passer à Linq ?

Merci beaucoup
20/06/2011, 16h38
tomlev

Citation:

Envoyé par Nathanael Marchand

Un éditeur tiers en propose un (j'ai plus la référence sous la main).

C'est DevArt

Citation:

Envoyé par Er3van

pratique pour faire des lectures à la volée, mais mauvais pour faire des opérations de masses (lecture/écriture/suppression de plusieurs dizaines de milliers de lignes).

On pourrait dire la même chose de tous les ORM, y compris NHibernate... si tu veux faire des opérations de masse, il vaut mieux les faire directement en SQL, ou même en procédure stockée
24/06/2011, 10h44
WOLO Laurent

Pour vous faire une idée sur les perfs des ORM, clique ici vous trouverez ca sur ce poste
24/06/2011, 11h04
Er3van

Se méfier quand même de la véracité des Benchmark fait par les acteurs du marchés...
24/06/2011, 12h26
WOLO Laurent

C'est vrai mais ca vous donne une idée et vous emmene à vous poser des bonnes questions et voir pourquoi pas faire les tests quand vous avez la possibilité pour valider.
D'une manière générale, un ORM, il faut bien le maitriser pour mieux l'utiliser.
En règle général, suivez juste les best-practices sur l'écriture des couches d'accès aux données et vous saurez déjouer la plupart des pièges en la matière et vous aurez déjà une bonne base pour vous interroger utilement ?
02/07/2011, 11h34
sheitancrew

NHibernate vs Linq to Entities

Bon, mon projet touche à sa fin.

Mais j'aimerais connaitre les point forts / points faibles de Linq to Entities comparée a NHibernate,
notamment pour les critères cités ci-dessous

- taille projet ( petit projet, on choisit => Linq ?)
- Volume BD (idem ? )
- Performance (optimiser perf. => NHibernate ? )
- Délais ( courts => Linq ? )
- Compétence SQL ( faible => Linq ? )

Et globalement les points forts de chaque techno.

Merci beaucoup de m'apporter toutes ces réponses.
03/07/2011, 11h33
Immobilis

Salut,

NHibernate, je sais pas trop, mais tu peux toujours jeter un oeil ici et prendre exemple sur le code pour comparer: http://immobilis.developpez.com/tuto...ity-framework/

A+
03/07/2011, 20h45
sheitancrew

Merci pour le lien.

Personne pour m'apporter quelques réponses ??

Malgré mes recherches, je sèche toujours...
04/07/2011, 09h46
Er3van

Citation:

Envoyé par sheitancrew

Bon, mon projet touche à sa fin.

Mais j'aimerais connaitre les point forts / points faibles de Linq to Entities comparée a NHibernate,
notamment pour les critères cités ci-dessous

- taille projet ( petit projet, on choisit => Linq ?)
- Volume BD (idem ? )
- Performance (optimiser perf. => NHibernate ? )
- Délais ( courts => Linq ? )
- Compétence SQL ( faible => Linq ? )

Et globalement les points forts de chaque techno.

Merci beaucoup de m'apporter toutes ces réponses.

Mes réponses basées sur mes critères, qui n'engagent que moi :

Ici, j'entends par "petit projet", un projet de moins de 100 JH de développements, avec maximum 5 développeurs.
Un gros projet, par opposition, c'est plus de 300 JH de développements, une dizaine de développeurs.

Petit projet : Entity Framework :ccool:
NHibernate est plus long à implémenter et prendre en main.

"Gros projet" : NHibernate se justifie pleinement, mais attention toutefois, il reste plus long à prendre en main. Entites Framework peut toujours être utilisé.

Volume DB : Plus que la taille de la DB, je dirais que c'est les accès qui vont faire la différence. Comme le montre le benchmark d'Immobilis, Entity Framework n'est pas très performant à l'écriture, mais se débrouille plutôt bien en lecture. NHibernate est plutôt moyen partout je dirais.

Performance : c'est assez lié, mais sur certains points, Entity Framework n'est pas très performant, notamment les écritures de masses (>500 enregistrements d'un coup).

Délais : si tu as un planning serré, EF c'est une valeur fiable, c'est maintenu par Microsoft, tu as tout sur le MSDN... moins de risque de planter le planning !

Compétences SQL : D'une manière générale, pour tous les ORM il faut qu'il y ait des compétences SQL derrière... si tu as un DBA en support c'est un plus.

Globalement, je dirais que le point fort d'EF c'est d'être facile à implémenter, pas trop mauvais au niveau des performances en lecture. En gros, pour utiliser dans une appli web basique, c'est vraiment bien.
En revanche, pour faire tourner des batchs de facturations, là c'est un choix un peu plus discutable...
04/07/2011, 10h18
BenoitM

Je pense qu'il ne faut pas trop prendre en compte le temps de la prise en main d'une technologie car celle-ci ce réparti sur tous tes projets...

Et pas oublier que qui peut le plus peut (souvent) le moins
04/07/2011, 11h00
sheitancrew

Un grand merci !
04/07/2011, 11h16
Er3van

Citation:

Envoyé par BenoitM

Je pense qu'il ne faut pas trop prendre en compte le temps de la prise en main d'une technologie car celle-ci ce réparti sur tous tes projets...

Et pas oublier que qui peut le plus peut (souvent) le moins

Oui et non, dans certaines entreprises (dont la mienne) on travaille avec beaucoup de prestataire de service, et également des collaborateur sur des sites nearshore et offshore, avec des gros turnover... du coup ce n'est pas aussi simple de mutualiser ou de conserver les compétences techniques sur plus d'un ou deux ans.

J'imagine ne pas être le seul dans ce cas, du coup ce critère peut s'appliquer à d'autres (mais pas à tous j'y consens).

Salut

Citation:

Envoyé par Er3van

Mes réponses basées sur mes critères, qui n'engagent que moi

Ce qui m’intéresserait c'est de connaître les mesures sur lesquelles tu te reposes pour forger ton opinion.

Je viens de faire un fournisseur pour NHibernate et j'ai tenté de passer mon programme dessus. Une catastrophe!!! Plus de 5 minutes pour faire la totalité des mises à jour. Je ne parle que des mises à jour des 8000 enregistrements. Si on ajoute les insertions et les lectures c'est la fête...

Comme je ne suis pas un pro de NHibernate, je te passe le code du fournisseur:

Code:

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
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
using System;
using System.Collections.Generic;
using Model;
using NHibernate;
using NHibernate.Cfg;
 
namespace Dal
{
    public class NHibernateHelper
    {
        private static ISessionFactory _sessionFactory;
 
        private static ISessionFactory SessionFactory
        {
            get
            {
                if (_sessionFactory == null)
                {
                    var configuration = new Configuration();
                    configuration.Configure();
                    configuration.AddAssembly(typeof(CustomerEntity).Assembly);
                    _sessionFactory = configuration.BuildSessionFactory();
                }
                return _sessionFactory;
            }
        }
 
        public static ISession OpenSession()
        {
            return SessionFactory.OpenSession();
        }
    }
 
    public class NHibernateCustomerProvider : ICrud<CustomerEntity>
    {
        private ISession session = NHibernateHelper.OpenSession();
 
        private bool disposed = false;
 
        public Guid Create(CustomerEntity obj)
        {
            obj.Id = Guid.NewGuid();
 
            using (ITransaction transaction = session.BeginTransaction())
            {
                try
                {
                    session.Save(obj);
                    transaction.Commit();
                }
                catch (Exception e)
                {
                    transaction.Rollback();
                    throw e;
                }
            }
            return obj.Id;
        }
 
        public CustomerEntity Read(CustomerEntity obj)
        {
            return session.Get<CustomerEntity>(obj.Id);
        }
 
        public IEnumerable<CustomerEntity> Read()
        {
            return session.QueryOver<CustomerEntity>().List();
        }
 
        public bool Update(CustomerEntity obj)
        {
            using (ITransaction transaction = session.BeginTransaction())
            {
                try
                {
                    session.SaveOrUpdate(obj);
                    transaction.Commit();
                }
                catch (Exception e)
                {
                    transaction.Rollback();
                    throw e;
                }
            }
            return true;
        }
 
        public bool Delete(CustomerEntity obj)
        {
            using (ITransaction transaction = session.BeginTransaction())
            {
                try
                {
                    session.Delete(obj);
                    transaction.Commit();
                }
                catch (Exception e)
                {
                    transaction.Rollback();
                    throw e;
                }
            }
            return true;
        }
 
        #region IDisposable
 
        public void Dispose()
        {
            if (!disposed)
            {
                Dispose(true);
                GC.SuppressFinalize(this);
            }
            disposed = true;
        }
 
        ~NHibernateCustomerProvider()
        {
            Dispose(false);
        }
 
        private void Dispose(bool disposing)
        {
            if (disposing)
            {
                session.Dispose();
            }
        }
 
        #endregion
    }
}

Mais bon, des chiffres SVP...

A+

04/07/2011, 15h24
Nathanael Marchand

NHibernate possède plusieurs niveaux de cache ce qui peut le rendre très efficace. Le problème avec cet outil c'est qu'ils est assez complexe à configurer correctement et la doc sur NHibernate est une vaste blague!
04/07/2011, 15h31
Immobilis

Voici les perfs du fournisseur NHibernate:

http://immobilis.developpez.com/tuto...NHibernate.png
Les requêtes SQL sont correctes, mais quand je regarde SQL Server Profiler, elles sont envoyées à un rythme très faible. J'ai l'impression que beaucoup de temps est perdu lors du mapping.
04/07/2011, 15h32
Er3van

Citation:

Envoyé par Immobilis

SalutCe qui m’intéresserait c'est de connaître les mesures sur lesquelles tu te reposes pour forger ton opinion.

Je n'ai jamais fait de benchmark si c'est la question !
Simplement par retours d'expérience je sais que NHibernate, quand il est bien configuré, a globalement de meilleurs performances que Entity Framework, (sauf peut-être pour de la lecture).

Citation:

Envoyé par Immobilis

Je viens de faire un fournisseur pour NHibernate et j'ai tenté de passer mon programme dessus. Une catastrophe!!! Plus de 5 minutes pour faire la totalité des mises à jour. Je ne parle que des mises à jour des 8000 enregistrements. Si on ajoute les insertions et les lectures c'est la fête...

C'est le problème, même si je suis convaincu qu'un expert NHibernate trouverait plein de trucs à changer dans ce code, et dans le paramétrage de NHibernate qui te permettraient d'améliorer celà.

Citation:

Envoyé par Immobilis

Mais bon, des chiffres SVP...

C'est assez difficile d'avoir des chiffres comparables.
En gros, ce que je peux te dire, c'est que le rapport :

Temps passé à configuré + Temps passé à développé
---------------------------------------------------
Performances obtenues

est bien meilleur pour Entity Framework. Mais certaines fois, les performances que tu obtiens justifient le surcoût.
04/07/2011, 15h38
Immobilis

Comme je n'ai jamais utilisé NHibernate avant, j'imagine que beaucoup d'utilisateurs le configureraient comme moi. C'est un peu décevant de voir des perfs aussi mauvaises dans une configuration de base.

Si quelqu'un voit des moyens d'améliorer le fournisseur, je peux faire d'autres tests.
04/07/2011, 16h18
iberserk

Bonjour à tous,

Citation:

Comme le montre le benchmark d'Immobilis, Entity Framework n'est pas très performant à l'écriture, mais se débrouille plutôt bien en lecture.

Citation:

En gros, pour utiliser dans une appli web basique, c'est vraiment bien.
En revanche, pour faire tourner des batchs de facturations, là c'est un choix un peu plus discutable...

Comme glissé à Immobilis par MP parallèlement à son article de Benchmark, j'ai envi de dire que pour ma part, c'est tout ce que je demande à EF:
Mapper mes objets dans le cadre de SELECT, cela fait gagner un temps fou lors de la phase de DEV...

Dès que plusieurs lignes sont à traiter, c'est automatique: passer le C UD en procédure stockée lancées par EF et le tour est joué...

Ce n'est pas lié à une faiblesse des ORMs mais au fait que le code client (entendez CSHARP) ne peut pas traiter de manière ensembliste un jeu de données...

Donc l'idéal pour moi :
C+U+D en procédure stockée
R laissé à EF et LINQ TO SQL...
04/07/2011, 16h35
Immobilis

Citation:

Envoyé par iberserk

Donc l'idéal pour moi :
C+U+D en procédure stockée
R laissé à EF et LINQ TO SQL...

+1
Et encore. La lecture peut aussi être faite sous forme de procédure stockée. Mais bon, difficile d'avoir des procédures pour chaque cas d'utilisation suivant qu'on souhaite faire remonter plus où moins de champs.
04/07/2011, 16h39
iberserk
Citation:

Et encore. La lecture peut aussi être faite sous forme de procédure stockée. Mais bon, difficile d'avoir des procédures pour chaque cas d'utilisation suivant qu'on souhaite faire remonter plus où moins de champs.

En fait vous feriez plutôt des fonctions SQL de type table qui peuvent prendre en entrée des paramètres et qui vous retourne une table.
Vous pouvez ainsi faire comme ceci:
Code:

1 2 SELECTcol1,col2 FROM dbo.FN_GET_COMMANDES_OF_CLIENt(3) WHERE dateCommande >GETDATE()-10
Avantage: celà vous retourne un IQUERYABLE qui peut donc 'subir' du LINQ TO SQL derrière, contrairement à une procédure stockée qui vous retournera une exception si vous faites ne serait-ce qu'un COUNT() dessus...