Discussion :

[italiasky]

Bonjour,

Mon post parle plus de bonnes pratiques de développement que du langage C#.

Lors d'un tuto de MSDN (les "coachs" très exactement), j'ai abordé la sérialisation.. Ca a l'air vraiment puissant mais j'ai quelques questions afin de délimiter ce qu'est ou n'est pas la sérialisation...

Tout d'abord, est-ce que la sérialisation est juste à associer avec XML ?
Par là, je viens au fait que XML n'est finalement qu'un moyen pour stocker de l'information de façon permanente après la fermeture du logiciel et que donc est-ce que les BDD peuvent jouer le même rôle pour sérialiser ?

En fait, ce que je me demande, c'est, par exemple, si on veut faire un logiciel qui gère des clients et l'on souhaite avoir une BDD pour stocker les informations sur le long terme.

Quelle est la méthode de programmation à utiliser ?
Est-ce qu'on doit avoir une classe Client avec des données membres pour toutes les informations qu'est censé avoir un Client dans notre application.
Et qui reprendrait donc les champs de la table Client qui est dans la BDD ?

Et lorsqu'on travaille sur un client, on rapatrie toutes ses informations dans une nouvelle instance de la classe Client. Et à la fin, on remets les informations dans la base ?

Ou on travaille directement dans la base de données à faire des requêtes ?

Est-ce que la première option serait de la sérialisation à proprement dit ou pas ?
Est-ce que c'est de cette façon qu'on "doit" programmer ?
Est-ce qu'il y a des mécanismes prévus justement pour lier tout ça dans C# ? Databinding ?

Merci
Bonne soirée

[Skyounet]

Tout d'abord, est-ce que la sérialisation est juste à associer avec XML ?
Par là, je viens au fait que XML n'est finalement qu'un moyen pour stocker de l'information de façon permanente après la fermeture du logiciel et que donc est-ce que les BDD peuvent jouer le même rôle pour sérialiser ?

Non, il existe plusieurs type de sérialisation : XML, Json, Binaire, SOAP (basée sur XML même si c'est plus un protocole qu'une sérialisation) etc ...

Quelle est la méthode de programmation à utiliser ?
Est-ce qu'on doit avoir une classe Client avec des données membres pour toutes les informations qu'est censé avoir un Client dans notre application.
Et qui reprendrait donc les champs de la table Client qui est dans la BDD ?

Et lorsqu'on travaille sur un client, on rapatrie toutes ses informations dans une nouvelle instance de la classe Client. Et à la fin, on remets les informations dans la base ?

Félicitations tu viens de trouver la "bonne" méthode

Tu peux soit passer par des ORM tel que Nhibernate ou Linq To Entities (oui on peut ne pas le considérer comme un ORM je sais).

Ce type de framework, réalise un mapping entre tes tables SQL et tes classes C#.

En gros à chaque table SQL correspondra des classes C#.
Lorsque tu modifies une propriétés de ton objet C# et que tu valides ce changement, il est reflété dans la BDD. Tu n'as pas besoin de taper de SQL, tout est transparent (mais tu peux le faire si tu le souhaites).

Sinon, tu peux réaliser ton propre Layer d'accès aux données.
Tu crées tes classes C# basé sur tes tables.

Tu crées une méthode GetClients qui interroge ta BDD et qui transforme le résultat en une liste de classe C# Client. Ici tu va devoir taper du SQL ou appeler des procédures stockés.

Ensuite il faut également prendre en charge l'update, l'insert et le delete

Ou on travaille directement dans la base de données à faire des requêtes ?

C'est ce que tu fais en créant ton propre Data Access (expliqué juste au dessus).
Personnellement je préfère de loin les ORM à requêter ma base directement, mais il faut aussi prendre en compte les performances.
Linq To Entities par exemple est très peu performant par rapport à du requêtage simple basé sur des procédures stockées par exemple.

Est-ce que la première option serait de la sérialisation à proprement dit ou pas ?

Non.

Est-ce que c'est de cette façon qu'on "doit" programmer ?

