Version imprimable
Là, il faut peut être cesser de raconter n'importe quoi : on s'en est passé pendant des années, et, que je sache, les projets fait ainsi ne plantent pas tout les matins et sont maintenus. Cela qui ne signifie certes pas que les ORM sont inutiles, mais affirmer qu'ils sont indispensables est juste risible.Citation:
Envoyé par marcusien
Attention, je ne dis pas que c'est indispensable, je sais pertinemment que des personnes s'en passent très bien et qu'ils n'ont pas toujours existé.
Mais dans l'optique d'un travail orienté objet et une deadline qui n'est pas très lointaine, je pense qu'on peut difficilement faire sans. Et également en termes de maintenance je pense que, malgré les problèmes que peuvent poser certains ORM, ils permettent vraiment de faire quelque chose de plus facilement compréhensible.
Je ne voudrais pas porter un oeil d'expert sur la pertinence de l'utilisation ou non d'un ORM étant donné que je ne suis pas assez expérimenté pour pouvoir affirmer que c'est mieux avec ou sans.
Etant donné le statut de notre société, on peut difficilement se passer des différentes couches d'abstraction pour avoir un rendement correcte lors de nos développements.
Si vous ne voulez pas partir dans un ORM:et avec un générateur de code style codesmith pour générer votre DAL?
Quel type d'application ? ASP.NET, WinForms, WPF, autre ?Citation:
Envoyé par marcusien
Avec CFE, tu crées un modèle (comme avec Entity Framework mais en plus complet) et tu génères le code SQL pour les tables et les vues et les procédures stockées (SQL server ou Oracle) et C#. Tu peux regarder les WebCast sur leur site pour te donner un aperçu rapide de l'outil.Citation:
Envoyé par marcusien
On veut partir sur du WPF avec MVVM.
Avant on développait avec XAF de DevExpress (qui fonctionne avec XPO) mais le manque de contrôle sur le code et les comportements de l'application nous a posé pas mal de soucis lors d'autres projets, donc on a voulu se réorienter.
Marcusien,
Je connais de très près les progiciels du domaine des négociants pour des raisons personnelles. Ce sont des progiciels vastes et riches fonctionnellement, comme tous les progiciels métiers.
Ce que je peux dire au vu de l'échange, du délai et de la taille d'équipe mentionnée, c'est que le projet tel que tu le décris va au suicide sans outil.
Donc oui, faire l'accès aux données "à la main" n'est pas une bonne option. Mais l'ORM n'est certainement pas le niveau d'outillage suffisant pour ce contexte.
Oui, certains projets peuvent aboutir avec un ORM et de très bons ouvriers, comme l'ont écrit certains, mais la dimension du projet que tu décris et le contexte PME / taille d'équipe modérée me laisse penser avec une quasi-certitude (pour faire comme le Gartner je dirais probabilité 0,98 :)) que le projet n'a aucune chance d'aboutir avec ce seul niveau d'outillage.
Daniel
Et quel niveau d'outillage conseillez-vous ? que peut-on faire de plus qu'avoir un ORM ainsi que d'adopter une techno comme WPF ? Je ne vois pas trop...
Je pense que tu devrais regarder le pdf conseillé par Daniel Cohen Zardi. Il explique assez bien la différence entre CodeFluent Entities et un ORM comme Entity Framework.Citation:
Envoyé par marcusien
http://www.codefluententities.com/do...0Framework.pdf
Ensuite tu peux l'essayer sur un petit modèle (quelques tables) et ainsi voir que qui est réellement possible (en tout cas avoir un petit aperçu). Il existe une license gratuite pour les usages non commerciaux. Cela devrait te permettre de tester et de voir une grande différence avec les ORM.
J'ai pris CodeFluent Entities et je compte le tester à titre personnel, mais la décision dans notre entreprise s'est rabbatue sur XPO de DevExpress.
Merci de vos réponses en tout cas.
Laurent
Pourrais-tu nous donner la raison de ce choix ?Citation:
Envoyé par marcusien
nhibernate avec un générateur de fichiers HBM et classes
Ensuite vous pouvez diviser vos hbm et classes par modules fonctionnels (sous forme de projets de modeles) et utiliser uniquement tel ou tel entité dans tel ou tel partie de l'application.
Ce qui ne serai pas possible avec un edmx centralisé en EF.
Nhibernate est clairement plus flexible pour ce type de besoin.
Tout simplement parce qu'il a déjà fait ses preuves lors de nos précédents projets comptant environ 300 tables, qu'il a une approche en mode "Code First" et que nous avons pris l'habitude de l'utiliser (dans un autre contexte, puisqu'avec XAF).Citation:
Envoyé par meziantou
Ce projet étant le projet principal justifiant notre activité, il n'est pas évident de prendre trop de risques avec des technologies que nous ne connaissons pas, et sont fournis par des tiers (XPO est fourni par un tiers, mais nous connaissons le produit).
De toute façon la décision ne vient pas de moi, mais ce choix nous paraissait le plus cohérent