Discussion :

[Kropernic]

Bonjour à tous,

Je viens quémander un peu d'aide pour débarbouiller un bout de code que j'ai écrit car je n'arrive pas à produire ce que je veux de manière propre.
Mes problèmes se posent au niveau de l'héritage et de la surcharge de propriété.

Dans la classe de base, j'ai une propriété d'un type de base. Dans la classe dérivée, j'ai une propriété d'un type dérivé aussi. Mais du coup, si j'instancie la classe dérivée, je me retrouve avec la propriété en double...

Sans plus d'introduction, voici le code en question :

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
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
134
135
136
137
138
139
140
141
142
143
144
145
146
Public MustInherit Class PromoDetail
    Public Property DTO As PROMO_DTO.PromoDetail
 
    Public Sub New(d As PROMO_DTO.PromoDetail)
        Me.DTO = d
    End Sub
 
    Public Function GetProducts() As List(Of PROMO_DTO.Product)
        If Me.DTO.Products.Count > 0 Then
            Return Me.DTO.Products
        ElseIf Me.DTO.ProductsOut.Count > 0 Then
            Return Me.DTO.ProductsOut
        Else
            Return Nothing
        End If
    End Function
 
    'Public MustOverride Sub FlagAsEncoded()
 
End Class
 
Public Class PromoDetailDemo
    Inherits PromoDetail
 
    Public Overloads Property DTO As PROMO_DTO.PromoDetailDemo
 
    Public Sub New(dto As PROMO_DTO.PromoDetailDemo)
        MyBase.New(dto)
        Me.DTO = dto
    End Sub
 
    Public Sub Delete()
        PROMO_DAL.PromoDetail.Delete(Me.DTO.Id)
    End Sub
End Class
 
Public Class PromoDetailsDemo
 
    Public Overloads Property DTO As List(Of PROMO_DTO.PromoDetailDemo)
 
    Public Sub New()
        Me.DTO = New List(Of PROMO_DTO.PromoDetailDemo)
    End Sub
 
    Public Sub New(dto As List(Of PROMO_DTO.PromoDetailDemo))
        Me.DTO = dto
    End Sub
 
    Public Sub Save(prm_id As Integer, ba_id As Byte)
        If CheckPercentageIsUniqueForList() Then
            PROMO_DAL.PromoDetail.SaveDemo(prm_id, ba_id, Me.DTO)
        Else
            Throw New EncodingDemoException("duplicate percentage", DTO(0).CodeDemo)
        End If
    End Sub
 
    Friend Function CheckPercentageIsUniqueForList() As Boolean
        Dim result As Boolean = True
        Dim percentList = (From dto In Me.DTO
                           Where dto.PercentType.Description = "LIST"
                           Select dto.Percentage)
 
        For Each p As Decimal In percentList.ToList
            If (From dto In Me.DTO
                Where dto.Percentage = p AndAlso dto.PercentType.Description = "LIST"
                Select dto).ToList.Count > 1 Then
                result = False
            End If
        Next
        Return result
    End Function
 
    Public Sub GetProducts()
        For Each d As PROMO_DTO.PromoDetailDemo In Me.DTO
            d.Products = PROMO_DAL.Product.GetDemoProduct(d.Id)
            d.ProductsOut = PROMO_DAL.Product.GetDemoProductOut(d.Id)
        Next
    End Sub
End Class
 
Public Class PromoDetailOwn
    Inherits PromoDetail
 
    Public Overloads Property DTO As PROMO_DTO.PromoDetailOwn
 
    Public Sub New(dto As PROMO_DTO.PromoDetailOwn)
        MyBase.New(dto)
        Me.DTO = dto
    End Sub
End Class
 
Public Class PromoDetailsOwn
    Public Property DTO As List(Of PROMO_DTO.PromoDetailOwn)
 
    Public Sub New()
        DTO = New List(Of PROMO_DTO.PromoDetailOwn)
    End Sub
 
    Public Sub New(dto As List(Of PROMO_DTO.PromoDetailOwn))
        Me.DTO = dto
    End Sub
 
    Public Sub Save(prm_id As Integer, ba_id As Byte)
        PROMO_DAL.PromoDetail.SaveOwn(prm_id, ba_id, Me.DTO)
    End Sub
 
    Public Sub GetProducts()
        For Each d As PROMO_DTO.PromoDetailOwn In Me.DTO
            d.Products = PROMO_DAL.Product.GetOwnProduct(d.Id)
            d.ProductsOut = PROMO_DAL.Product.GetOwnProductOut(d.Id)
        Next
    End Sub
