Discussion :

[neo.51]

Bonjour,

Voilà, maintenant que j'appréhende assez bien les possibilitées du framework .NET 2.0. Je développe des applis qui sont à 80% des applis dites de gestion et je souhaiterais concevoir mes projets de la manière suivante :

-Une couche d'accés aux données générée avec un générateur de code.
-Une couche métier que je code en fonction des spécifs.
-Une couche présentation en utilisant au maximum le databinding (avec mes objets en datasource).

Je n'ai pas besoin d'une forte indépendance des couches mais la séparation en 3 couches me permettra de mieux maintenir mon code et de réutiliser mes couches data/métier dans un autre projet.

Le problème que je rencontre actuellement, c'est que tous les générateurs de code que j'ai trouvé gènèrent un code mal adapté aux nouveautées de .NET 2.0 à savoir :
-Les générics.
-La possibilitée d'avoir des objets comme source de donnés.

Sur ce deuxième point, un problème récurent est qu'on ne peut pas ni filtrer ni trier des bindingSources ayant un objet comme source de données. Que ce soit un généric ou une liste typé faite par un générateur on se retrouve avec une BindingSource "bridé" ce qui est assez pénalisant quand on veut un interface un minimum riche (pouvoir trier par colonne et faire des filtres c'est quand même les bases).

Alors biensur rien ne m'oblige à utiliser une BindingSource ... certe, mais il faut quand même avouer que la conception d'interfaces graphiques et le code que ça engendre derrière pour faire quelques vues maitre/détail avec 2-3 liaisons est bien plus rapide et éfficace avec une bonne BindingSource.

Le temps de développement de la partie UI est forcément allongé si on utilise pas le DataBinding à fond, plus les risques d'érreurs de code (forcément plus on code plus on a de chance de faire des érreurs).

La modèle DataSet/DataAdapter me plait de moins en moins, trés rigide, trés opaque, qui peu le plus peut le moins mais le dataset me semble souvent être une grosse uzine à gaz dont je n'utilise que 10% des méthodes . En plus j'ai souvent plus de 50 Tables en base de donnée, imaginnez un dataset de 50 Tables !!! ingérable ...

En gros j'ai l'impression d'avoir le choix :
-Soit une DAL "propre" que je génère avec un générateur de code mais derrière une compléxité supplémentaire pour coder la partie UI.
-Soit une DAL basée sur des Dataset avec difficultée de séparer la couche métier/data mais une UI plus facile à concevoir.

Et vous comment faites vous ? Quels outils utilisez vous ?

[neguib]

...Le problème que je rencontre actuellement, c'est que tous les générateurs de code que j'ai trouvé gènèrent un code mal adapté aux nouveautées de .NET 2.0 à savoir :
-Les générics.
-La possibilitée d'avoir des objets comme source de donnés.

Sur ce deuxième point, un problème récurent est qu'on ne peut pas ni filtrer ni trier des bindingSources ayant un objet comme source de données. Que ce soit un généric ou une liste typé faite par un générateur on se retrouve avec une BindingSource "bridé" ce qui est assez pénalisant quand on veut un interface un minimum riche (pouvoir trier par colonne et faire des filtres c'est quand même les bases).

Disons que çà necessite une étape supplémentaire pour effectuer la transformation en un BindingList qui lui gèrera le tri et la recherche

[neo.51]

Par défaut une bindingList ne peut pas être triée et encore moins filtrée.

Pour le tri y a moyen de l'implémenter, le Search aussi, mais le filtrage ...

Enfin je voulais aussi élargir le débat sur votre manière de procéder

[joujou_le_fou]

Je me suis retrouvé confronté au même problème.

La "solution" que j'ai trouvée consistait à passer par des SQLDataSource. C'est ces objets qui étaient chargés d'appeler les procédures stockées.
Du coup, le modèle 3 tiers que j'avais mis en place a été cassé.
Mais j'ai pas très bien saisi le fonctionnement de ces types d'objets, alors si qqun a des infos, je suis à l'écoute, comme Neo51!!

[FRED.G]

J'ai découvert le développement en couches il y a à peine un mois (à l'origine je viens d'Access) et depuis deux semaines j'étudie la question du mapping Objet Relationnel.

