objets métiers -> base de données - SQL/NoSQL - Programmation
Marsh Posté le 05-07-2007 à 11:32:54
L'objet qui me permet de faire le lien entre l'interface graphique et les objets métiers par exemple.
Marsh Posté le 05-07-2007 à 19:29:19
Il existe effectivement plusieurs méthodes.
1/ tu te trimbales l'ensemble du code nécessaire aux accès dans la base de données dans tes objets métiers.
Avantages : Les objets métiers sont autonomes, et tu n'as pas à te soucier de la présence d'élément extérieur.
Inconvénients : Si la structure de la base de données change, ou si la méthode d'accès à cette dernière change, ou si tu veux mettre en place des solutions de cache évoluées, ou autres, tu vas être obligé de modifier énormément de code redondant, voir te heurter à des problèmes quasi insollubles
2/ Utiliser un objet d'accès à la base de données très basique (pour ainsi dire, une simple surcharge des méthodes des objets de Base du Framework), et les appeler depuis tes objets métiers.
Avantages : Moins de redondance que dans le premier cas, et maintenabilité accrue
Inconvénients : Les objets métiers font toujours des appels à des méthodes assez bas niveau, ce qui peut compromettre en partie l'évolutivité (si demain tu changes d'un système de SGBD pour une solution basée sur des fichiers plats, tes objets métier sont tout aussi impactés que dans le premier cas)
3/ Déporter complètement la couche "accès aux données" vers l'objet de base de données. Ainsi, l'objet de base de données contient non seulement la connection à la base, mais toutes les méthodes métiers permettant l'accès à la base.
Avantages : Abstraction totale de la couche des données. Ainsi la maintenance et l'évolutivité sont très aisées
Inconvénients : Déport de méthodes métier au sein d'un objet "générique". Ainsi, l'étude de l'objet métier seul est insuffisant pour connaître tous les tenants du fonctionnement de ce dernier.
4/ Incorporer les deux couches ensemble, grace à l'héritage. l'objet métier dispose des méthodes de base d'accès à la couche des données, tandis que l'objet métier en hérite afin de faire lui-même les traîtements dans la base, sans se soucier de la façon qu'il les fait
Avantages : à priori, tous les avantages des 3 solutions précédentes
Inconvéniets : à priori, aucun des inconvénients cités ci-dessus
Personnellement, j'utilise actuellement le système "3". Il est aisé à mettre en place, et facilement maintenable lorsque les objets métiers restent simples et peu nombreux.
Je viens d'imaginer le cas "4", qui me semble en tout points suppérieur. Mais vu que je viens de l'imaginer, je peux pas te garantir qu'il marche
Marsh Posté le 05-07-2007 à 20:58:32
Je viens de tester en vitesse une implémentation pourrave du 4.
Spa trop pourri, faut juste pas avoir l'esprit tordu comme moi
La base de test
Code :
|
Le code C#
Code :
|
Sortie :
|
Edit : Plus je me relis, et plus je me dis que c'est total n'imp' mon objet "Produit" M'enfin t'as le principe, et il marche
On voit notamment très bien dans cet exemple que :
- DataBase ne sais absolument pas ce qu'il fait. Il est complètement générique, et ne contient aucune information relative aux métiers
- On voit aussi que l'objet métier ne sait pas non plus d'où viennent les données et ce qu'on en fait
=> En quelques heures, je peux altérer mon objet "DataBase" pour passer à une base Oracle par exemple, ou même la gestion d'information à partir de fichiers XML
Marsh Posté le 06-07-2007 à 08:26:45
Merci beaucoup MagicBuzz, c'est exactement ce genre de réponse que j'attendais. Bravo pour la précision de tes explications et pour ton code qui m'a aidé à refaire mon programme proprement et plus efficacement.
Marsh Posté le 05-07-2007 à 10:27:23
Bonjour,
je souhaite faire un petit programme de gestion orienté objet avec utilisation d'une base de données pour sauvegarder les données. Je n'utilise pas d'outils de mapping objet/relationnel.
J'ai défini les objets métiers. Je souhaite savoir s'il doivent disposer eux-mêmes de méthodes pour l'insertion ou la séléction dans la base de données ou si je dois faire intervenir un élement extérieur.
Evidement les deux approches sont possibles mais je voudrais vos avis sur la pertinence des deux stratégies.
Merci.