End Class
 
Public Class PromoDetailDepartment
    Inherits PromoDetail
 
    Public Overloads Property DTO As PROMO_DTO.PromoDetailDepartment
 
    Public Sub New(dto As PROMO_DTO.PromoDetailDepartment)
        MyBase.New(dto)
        Me.DTO = dto
    End Sub
End Class
 
Public Class PromoDetailsDepartment
    Public Property DTO As List(Of PROMO_DTO.PromoDetailDepartment)
 
    Public Sub New()
        Me.DTO = New List(Of PROMO_DTO.PromoDetailDepartment)
    End Sub
 
    Public Sub New(dto As List(Of PROMO_DTO.PromoDetailDepartment))
        Me.DTO = dto
    End Sub
 
    Public Sub save(prm_id As Integer, ba_id As Byte)
        PROMO_DAL.PromoDetail.SaveDepartment(prm_id, ba_id, Me.DTO)
    End Sub
 
    Public Sub GetProducts() 'there is no inclusive list for department
        For Each d As PROMO_DTO.PromoDetailDepartment In Me.DTO
            d.ProductsOut = PROMO_DAL.Product.GetDeptProductOut(d.Id)
        Next
    End Sub
End Class

Il y a probablement plein de trucs à corriger là-dedans et, n'ayant jamais eu de vrai cours de POO ni aucun "expert" dans mon antourage avec qui échanger sur le sulet, je suis bien conscient, qu'en terme de POO, je fais de la merde. Donc lachez-vous, pour ce coup-ci, tout est permis .

[Pol63]

overloads sert à ajouter quelque chose du même nom
overrides sert à remplacer dans un héritage, mais il ne peut etre utiliser que pour quelque chose de similaire (type et signature)

donc ca n'ira pas dans ton cas

par contre en général on utilise juste la propriété de base as le type de base, car tu peux ranger une instance de PromoDetailOwn dans une propriété de type PromoDetail vu qu'il y a héritage

il faudrait détailler l'utilité de tout ca sinon

[Kropernic]

overloads sert à ajouter quelque chose du même nom
overrides sert à remplacer dans un héritage, mais il ne peut etre utiliser que pour quelque chose de similaire (type et signature)

donc ca n'ira pas dans ton cas

Ah bin c'est ce que j'avais compris et je pensais que je faisais fausse route... Zut !

par contre en général on utilise juste la propriété de base as le type de base, car tu peux ranger une instance de PromoDetailOwn dans une propriété de type PromoDetail vu qu'il y a héritage

Mais si je mets une instance de PromoDetailOwn dans une propriété de type PromoDetail, quand je tente d'accéder à la propriété, toutes les propriétés (publiques) de la classe PromoDetailOwn sont-elles alors bien accessibles ? Mon problème de compréhension/utilisation se situe quelque part ici je pense.

il faudrait détailler l'utilité de tout ca sinon

Ca par contre, ça risque d'être fort long car c'est plein de concept et jargon propre à l'entreprise où je bosse... Du coup, j'aimerais autant éviter ^^

[Pol63]

Mais si je mets une instance de PromoDetailOwn dans une propriété de type PromoDetail, quand je tente d'accéder à la propriété, toutes les propriétés (publiques) de la classe PromoDetailOwn sont-elles alors bien accessibles ? Mon problème de compréhension/utilisation se situe quelque part ici je pense.

ca dépend ^^

depuis visual studio l'intellisense va te l'interdire
par contre on peut faire if typeof instance is teltype then directcast(instance,teltype).propriété

mais si tu dois faire ca souvent ca veut dire qu'il y a un problème de conception