Utiliser des ORM ou ton propre mécanisme oui (en même temps y'a pas 50 approches possibles ).

Est-ce qu'il y a des mécanismes prévus justement pour lier tout ça dans C# ? Databinding ?

Avec WPF et Silverlight oui.
WPF/Silverlight + Linq To Entites c'est vraiment génial.
Tu bind tes entités sur tes formulaires et quand tu modifies un champs via l'interface et que tu valides ça update ta BDD.

Sinon pour en revenir à la serialisation, il ne faut pas voir ça comme un moyen de stocker de l'information. Tu l'as vu toi même, les BDD sont là pour ça.

Tu peux voir la sérialisation comme un moyen de stockage temporaire (mode déconnecté ou système de cache par exemple) ou comme un moyen de transport.

Je veux envoyer un objet d'une application A à une application B, je vais le sérialiser, l'envoyer et l'application B va le récupérer et le reconstruire.

C'est le principe des WebServices et du Remoting par exemple.

[italiasky]

Merci de votre réponse.

Je viens juste de finir de lire l'article "Introduction au développement en couches" de Thomas Lebrun et si j'ai bien compris, ca reprend ce qu'on est entrain de dire non ?

A savoir :
- L'interface utilisateur
- La couche d’accès aux données (DAL, Data Access Layer) => qui peut soit être développée à la main, soit être un framework type Nhibernate, Linq To Entities
- La couche métier (BLL, Business Logic Layer)

Et les objets métier (Business Objects), ce sont alors les classes qui "reflètent" les tables ?

Par contre, j'ai forcément une question qui me vient à l'esprit, si on copie nos tables dans des objets, est-ce que au niveau performance, ca suit toujours ?
Par exemple, si on a une listview qui liste tous les clients, si il y a 1000 clients, on aura 1000 objets Client créés dans lesquels les données de la table ont été rapatriées.
De plus, si chaque client, a une dizaine de facture, et qu'on rapatrie aussi les données de chaque facture dans des objets de type Facture, dont chaque Client a donc une liste de Facture.
Etc, on peut en rajouter des informations liées au client...

Ca peut vite commencer à chiffrer non ? Est-ce toujours viable ?

Est-ce que dès que l'on modifie une donnée, il faut l'updater tout de suite dans la base ou on écrit toutes les données d'un coup à la fermeture, même celles qui n'ont pas changées du coup.

Merci
Bonne soirée

[Skyounet]

Merci de votre réponse.

Je viens juste de finir de lire l'article "Introduction au développement en couches" de Thomas Lebrun et si j'ai bien compris, ca reprend ce qu'on est entrain de dire non ?

Et les objets métier (Business Objects), ce sont alors les classes qui "reflètent" les tables ?

C'est exactement ça.

Par contre, j'ai forcément une question qui me vient à l'esprit, [...]
De plus, si chaque client, a une dizaine de facture, et qu'on rapatrie aussi les données de chaque facture dans des objets de type Facture, dont chaque Client a donc une liste de Facture.
Etc, on peut en rajouter des informations liées au client...

C'est là qu'intervient des concepts comme le lazy loading.
Kesako ? http://en.wikipedia.org/wiki/Lazy_loading

En mode lazy load, tu charges seulement tes clients.
Lorsque tu as besoin des ses factures et seulement à ce moment alors tu vas charger les factures de ce client et de lui seulement.

Est-ce que dès que l'on modifie une donnée, il faut l'updater tout de suite dans la base ou on écrit toutes les données d'un coup à la fermeture, même celles qui n'ont pas changées du coup.

Là c'est comme tu veux, ou plutôt comme ton interface est faites.
Si tu as une fenêtre de modification d'un client, l'utilisateur s'attende à ce que dès qu'il clic sur Save les changements soient faits.

N'oublies pas que tu ne sauvegardes que les clients qui ont été modifié.

En fait dans les ORM chaque entité (instance d'une classe) possède un état.
Par exemple : Modified, Added, Deleted

Lorsque tu appelles la méthode Save de ton ORM, il liste tous les objets auquels il est lié et selon son état, il effectue la commande SQL qui va bien : Update pour Modified, Insert pour Added et Delete pour Deleted.

Si l'utilisateur ne modifie qu'un seul client, le Save ne fera qu'une seule requête à ta BDD (un seul Update dans le cas présent).

C'est ici que les performances de Linq To Entities doivent être améliorées. Si tu inserts beaucoup d'éléments ça peche un peu.

[italiasky]

Ok intéressant tout ca, j'ai feuilleté quelques articles et tuto sur le sujet...
Mais j'ai vite perdu la tête en fait... lol

Je ne sais pas si utiliser un ORM pour mon cas est vraiment pertinent parce que d'après les tutos, ca a l'air assez lourd à déployer ces fameux ORM non ?
J'ai regardé NHibernate et ca m'a pas l'air si simple... Et puis vu que je débute en dev .NET, il est surement préférable que je fasse un peu à la main.

Mais donc, la place des ORM, si j'ai bien compris, est-ce qu'ils remplacent bien la couche DAL et créent automatiquement les BO (Business Objets (ou DataObjects ? j'ai trouvé ce terme aussi, est-ce que c'est bien la même chose ?))
Ces fameux BO ne contiennent pas de méthodes ? C'est juste des données ?
Si j'ai bien compris, le traitement sur ces données est fait dans la couche BLL (Business Logic Layer) avec par exemple une classe XManager pour le BO X qui se rapporte également à une table X.. et la boucle est bouclée.. pas vrai ?

Donc si je veux faire à la main, il faut que je développe moi même une classe pour chaque table (les BO) et que j'ai ma couche d'accès aux données (dans mon cas à la DB). C'est cette couche qui fait les opérations de CRUD ?
Mais cette couche, concrètement, elle est organisée comment ? Juste une classe ClientDAO qui fait tout ou une classe pour chaque table ?

Sur un schéma et exemple, ce sera plus concret je pense.

J'ai 2 tables : X et Y

Business Logic Layer (BLL)
XManager : les méthodes qui permettent de manipuler les données de X
YManager

Business Objetcs (BO) (ou DataObjets?)
X : une classe qui contient que des données, provenant de la base de données de la table X
Y

DataAccessLayer (DAL) : c'est ici qu'on fait concrètement les accès à la DB
ClientDAO
ou
XClientDAO, YClientDAO ou quelque chose du genre ?


Je ne vois pas ou placer une méthode Save par exemple, lorsque j'ai créé un nouvel objet X dans mon logiciel et qu'ensuite je veux le sauver dans la base...
Fait-on :
X.Save()
XManager.Save(X)
ou encore en passant par le DAL directement XClientDAO.Save(X) ?


Je me pose toute ces questions car j'aimerais acquérir les bonnes pratiques pour le développement d'applications vu que je débute sous .NET avec un nouveau projet, tant qu'à faire...

Merci beaucoup

Bonne journée

PS :
( J'ai essayé d'utiliser Nhibernate avec SQLite parce que j'aimerais utiliser cette DB pour mon appli et non un SLQ Serveur ou autre plus conséquent, mais j'y suis pas parvenu... :/ la plupart des tutos sur NHibernate sont fait pour SQL Server... )

[bacelar]

Je voudrais signaler le principal écueil, à mon avis, de l'utilisation d'un ORM.
Il faut absolument dissocier le model objet de la couche business, dont l'objectif est de facilité l'implémentations des règles métiers des classes de récupération de la DAL qui est plus proche du modèle de la base de données, conçu pour éviter des redondance, permettre la cohérence référentielle etc..

Il faut donc prendre la peine de faire une conception du schéma de la base et une conception des objets métiers bien distinctes.

L'utilisation d'ORM à tendance à fusionner ces modèles par une simplification trop hâtive qui rend soit une base de données ayant des problèmes de performances et de contraintes référentiels, soit un modèle objet rendant l'implémentation des règles métiers laborieuses et peu maintenables.