Discussion :

[Immobilis]

Ce type de clef découle d'une modélisation respectant les règles de gestion.

C'est justement ce qu'il faut éviter. Les règles de gestion métier sont changeantes, incomplètes, dépendantes des méthodes de travail. Cela fait porter un risque sur l'intégrité de la base de données. A mon avis, les clefs ne devraient être que des identifiants uniques auto-générés (guid, entier). L'intégrité des données peut être garanties par d'autres moyens triggers, contraintes, ...

Avec Code First, c'est en fait la DB qui s'adapte au code.

Je ne dirai pas ça comme ça mais plutôt le modèle (le terme est important) est créé via une IHM de design dans Visual Studio. Le produit obtenu est un script SQL.

Sinon, les approches modèle et code first sont similaires. Dans le premier cas, je dirai qu'on se laisse guider par un assistant et comme en général le model est souvent très proche de la structure de la base (ou inversement), c'est une excellente entrée en matière.

Une fois la DB correctement normalisée et après vérification de toutes règles de gestion par la MOA

Si le modèle se base sur des métadonnées cela devient difficile à montrer. Dans les cas "normaux", cela se fait aussi très bien avec EF et Visual Studio.

j'utilise EF en Database-First avec modèle T4 d'objets POCO et j'en suis satisfaite

Faudrait que j'essaye ça aussi.

Quelque soit l'approche c'est surtout une question d'affinité avec les outils de développement. Il n'y a pas UNE façon de développer.

A+

[plume13]

Quelque soit l'approche c'est surtout une question d'affinité avec les outils de développement. Il n'y a pas UNE façon de développer.

Oui tu as raison de le rappeler. J'ai tendance à chercher la forme de programmation ultime mais finalement, la bonne programmation c'est celle qui colle à nos besoins

[rv26t]

@Kropernic

mise à part la factory où, selon l'exemple de l'article, les noms des objets sont hard codés...

Justement, j'ai fait une petite modif de ce coté. J'essayerais de faire un billet.
J'ai rendu la méthode générique (note : je ne parle pas des paramètres de la requête pour GetSingleDTO que je passe de façon particulière, ce n'est pas le but du sujet)

Voici la méthode GetListDTO avec les classes de travail générique en paramètres (T pour le type de classe parser, V pour le type de classe DTO qui constituera la liste) pour répondre à toutes construction de liste de DTO de façon générique. (mais avec des éléments typés) (GetSingleDTO idem)

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
    ''' <summary>Lit plusieurs lignes de données renvoyé sous forme d'une liste d'instance de classe DTO définie par l'appelant.</summary>
    ''' <typeparam name="T">Type de classe analyseur qui sera utilisé pour créer un DTO léger recevant les données.</typeparam>
    ''' <typeparam name="V">Type de classe DTO léger recevant les données.</typeparam>
    ''' <param name="Requete">La requête de sélection.</param>
    ''' <returns>Une liste d'instances de classe DTO pour l'ensemble de ligne de données.</returns>
    ''' <remarks>Méthode générique ne connaissant pas le type de classe analyseur en entrée, ni le type de DTO.
    ''' Une fabrique générique renvoie une instance de cette classe analyseur, une méthode de cette instance (PopulateDTO) retourne une instance DTO léger contenant l'ensemble d'une ligne de données.
    ''' Une boucle permet la lecture de toutes les lignes et d'alimenter la liste retournée. Une liste de DTO correspondant au type (V) (passé en paramètre) est ainsi constituée, et renvoyée.</remarks>
    Public Function GetListDTO(Of T As {New}, V)(ByVal Requete As String) As List(Of V)
        Dim ListeDTO As List(Of V) = New List(Of V)
                    ' suite code ...
                    ' ...
                    parser = DTOParserFactory.FabriqueClasse(Of T)()
                    ' suite code ...
                    ' ...
                    Return ListeDTO

Le paramètre peut rester (ByRef command As SqlCommand) comme dans le tuto au lieu de la requete

[meziantou]