normalement avec le polymorphisme on s'arrange pour ne pas se soucier de ce que c'est
par exemple si tu as des produits en stock propre, et des produits en dépot vente, ils ont tous les 2 un fonctionnement différent lors d'une vente
sur le produit en stock tu décrémentes le stocks et ajoute le prix sur ton compte
pour le produit en dépot vente tu décrémentes le stock, tu ajoute une partie du prix sur ton compte et le reste est à restituer à un tiers

dans ce cas les 2 classes ont une méthode Vente(nb as integer)
le 1er tu fais x requetes en bases (update stock, update moncompte)
le 2ème tu fais d'autres requetes (update stock, upate moncompte, insert into argentàrestituer)

par contre au niveau du code tu travailles avec des collections typées sur l'instance de base, et tu fais juste .vente sans te poser de question

ca sert à ca le polymorphisme, quand tu rajoutes une classes (même 6 mois après) tu la fait rentrer dans le moule de ce qu'on peut faire dessus, et tu codes ce qu'elle a de spécifique
par contre il faut arriver à abstraire tout le fonctionnement pour n'avoir que des membres génériques (il arrive parfois qu'on ait un ou deux trucs spécifiques, et c'est là qu'intervient le typeof/directcast, ou des interfaces quand on a trop de spécificités, genre IGereStock)

[Kropernic]