Mes recherches (pour l'instant) m'ont amené à tester la solution originale proposée par Mistu Furuta de chez MS.


L'idée est de stocker les données persistentes dans un Dataset.

L'alimentation et la sauvegarde des données du Dataset (la partie SQL) est isolée dans une couche dédiée.

De l'autre côté, on a une couche d'objets métiers qui vont offrir des "Vues" des données du Dataset.
Une "vue", c'est à dire que les données ne sont pas stockées dans les objets. Les propriétés persistentes de l'objet pointent directement sur les données du Dataset (DataTable / DataRow).

Côté IU c'est sur ces objets métier qu'on va se binder.


Pour profiter de tous les avantages du BindingSource, il faut que les Objets métier implémentent les bonnes interfaces.

Concrêtement on a les Classes de collection d'objet qui vont implémenter IBindingList, IBindingListView, etc., afin de profiter de toutes les fonctionnalités de filtrage et tri avancées.

Et les classes d'objet "simple", qui vont éventuellement implémenter IEditableObject, afin de gérer le versionning, etc.

Comment implémenter ces interfaces ? Rien de plus simple :

- pour les classes de collection, on stocke un Dataview en tant que donnée membre Private et on fait un simple "chainage" des propriétés et méthodes du Dataview qui correspondent aux propriétés et méthodes des interfaces.

- pour les autre objets, on fait la même chose, mais avec un DataRowView au lieu du DataView. Et on fait également un chaînage des propriétés persistantes...
En fait, le DatarowView est une vue du DataRow (qui est le seul à contenir les données), tout comme les DataView sont des vues des DataTable. notre objet métier ici est lui-même une "vue" du DatarowView, mais une vue que l'on peut modeler soi-même : par exemple on peut masquer des colonnes, en mettre en ReadOnly, etc.


Exemple d'implémentation d'interface par "chainage" pour un objet collection :

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 Clients
 
        Implements System.Collections.IEnumerable
        Implements System.Collections.ICollection
        Implements System.Collections.IList
        Implements System.ComponentModel.IBindingList
        Implements System.ComponentModel.IBindingListView
 
        Private WithEvents m_DataView As DataView
 
        Public Overloads Sub ApplySort(ByVal sorts As System.ComponentModel.ListSortDescriptionCollection) Implements System.ComponentModel.IBindingListView.ApplySort
            DirectCast(Me.m_DataView, System.ComponentModel.IBindingListView).ApplySort(sorts)
        End Sub
 
        Public Property Filter() As String Implements System.ComponentModel.IBindingListView.Filter
            Get
                Return DirectCast(Me.m_DataView, System.ComponentModel.IBindingListView).Filter
            End Get
            Set(ByVal value As String)
                DirectCast(Me.m_DataView, System.ComponentModel.IBindingListView).Filter = value
            End Set
        End Property
 
        Public Sub RemoveFilter() Implements System.ComponentModel.IBindingListView.RemoveFilter
            DirectCast(Me.m_DataView, System.ComponentModel.IBindingListView).RemoveFilter()
        End Sub
 
Etc.
 
End Class

Bien entendu il ne s'agit pas de faire un chaînage 100 % identique dans nos objets collection, sinon ils ne seraient rien d'autre que des DataView ...
En fait, il ne faut pas oublier de renvoyer notre objet métier au lieu de renvoyer un simple DataRowView dans :

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
   Public Class Clients
 
Private WithEvents m_DataView As DataView
...
 
        Default Public Property Item(ByVal index As Integer) As Object Implements System.Collections.IList.Item
            Get
                    Return New Client(m_DataView.Item(index ))
            End Get
            Set(ByVal value As Object)
                   ...
            End Set
        End Property
 
...

Cette solution m'a séduit et j'essaye donc de la mettre en place dans mon application.

Vous aurez plus d'infos ici : http://www.microsoft.com/france/even...ntID=118769669

[zeavan]

perso j'utilise enterprise library 2.0 de microsoft+ datawindow 2.0 de sysbase et je creer mon prore model data.

l'association des 2 me satisfait assez pour m'aider a differencier les differentes couches.

sinon il y a codesmith avec netears qui supporte les generics mais je crois que c'est encore en beta.

[B.AF]

Et bien j'espére que ca ne sera pas perçu comme de la pub, mais la solution de ta question est exactement ce que je gére les composants data enterprise de component one.

A savoir :
Un dataref local client pouvant pointer sur un composant tier d'accès aux données, qui lui même peut être lié à des classes métier.

Ca ne fait pas tout, c'est très propriétaire, mais j'ai envie de dire aussi que tous les composants se dérivent.

Je suis assez sidéré aujourd'hui de voir que beaucoup de développeurs prennent les composants "as it", en drag and drop, alors que la régle d'or d'un composant quel qu'il soit, et que l'évolutivité et la maintenance souhaiterai que tous prennent le simple temps de créer un nouveau composant dérivé.

Et là tu gagneras du temps.

[FRED.G]

Je ne vois pas là de la pub mal placée, c'est toujours intéressant d'avoir un retour utilisateur sur une techno donnée, propriétaire ou non.

Tu peux même écrire un article sur les composants data enterprise, nous aurons la possibilité de le publier s'il est bien fait.

Sinon pour ma part, je préfère viser des outils libres ou MS, c'est pourquoi j'étudie l'Entity Framework en ce moment.

[Exsilius]

Bonjour,

Rentré de vacances depuis peu , je viens de prendre un peu de temps pour continuer à explorer les mystères de l'architecture 3 tier en DotNet et du mapping objet/relationnel. Fred.g, Tes réponses m'ont eclairé, et je viens de lire quelques articles concernant ObjectSpaces de Microsoft (notamment ici).

L'avez vous utilisé ? Quel sont vos retours ?

Chaleureusement.

[Exsilius]

Je viens de voir que Microsoft ne donne pas suite à ObjectSpaces et que son successeur s'appellera DLinq ou (Linq ?...)(que ferait-on sans dvp ?) et qu'il est prévu avec la version 3.0 de C# (lien msdn)...

Ca me parait un peu la jungle au niveau des 'ORM' DotNet...
Je reviens donc à une des problèmatiques posé par neo.51 au début du thread :

Et vous comment faites vous ? Quels outils utilisez vous ?

[aserf]

Bonjour,
perso j'ai developper mon propre générateur de code, sa me permet a souhait de rajouter tout ce que je veux, si il y en as que sa interesse www.database2code.com. il comporte probablement des inconvenient par rapport a des outils pro, mais a surtout pas mal d'avantage (comme la mise a jour de structure de base de donnée, et un vrai mapping, ce qui permet de passer d'une base Access, SQL Server ou MySql en qq seconde).

Autrement je vais regarder un peu tout les outils que vous avez cité ici, je pense que je peu m'inspirer de certaine de ces fonctionnalitées.

merci,

[Jfrancois57]

Est t il possible de générer une partie du code à partir de diagramme UML avec un logiciel ? si oui lequel ?

[SaumonAgile]

J'évalue SubSonic à titre professionnel depuis plusieurs jours et je dois avouer que je suis impressé du travail réalisé. C'est gratuit et open source, et normalement ce sera bientôt supporté par Microsoft (le développeur principal vient d'y être embauché pour continuer à travailler dessus).
Au niveau des fonctionnalités, on a un O/RM puissant, avec une (très) bonne gestion des transactions, une gestion des relations Many-to-Many.
La prise en main est très intuitive, le site est plein de webcasts clairs.
On a en plus un outil de génération de code.

Un excellent produit, pour les petites applications comme pour les plus grosses :
- pour les petites, la DAL est générée sans écrire une ligne de code,
- pour les grandes, le framework de mapping est assez puissant pour supporter la charge et même la diminuer par rapport à d'autres outils d'O/RM (possibilité de ne pas remonter toutes les colonnes dans une requête, etc).

[le-maraudeur]

Bonjour,

j'ai lu attentivement ce sujet très intéressant.

J'ai une question connexe au sujet, pour laquelle je ne parviens pas à trouver de réponse :

J'utilise un framework "maison" qui pour le moment ne fait qu'hériter des collections génériques.

Mon problème se situe au niveau de l'utilisation de mes objets "collections" (de type System.Collection.Generics.List(Of T)) en tant que Datasource (fonctionne bien), lorsque les objets de type T composants ma collection ont des "PropertyObject".

Dans ce cas de figure, il m'est impossible d'afficher la moindre propriété du sous-objet dans le datagrid. J'ai beau essayer tout ce que je trouve comme idée ou tuto, et rien n'y fait. J'ai toujours une colonne affichant le type du PropertyObject.

Pour le moment, la seule solution que j'ai mis en oeuvre a été de rendre visible la propriété du sous-objet que je veux voir affichée dans mon datagrid dans l'objet père le contenant. Autant dire, une solution peu élégante, bien que simple, et qui de plus nécessite une modification manuelle de mon framework qui est généré automatiquement à l'aide d'un générateur.

[B.AF]

Généré le code d'une application depuis une base de donnée, c'est un doux rêve.

C'est terrifiant de croire qu'un outil peut combler le manque entre le monde relationnel et le monde objet.

M'enfin, si cela permet de vendre...

Voilà néanmoins les résultats de mon équipe r&d (en synthése) :

Nhibernate :
22 développeurs commiteurs, excellent support du groupe, documentation exhaustive, conforme en 2.0 à la version 3.2 java;
Excellente performance; vrai mapping; entiérement contrôlable
Peut réellement travailler en objet
Moteur de requête intelligent, hsql très souple
Gestion des sessions et du cache entiérement gérable
CL : Excellente technicité, suffisamment ouvert pour maitriser la persistence, excellence des développeurs, expérience de la communauté JAVA en fond.

LLBL
Excellent leader (F.BOUMA), support bon dans l'ensemble
Pas de POCO.
Génération de code propriétaire et obscur
Travail uniquement en relationnel
Serialization propriétaire en boite noire
Moteur de requête intégré très complexe et quasi inutilisable
CL : Très bon outil, trop propriétaire, peu ouvert, Leader très peu à l'écoute des remarques des users, trop orienté reverse engineering de DB.

EUSS:
Seul outil offrant un persistence multi support intelligente
POCO
Fonctionnalités très poussées
Langage de requête XPath Like
CL : Mis en en monitoring, probablement un futur grand; risque de ne pas être adopté cependant (communauté et support faibles). Mais excellente technicité.

EF :
Immature, 3 fichiers difficiles à manipuler pour un mapping; stratégie de chargement trop propriétaire,; n'est pas objet mais relationnel.
Pas de POCO
Uniquement SQL Serveur
CL : Non concluant, outil immature à retester

Linq To SQL
Hors scope; "jouet".

IdeaBlade:
En aveugle; très marketté, code sale, peu de pré occupation de la couche business. Très cher, risque opérationnel élevé. Produit purement commercial.
CL : Abandon

NetTiers :
Outil de génération, à paramétrer, pas réellement intéressant (aucune logique de persistance reélle, que du code généré en templates)
CL : Abandon

SubSonic :
Outil de génération et d'encapsulation, fonctionnalités ORM limitées,
Pas de POCO
Orienté Web
CL : Abandon

[alainam]

Bonjour,

Je me suis mis à Visual Studio 2005 depuis cet été et je dois dire que je souffre beaucoup. Je viens du monde VB6 & SQL Server (Ado Oledb), et je n'y connaissais rien en programmation Objet et encore moins en développement WEB.
Je suis un informaticien indépendant (senior et dépassé), et j'ai eu beaucoup de mal à appréhender ce monde là : on ne parle pas le même langage. Je me suis auto formé et j'ai suivi une formation qui m'a quasiment coûté le tiers de mon dernier contrat.
Mon premier soucis avant d'attaquer le développement d'une application Web que j’ai vendue a été de reconstruire un atelier de génie logiciel qui me permette de retrouver un environnement familier, que je maîtrise et qui autorise des développements stables, fiables, et duplicables.
Dans un logiciel de gestion qu'il soit Web ou non, la base de données est la partie la plus importante. Comme mes progiciels VB6, sont hyper stables et suffisamment puissants pour ma clientèle, je n'ai pas voulu la reconcevoir.
Le challenge que je me suis fixé c'est que mes bases de données, puissent être attaquées par mes anciens progiciels VB6 et les applications Web Visual Studio 2005 que je dois écrire.
Ainsi je peux proposer un environnement mixte à mes clients Réseau et/ou Web.
Quand je me suis attaqué au problème, j'ai vite vu qu'il fallait adopter une architecture 3tiers et le DataBinding. Quand j'ai commencé à concevoir la couche métier, je me suis aperçu que la charge de travail était trop importante (plus de 300 tables, et dont certaines sont dodues).
Je me suis mis à la recherche de générateurs (codesmith et autres) mais soit je n'y comprenais rien, soit le résultat était décevant.
En désespoir de cause (comme à l’ancienne) , je me suis mis à écrire un générateur de couche métier adapté à mes besoins.
Auparavant, suite à ma formation ASP Net, j'ai conçu un modèle avec quelques tables pour vérifier le fonctionnement de la couche métier avec le Databinding.
Ensuite j'ai utilisé VB.net (WinForm) pour développer la moulinette (ou le générateur si vous préférez).
Cela m’a pris plus d’un mois de travail (j’en ai profité aussi pour me former à VB.Net que je ne connaissais pas)
Que fait la moulinette :
1) Elle se connecte sur SQL 2000
2) On choisit une base de données
3) On choisit les tables ou les vues
4) On génère au choix :
a) les entités
b) la couche standard d'accés aux données (procédures standard CRUD avec ou sans transaction. Ce sont des classes partielles non modifiables par le programmeur) cette couche est en principe écrasée à chaque génération
c) la couche spécifique d'accès aux données (classes partielles modifiables par le développeur) cette couche n'est pas en principe écrasée à chaque génération
d) les procédures stockées à inclure dans SQL Server


