Discussion :

[gside]

Bonjour à tous,

J'arrive dans le monde .net depuis peu, avec l'objectif de porter une application multi-tiers écrite en Delphi. Bases C# et .NET2.0 assimilées il me semble, mais je reste un peu (beaucoup) perdu face à la multitude de technos introduites à partir du framework 3.0, dont certaines sont déjà déclarées depréciées (ADO.NET, Linq to Sql).


Mon souci majeur étant la productivité et simplicité d'utilisation avant les possibilités techniques, quelles seraient selon vous les meilleures combinaisons de technos afin de réaliser une appli respectant ces quatres exigences:
- n-tiers, avec client WinForm évolutif vers WPF
- re-hosting de workflow WF
- fortement orientée gestion: nombreux accés base de donnée et nombreuses entités à gérer
- indépendance du SGBD
et quels sont les efforts d'apprentissage face au gain de productivité espérés?


Autre questionnement... les technos poussées par MS sont elles vraiment toutes intégrables facilement à ce jour (avec .NET 3.5SP1, voir .NET 4.0)?
Par exemple:
- Entity Framework en modèle n-tiers? compatible ObjectDataSource?
- Entity Framework indépendant du SGBD (utilisation des DbProviderFactories plutot que les classes typées Oracle, etc. ?)
- Workflow re-hostable sous WPF?
- Workflow persistent via Entity Framework?

Merci d'avance pour vos avis éclairés sur ces deux sujets
Tout retour d'expérience sur ce type de projet (gestion, multi-tiers) serait également le bienvenu!

[Pierre Henri Kuate]

Pas évident de répondre à ta question. En fait, il semble que le principal choix que tu ai soit entre WPF et WinForm.

Je pense que tu devrais choisir WPF plutôt que WinForm parce que sur le long terme, je pense que Microsoft se concentrera plus pour développer WPF.

Pour l'ndépendance du SGBD, regarde aussi NHibernate (commence avec cet article). Avant Entity Framework, c'était la solution la plus populaire (et techniquement, ça reste la plus avancée).

[gside]

Oui question peut être un peu trop large, je précise:

J'essaie en fait d'évaluer si l'utilisation de .NET reste viable pour l'édition de logiciel de gestion en individuel ou petit groupe 2/3 pers., et quels sont les choix recommendés dans cette configuration:

- utilisation ou pas d'un ORM, en prenant en compte le cout d'apprentissage (NHibernate), de débug/optimisation (stabilité de EF)

- utilisation des wizards ou code manuel, en particulier pour le dataset: 1 table = 2500 lignes de code générées (!) c'est du code à comprendre et à maintenir: l'utilisation du wizard a aussi un coût...

- utilisation ou pas d'une couche de services, utilisation de WCF ou remoting directement?

Un retour d'expérience du type "j'ai utilisé xy pour le GUI, dataset créés par code, pas d'ORM, et .NET remoting plutot que WCF pour telles raisons" serait super

Merci

[Philippe Vialatte]

ok

Un retour d'expérience du type "j'ai utilisé xy pour le GUI, dataset créés par code, pas d'ORM, et .NET remoting plutot que WCF pour telles raisons" serait super

Sur mes derniers projets j'ai utilise :
- Subsonic comme mapper de bases de donnees (projet en 2.0, et pas le temps de faire monter l'equipe en competence sur NHibernate)
- StructureMap et une couche de DTO pour rendre l'appli la plus ignorante de la persistance possible
- cote winform, le controle NicePanel de PureComponents pour le mapping de l'UI et pour avoir une UI sympa
- surtout pas de wizard ou de datasets fortement types, c'est la mort de l'equipe de maintenance

Cote ORM, mon coeur balance, en open-source, pour des projets "complexes", je dirais NHibernate, pour des projets plus "simples", Subsonic, cote Microsoft, la derniere version d'EF est sortie et semble prometteuse, cote vendeurs, lightspeed ORM semble nickel...

Je pense que tu devrais choisir WPF plutôt que WinForm parce que sur le long terme, je pense que Microsoft se concentrera plus pour développer WPF.

Pas d'accord...Winform reste le produit le plus repandu cote UI bureau pour le moment, si on parle de long terme, toujours prendre en compte l'aspect maintenance, et, pour le moment, il est plus facile de faire maintenir une appli winform que WPF.
A la limite, implementer une jolie separation MVC, pour passer facilement a WPF le jour ou la majorite des developpeurs peut supporter WPF, je dis pas non (en plus, c'est plus propre )

[gside]

ok, je commence à mieux me figurer quels choix conviendraient:

DAL: Subsonic pour générer les classes (ça reste une approche dataset typé il me semble, mais indépendant du sgbd)

Couche objet: Existe-il un outil complémentaire à subsonic facilitant la création des classes correspondantes?

GUI: Utilisation des interfaces et factory afin de rendre la GUI le plus indépendante possible de la couche objet, et permettre par exemple le passage de WinForm à WPF - (MVC comme recommandé par Philippe)

Je fuis définitivement les wizards, car pas adepte de l'approche 'génération de code' sans que:
1) ce code soit encapsulé (i.e. le code généré peut être modifié, ce qui pose des problèmes de maintenance et robustesse) et
2) paramétrable (utilisation de propriétés ou techniques plus évoluées, pour modifier le comportement du code généré, plutot que d'aller directement modifier le code généré)
C'est vraiment LE point qui me perturbe dans visual studio, tout le reste (framework) étant vraiment trés bon! Avis bienvenus

Merci pour votre aide