Bon puisque t'as l'air de connaître le principe, je rentre plus en détail alors (ou alors j'avais p-e déjà expliqué dans une autre discussion^^).

Le problème est effectivement de différencier le stock propre du dépôt vente. Mais je ne travaille pas sur les produits en eux-même. Je travaille sur les promos qui les concernent.

Au départ, il y a donc la promo qui malgré sa chiée de propriétés est une classe assez simple (j'ai viré le constructeur pour plus de concision).
N.B. : Mes DTO's ne sont pas de vrai DTO car certains contiennent une méthode ToString et des propriétés qui sont calculées

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
Public Class Promo
    Implements DtoBase
 
    Public Property Isnew As Boolean Implements DtoBase.Isnew
 
    Public Property Id As Integer
    Public Property Description As String
    Public Property Surtype As Surtype
    Public Property Type As PromoType
    Public Property StartDate As Date
    Public Property EndDate As Date
    Public Property StartTime As TimeSpan
    Public Property EndTime As TimeSpan
    Public Property Validated As Boolean
    Public Property ValidatedOn As DateTime
    Public Property Encoded As Boolean
    Public Property EncodedOn As DateTime
    Public Property Released As Boolean
    Public Property ReleasedOn As DateTime
    Public Property Tested As Boolean
    Public Property TestedOn As DateTime
 
    Public Property DetailsDemo As List(Of PromoDetailDemo)
    Public Property DetailsOwn As List(Of PromoDetailOwn)
    Public Property DetailsDepartment As List(Of PromoDetailDepartment)
    Public Property Targets As List(Of Target)
    Public Property Stores As List(Of Store)
    Public Property Days As List(Of Day)
 
End Class

Une promo peut porter sur 3 choses :

1. Du stock propre (propriété DetailsOwn)
2. Du stock en dépôt vente (propriété DetailsDemo)
3. Tout un rayon de stock propre (propriété DetailsDepartment). C'est un cas particulier, oublions-le pour le moment.

Pour le stock propre, on a besoin :

• d'une description
• d'une remarque (facultatif)
• du rayon
• de la marque
• du pourcentage à appliquer
• de la liste des articles sur lesquels la promo s'applique (inclusion) ou ne s'applique pas (exclusion). C'est l'un ou l'autre, pas les deux.

Pour le stock en dépôt vente on a besoin :

• d'une description
• d'une remarque (facultatif)
• du code démo (qui est un code unique faisant référence à une triple (rayon, fournisseur, marque))
• du pourcentage à appliquer
• de la liste des articles sur lesquels la promo s'applique (inclusion) ou ne s'applique pas (exclusion). C'est l'un ou l'autre, pas les deux.

Sur base de cela, il me semblait logique de créer une classe de base contenant les points en commun et deux classes dérivées pour les points propres à chaque type.
Ce qui a donné ceci :

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
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
Public Class PromoDetail
    Implements DtoBase
 
    Public Property Isnew As Boolean Implements DtoBase.Isnew
 
    Public Property Id As Integer
    Public Property Description As String
    Public Property Note As String
    'Public Property PriceReduction As Boolean
    Public Property Percentage As Decimal
    Private _listType As String
    Public ReadOnly Property ListType As String
        Get
            Return _listType
        End Get
    End Property
    Private _productCount As Integer
    Public ReadOnly Property ProductCount As Integer
        Get
            Return _productCount
        End Get
    End Property
 
    Private _products As List(Of Product)
    Public Property Products As List(Of Product)
        Get
            Return _products
        End Get
        Set(value As List(Of Product))
            _products = value
            If value.Count > 0 Then
                _listType = "INC"
                _productCount = value.Count
            End If
        End Set
    End Property
 
    Private _productsOut As List(Of Product)
    Public Property ProductsOut As List(Of Product)
        Get
            Return _productsOut
        End Get
        Set(value As List(Of Product))
            _productsOut = value
            If value.Count > 0 Then
                _listType = "EXC"
                _productCount = value.Count
            End If
        End Set
    End Property
 
End Class
 
Public Class PromoDetailDemo
    Inherits PromoDetail
 
    Public Property CodeDemo As CodeDemo
 
End Class
 
Public Class PromoDetailOwn
    Inherits PromoDetail
 
    Public Property Department As Department
    Public Property Brand As Brand
 
End Class

Voilà pour les DTO. Jusque là, je pense que c'est plutôt clair et correct. Du moins je l'espère.

J'ai donc créé les objets de la BLL qui manipulent ces DTO selon la même idée et cela a donné le code que j'ai montré au début de le discussion.

Comment aurais-je du faire ? / Comment aurais-tu fait ?

[Pol63]

Bon puisque t'as l'air de connaître le principe, je rentre plus en détail alors (ou alors j'avais p-e déjà expliqué dans une autre discussion^^).

Alors soit c'est mon inconscient qui a déjà lu ca, soit j'ai tapé dans le mille, c'est en voyant des produits et des Own que j'ai imaginé cet exemple ...



sinon tu as bien décris les données à stocker, mais pas les traitements
parce que niveau stockage ca ne pose pas de problème de polymorpher ^^

sinon je vois bien une classe promo (pas mustinherit, ceci c'est utile en cas de mustoverride surtout)
description
list produits inclus/exclus
is inclusion
...
rayon
marque

et une classe promoDepot inherits avec en plus fournisseur et une propriété qui génère le code démo


mais bon après s'il n'y a pas de méthode sur tes classes ca s'arrete là (ni d'affichage)
et pour stocker tout ca un list(of promo)

[Kropernic]

Alors soit c'est mon inconscient qui a déjà lu ca, soit j'ai tapé dans le mille, c'est en voyant des produits et des Own que j'ai imaginé cet exemple ...

sinon tu as bien décris les données à stocker, mais pas les traitements
parce que niveau stockage ca ne pose pas de problème de polymorpher ^^

sinon je vois bien une classe promo (pas mustinherit, ceci c'est utile en cas de mustoverride surtout)
description
list produits inclus/exclus
is inclusion
...
rayon
marque

et une classe promoDepot inherits avec en plus fournisseur et une propriété qui génère le code démo


mais bon après s'il n'y a pas de méthode sur tes classes ca s'arrete là (ni d'affichage)
et pour stocker tout ca un list(of promo)

Je ne comprends pas ta remarque concernant les traitements.

Y a pas des masses de traitements à faire en fait.

Voici le process :

1. un admin créée une promo (cad définit les dates, le nom, le public cible, les magasins où elle sera active, les jours où elle sera active et le type de promo (actuellement uniquement avec%) et les bureaux d'achats qui peuvent y mettre du contenu)
2. les bureaux d'achats autorisés ajoute du contenu à la promo (ce que j'ai décrit dans mon message précédent).
3. les bureaux d'achats "clôturent" ce qu'ils ont encodés pour dire "j'ai fini"
4. un admin valide la promo donnant le signale à l'équipe caisse pour l'encoder dans le système caisse

Niveau applicatif cela donne :

1. une ligne est créée dans la table promo
2. quand un bureau d'achat accède à une promo, il y a donc un objet BLL.Promo qui contient lui-même un objet DTO.Promo avec toutes les propriétés initialisés sauf DetailsDemo, DetailsOwn* qui sont vides la première fois. S'ils reviennent sur la promo alors qu'ils ont déjà encodé quelque chose, elles sont évidemment initialisées avec ce qu'ils ont encodés
3. pour ajouter du contenu, le bureau d'achat fait ceci :
   
   1. si stock propre :
      
      1. choix du rayon
      2. choix de la(des) marque(s)
      3. choix du types de pourcentages (automatique, popup, sur liste)
         
         1. si auto : choix du pourcentage
         2. si popup : choix des pourcentages
         3. si liste : ajout des listes d'articles (qui contiennent les pourcentages)
      
      
   2. si depôt-vente :
      
      1. choix du rayon
      2. choix du(des) code(s) démo(s)
      3. choix du types de pourcentages (auto, popup, sur liste)
         
         1. si auto : choix du pourcentage
         2. si popup : choix des pourcentages
         3. si liste : ajout des listes d'articles (qui contiennent les pourcentages)

* je laisse DetailsDepartment de côté qui est juste un cas particulier de DetailsOwn.

Et tout cela crée des lignes dans différentes tables de la DB qui est parfaitement normalisée jusqu'en 5 NF voir même p-e 6 NF (de nos jours, il y a les "grammar nazi", moi c'est pareil mais pour la normalisation même si je me suis quelque peu modéré ces derniers-temps).

Le pourquoi j'ai fait ces différentes classes est pour l'affichage dans un DataGridView. Quand je dois afficher des données dans ce type de contrôle, j'initialise les colonnes moi-même et je les lie à la propriété correspondante de la liste d'objets que je passe en datasource. D'où le fait que mes DTO aient tous une méthode ToString histoire que le dgv sache quoi afficher (sinon il m'affiche le type ce con-là ^^).
Et donc, je ne suis pas certain que l'affichage se fasse correctement si je passe une liste de PromoDetails au dgv si elle contient en réalité une liste de PromoDetailsOwn ou de de PromoDetailsDemo.

Est-ce plus clair ? J'espère que j'suis pas à côté de la plaque pour ta question et que je n'ai pas écrit tout ça pour rien .

[Kropernic]

J'ai oublié de préciser.

J'aurais pu n'avoir qu'un objet BLL.Promo vu que c'est l'objet de base qui contient tout le reste. Mais lors de la création du contenu d'une promo par exemple, j'ai la promo "qui traine" dans un coin car j'ai toujours besoin de pouvoir transmettre son id à la DAL pour la persistance en DB mais je travaille à ce moment avec des objets BLL.DetailsXXX histoire d'avoir des trucs plus léger et auxquelles je peux ajouter des méthodes propres à ce qu'ils doivent faire car même si les traitements et les données semblent identique à 90%, les contraintes ne sont pas les mêmes sur le stock propre que sur le dépôt-vente.

Du coup, je n'ai pas les mêmes vérifications métiers à faire et donc, j'ai besoin de classes différentes dans la BLL pour caser tout ça.

[Pol63]

à vu de nez j'aurais tendance à dire que tu te compliques la vie pour rien

le polymorphisme c'est bien s'il y a des traitements (méthodes), si c'est juste pour du stockage de données avoir 2 classes distinctes sans héritage ne pose aucun soucis
enfin réfléchis y 2 minutes "es-ce que ca m'amène de la simplicité quelque part ?"
alors que tu aurais fait 2 classes différentes, 2 collections différentes et un mix des 2 dans le datagrid tu aurais surement déjà fini ton programme ^^


après il parrait que quand on est scolaire on a tendance à suivre les normes et à chercher à se compliquer la vie
(dto, dal, bll, norme 5nf et autre je ne vois pas ce que ca veut dire (enfin si dal c'est data access layer j'imagine, mais ca ne précise rien de spécial)
je ne dis pas le jargon est inutile, ca peut aider à se comprendre précisément dans certains cas
et les normes de base de données j'ai vite vu que les mcd bien jolis ne suivent pas toujours les contraintes de performances des sgbdr

[Kropernic]

à vu de nez j'aurais tendance à dire que tu te compliques la vie pour rien

le polymorphisme c'est bien s'il y a des traitements (méthodes), si c'est juste pour du stockage de données avoir 2 classes distinctes sans héritage ne pose aucun soucis
enfin réfléchis y 2 minutes "es-ce que ca m'amène de la simplicité quelque part ?"
alors que tu aurais fait 2 classes différentes, 2 collections différentes et un mix des 2 dans le datagrid tu aurais surement déjà fini ton programme ^^

C'est probablement vrai et c'est d'ailleurs ce vers quoi je m'oriente ^^. Je pensais bien faire en évitant la répétition mais dans ce cas-ci, ce n'est p-e pas utile.

après il parrait que quand on est scolaire on a tendance à suivre les normes et à chercher à se compliquer la vie
(dto, dal, bll, norme 5nf et autre je ne vois pas ce que ca veut dire (enfin si dal c'est data access layer j'imagine, mais ca ne précise rien de spécial)
je ne dis pas le jargon est inutile, ca peut aider à se comprendre précisément dans certains cas
et les normes de base de données j'ai vite vu que les mcd bien jolis ne suivent pas toujours les contraintes de performances des sgbdr

La par contre, je ne suis pas du tout d'accord. Surtout concernant la base de données. On va s'égarer du sujet mais tant pis, c'est trop intéressant comme débat.

Pour dto, dal et bll, je veux bien, j'aurais probablement du préciser mais vu ton niveau, j'ai présupposé que tu savais de quoi je parlais vu que c'est même hyper standard/courant. Mais voici la traduction d'un article sur les DTO qui m'a servi de modèle pour construire mon archi standard pour les dév que je dois faire en interne ici. Après, on aurait probablement pu faire autrement mais j'suis assez à l'aise avec celle-là donc je l'utilise. Comme déjà dit, je n'ai jamais eu de cours de POO ou d'architecture donc je fais avec ce que je connais.

Pareil pour 5 NF. T'es quand même pas le premier débutant venu. Quand je parle de DB et de 5NF, j'imagine t'as assez d'expérience pour savoir que 5NF signifie 5 forme normale (NF = normal form en anglais). A moins que tu ne fasses vraiment que de la programmation et que tu ne mettes jamais les pieds dans une DB mais je ne crois pas ^^.

Un MCD n'est pas fait pour être joli. Il est fait pour refléter conceptuellement (ça tombe bien, c'est son nom^^) la réalité de ce que le client veut faire. Si le MCD est normalisé (car en fait, si j'dis pas de connerie, ce n'est pas la DB qui est normalisée mais c'est le MCD), les performances seront dans 99% des cas (je reste prudent) au rendez-vous. A condition bien sûr de s'en donner les moyens. C'est sûr que si, d'un point de vue hardware, la machine hébergeant la DB ne peut supporter la charge demandée, les perfs vont être désastreuses. Il en va de même dans le choix du sgdbr. Pour la DB de mon site perso qui va recevoir la visite de 3 tondus et 2 pelés par mois et qui ne servira qu'au login histoire que le site puisse afficher "Bonjour XX", un mysql suffit amplement. Pour une DB qui d'un soft qui devra gérer le planning du personnel de plusieurs magasins, les heures d'ouvertures, s'assurer que le personnel n'est pas planifier en dehors des tranches horaires permises qui sont elles-mêmes définie par chaque magasin et si ce soft est utilisé par plusieurs dizaines de personnes en même temps, je ne suis pas certain qu'un mysql suffisent.

On a chez nous une application web outsourcée qui a été développée en php avec mysql comme DB. Il y a quelque chose commme max 10 utilisateurs simultanés et les perfs sont catastrophiques ! Le dev peut être en cause bien sûr mais je suis persuadé que la DB (à laquelle j'ai accès dont je connais sa structure) est une infamie en terme de normalisation et je suis intimement convaincu que c'est une grosse partie du problème.

[Pol63]

il y a des tas de normes de développement, à utiliser selon ce qu'on fait
mais il y a surtout la logique et la connaissance des outils

personnellement je préfère ne pas taper de code
parce que ton dto si ca te fais taper du code il y a mieux je pense, parce les exemples ont l'air d'avoir une liste de propriétés reflétant la table, du code de lecture qui remplit les propriétés, du code de création avec plein de DbParameters à setter ...
au final tout ceci c'est toujours la même chose
parce que moi taper 2x des tests de validation d'une fenetre, 2x une requete d'insert, alors que ce sont juste des noms et des types de propriétés qui changes je ne trouve pas ca optimal, ca peut être automatisé

je préfère un générateur de code qui va me créer les propriétés à partir d'une table
et du code générique qui sait traiter n'importe quelle requete et n'importe quel objet sans avoir à le connaitre

par exemple j'ai déjà fait un code où on lui donne un list(of tel objet) et une requete et c'est tout, le truc il remplit tout, et de manière aussi performante que si on avait tapé du code (voir plus pour ceux qui n'ont pas vu la différence en datareader.item et datareaer.readvalues)
et au boulot on a même une autre méthode, on ne tape pas beaucoup de code, surtout des requetes select, tout le reste est généré par le code (interface, insert/update/delete ...)
on a rarement des classes de stockage de données même

après il y a des choses comme EF qui font tout ca, mais je prefère connaitre comment un outil fonctionne en interne pour l'utiliser, et EF vu que ca doit répondre à toutes les problématiques c'est assez ouvert et ca doit prendre du temps à maitriser (sur un petit projet c'est doit être royal par contre)

pour les mcd je n'ai qu'un bts et on était pas arrivé à la 5 et 6ème forme je crois
mais bon de ce que j'en avais vu c'était surtout de la logique, et là aussi quand on connait comment fonctionne sql server et ce qu'il préfère on arrive à faire des choses performantes de manière naturelle

on peut aussi voir que développeur peut être un art, il faut bien sur avoir des connaissances et continuer d'en apprendre sans cesse, mais ne pas forcément suivre des choses
après tout c'est de la création

[Kropernic]

Les outils de génération comme EF, je suis assez réticent personnellement. Je ne l'ai jamais utilisé mais j'ai beaucoup lu.
Comme tu le dis, ça doit répondre à tellement de chose qu'à mon avis, c'est devenu un outil générique et du coup, ça répond mal à certaines problématiques qui auraient besoin d'un outil plus spécialisé.

C'est p-e aussi dû à mon domaine de travailler (l'informatique de gestion) mais le développement où la DB est créée en fonction du code, ça me hérisse les poils du corps. Mais pour ça, il y a l'approche DB First qui est apparue (par opposition à l'approche Code First). Cependant, j'ai aussi lu qu'il y a des cas où les requêtes générées par EF sont loin d'être optimales. Du coup, je crée toutes mes procédures stockées moi-même et je m'assure que tous les indexes nécessaires sont bien présent dans la DB.

Après, il y a sûrement des outils moins gargantuesques qui sont plus spécialisés pour l'informatique de gestion qui conviendraient probablement. Mais je n'ai de toute façon pas le temps pour le moment de les chercher et encore moins de les tester. Et même si c'était le cas, il faudrait encore arriver à débloquer le budget pour pouvoir les utiliser.

Conclusion, je code tout moi-même (en m'appuyant sur des choses les bases solides du framework .NET, je ne recode bien sûr pas tout ADO.NET à chaque fois ), j'ai une parfaite connaissances des allers-retours avec la DB et de l'archi de l'application. S'il y a un truc qui cloche quelque part, cela me permet de très vites pouvoir pointer le problème du doigts au prix de quelques instants de réflexion.

Sinon, je suis d'accord avec toi développer c'est un art (tout comme administrer une DB). Il y a des lignes directrices mais après, c'est de l'artisanat. Mais même en artisanat, il y a quand même des règles de bases à respecter sans quoi ce qui est fabriqué (peu importe le domaine) ne sera pas de bonne qualité (à moins de parvenir à découvrir une nouvelle manière de faire totalement révolutionnaire et de viser le prix nobel mais ce n'est pas mon cas ^^).