Cette moulinette m'a permis de générer quelques 200.000 lignes de code propre et stable. Elle ne gère pas tous les questions, mais elle permet le DataBinding des GridView avec des collections (List of entites), le DataBinding des formview ou detailview avec des entités. Le problème du tri dans les gridview est résolu avec le SortExpression : on n’a pas besoin de passer par un DataSet.
Pour les jointures et les transactions il faut écrire un peu de code dans les procédures d'accès au données spécifiques (celles qui ne sont pas écrasées par une nouvelle génération).
L’intérêt de tout ceci est que la couche interface Utilisateur est indépendante de la couche métier, et je peux dire que lorsqu’on a fait cet énorme effort, c’est quand même beaucoup mieux.
PS: Pendant ces moments là on se sent un peu seul (techniquement parlant). aussi je suis prêt à partager cette technique, en échange d'indulgence sur le jugement de mon code et pourquoi pas le faire évoluer ensemble

[Exsilius]

Effectivement, bel effort ... mais qui me parait légérement effrayant au vu de mes délais (surtout que je travaille en TimeBoxing...).

Peut-tu détailler quels mapper objet/relationnel tu as utilisé, et sur quels points il t'ont déçu ?

[alainam]

Si la question m'est adressée, je suis désolé, mais je ne la comprend pas...

Peut-tu détailler quels mapper objet/relationnel tu as utilisé, et sur quels points il t'ont déçu ?

[Exsilius]

Je veux effectivement parler de ce que tu appelles les 'générateurs'. Il semble que ce soit bien des outils de mapping (transformation) de tes entités (modèle relationnel) en classe (modèle objet).

Me trompe-je ?

[alainam]

Je vais essayer d'être clair.
Le lien MoulinetteSurBaseSQLServer.doc explique le fonctionnement général.

Le lien amw_Cad_TabTiNiveauTiers_Crud_ProcedureStockee.sql montre les procédures stockées gnérées qui seront incluses automatiquement dans SQL Server. La Couche d'accés aux donnnées s'en servira

Le lien TabTiNiveauTiers.vb montre la classe Entite générée

Le lien TabTiNiveauTiersCADCrud.vb montre la classe partielle (partie standard) d'accès aux données. En principe le programmeur n'a pas à modifier le code généré

Le lien TabTiNiveauTiersCADSpecif.vb montre la classe partielle (partie spécifique) d'accès aux données. Le programmeur y écrit les procédures d'accés aux données spécifiques. Par défaut la génération ne l'écrase pas.