Je suis en train de concevoir un programme de vente et je me demande si je doit concevoir en OO ou pas. Je me demande souvant ou est l`avantage en OO dans les applications de base de données. Dans le developpement de jeux, je vois clairement l`avantage mais en DB ??? Pouvez vous me donner les avantages en DB?
Merci!
L’objet à été un flop avec les bases de données. Le modèle le plus appliqué encore en ce moment est merise ou uml.
Sinon quelques utilisations arrivent à percer avec l’objet, les annuaires par exemple ou encore Zope.
Si je comprend bien, les application DB en OO sont très rares. Je sais que Merise est très utilisé pour la conception architecturale des Bases de données. Dans mon cas, j’ai créé ma structure sur papier sans la méthode merise. En ce qui concerne UML, bien je crois que cette méthode n’est pas envisageable dans le cas de développement d’application DB. Je crois que je vais suivre ma premiere idée et de développer par module.
La POO est très répandue pour moi au contraire, bien que les bases de données Objets ne percent pas, on peut très bien créer des Bean donc des objets qui mappent les données de la base.
Quand à UML, c’est aussi objet comme approche (diagramme de classes…) mais rien ne vaut un bon MLD/MPD pour représenter clairement une base de données, et la normaliser (pour optimiser les données ).
Je suis daccord avec toi mais, ce qui me fais hésiter pour le développement OO c`est que j`ai l`impression de refaire ce quyi existe déjà. Ce que je veux dir, c’est qu’un fois mon Objet DataReader initialiser, j’ai toute mes champs et mes données. Donc a quoi ça sert de redefinire un Object Client?
Oui, il ne faut surtout pas redéfinir des objets techniques si on n’en a pas besoin, il y a toutes les chances que les api objet fournie soit mieux faite que celles qu’on développe, quoique certaines entreprises cherchent à encapsuler cette partie technique dans des “frameworks” parfois un peu difficile à mettre au point.
Non, un autre avantage de l’objet c’est de définir des objets dit “métiers” qui répondent à ta problématique, sont plus souple pour s’adapter à des cas différents, et qui représente vraiment les concepts manipulés par ton application, qu’il soient en base, ou en RAM, (par exemple un objet pour définir un utilisateur connecté, avec ses informations connexes, et des méthodes pour le déconnecter auto…)
Après, tu peux aussi très bien définir séparément des objets techniques pour combler des lacunes d’objets déjà utilisé (ajout d’un cache, d’un protocole non implémenté, wrapper…)
les “design pattern” montrent des cas typiques d’utilisation des objets, plutôt pour la façon de les faire interragir, mais on peut très concevoir sa propre utilisation du polymorphisme et autres concept objets sans passer par des pattern.
http://smeric.developpez.com/java/uml/
Edit: voir aussi les notions de découpage en couche de SOA qui va plus loin dans la séparation des rôles d’objets que la partie métier/technique, et qui est un peu différent aussi du principe MVC. on peut très bien développer objet sans connaître tout ça, mais en avoir au moins une vague idée est utile à mon avis 
Merci deltree,
Tu m`as aidé a mieu comprendre l’utilisation de l’objet. J’avais déjà une idée de son utilisation mais avec ces quelques lignes d’explication ça me donne une meilleur idée.
Salutation!