D’un côté, certains préfèrent tout écrire à la main en utilisant directement ADO.NET sans surcouche. D’un autre côté les fervents défenseurs des ORM. En gros d’un côté on aime faire de la plomberie alors que de l’autre non . Personnellement je n'aime pas la plomberie mais je n'utilise pas pour autant un ORM.

Je tenais juste à présenter un produit avec une approche différente : CodeFluent Entities. En gros comme Entity Framework, on part d’un modèle représentant des entités, des énumérations, des propriétés, des méthodes, des règles, des vues, etc. (on peut modéliser un peu plus de concepts qu’EF (le document date de 2012 mais beaucoup de choses restent vraies)). On ajoute ensuite des producteurs dont le but est de générer le code (SQL Server, Oracle, PostgreSQL, C#, VB.NET, WCF, Proxy WCF, ASP.NET, etc.). Tout le code généré est statique (Procédures stockés, code d’accès aux données…) et pour l'accès aux données, seuls des procédures stockées et ADO.NET sont utilisés, ce qui devrait plaire à rv26t .
A vrai dire il y a une très légère surcouche nommée CodeFluentPersistence dont le but est de masquer les différences entre les différents SGBD, notamment au niveau des paramètres (par exemple certains utilisent @param, d'autres :param) ou des erreurs (duplicate, concurrence). Bref ça reste très très léger.

On a donc les avantages d’une approche Model-First tout en ayant au final un code totalement statique et facilement lisible (donc debuggable au besoin). Pour ceux qui se demandent quels sont les avantages du model first.

Pour ceux qui veulent refaire un semblant de CodeFluent Entities avec EF (oui on en est encore assez loin), vous pouvez regarder le blog de Matthieu Mezil et son WAQS (c’est un fan absolu d'EF et des T4).

Il ne faut pas non plus oublier un problème assez important vis à vis d'Entity Framework : le travail en équipe est un véritable calvaire !

CodeFluent Entities gèrent cela sans trop de problème. Le modèle peut être découpé en autant de fichiers que nécessaire (un par entité, un par namespace, ou autre), alors qu'avec EF on a un fichier EDMX pour tout le modèle. Au niveau du designer on peut spécifier quels éléments doivent être affichés sur chaque surfaces (contrairement à EF on peut avoir plusieurs surfaces). Cela permet également de travailler avec de gros modèle.

[rv26t]

@meziantou
Merci pour ces infos (désolé pour le temps de réponse)
Connaître d'autres solutions telle que celle que tu présentes est très intéressant.
Cela permet de choisir la meilleure approche suivant le type de projet.

A ce titre il me semble judicieux d'indiquer aussi l'existance de Dapper qui est vraiment très léger et permet une approche très simple.

[aserf]

Quel 'on utilise tel ou tel outils les performances ne changerons pas énormément au global.
Le plus gros goulet d'étranglement est lors de l'insertion dans la base de données des modifications.

Gagner quelle que milliseconde lors de l'affectation d'une valeur dans l'objet ne changera pas grand chose si on arrive à diviser par 10 l'insertion dans la base de données.
C'est pour sa que j'ai développer mes propres outils (qui ce base sur les DataTable ou sur EF4&5), et les facteurs dans certain contexte sont de 1 a 200 (de 1h on peu passer à 20s).

[rv26t]

Bonjour aserf,

La série de tutoriels concerne plus la lecture des données. Surtout pour un ensemble important de lignes pour une utilisation dans certains cas particuliers ou la performance est souhaitée.
En ce qui concerne l'insertion ou la modification, le tutoriel montre juste une méthode classique pour insérer/modifier une ligne et ne s'étend pas sur le sujet.

Mais pour répondre à votre remarque, dans le cas d'insertion ou de modification, généralement :
- Soit l'utilisateur effectue une saisie pour insérer ou mettre à jour une ligne, auquel cas le temps d'accès sera faible.
- Soit il met à jour un ensemble de ligne, mais c'est une seule requête qui effectue la manip, et les performances dépendent du SGBD. (Enfin surtout de la requête, de la structure des tables, index, ....)
- Soit il s'agit de traitement important - importation d'un autre système, traitement de mise à jour en masse - auquel cas cela est effectué de nuit par des batchs.