Discussion :

[exile69]

Bonjour,

Actuellement nous avons une application client lourd développer en C# framework 2.0 avec des bases SQL Server 2005.

Cette application commence à vieillir et nous sommes en train de rédiger un cahier des charges pour un projet de refonte.
Nous voudrions une application Web, afin de pouvoir avoir une base de données centralisée, l'application pourra être consultée sur tablette ou smartphone.

Nous avons environ 1000 utilisateurs qui devront se connecter.

Notre société étant en accord avec Microsoft, nous partirons sur une base de données SQL Server 2012, par contre nous ne savons pas sur quelle technologie se tourner ? (ASP.NET, MVC, Ajax ?) Quels framework pourrons nous utiliser ? (Nhibernate....)

Merci de vos réponses

Cordialement

[Isythiel]

Bonjour,

Pour ce qui est de la techno côté client, je te conseille de te pencher vers HTML 5, y compris pour tablette et smartphone.

Ca commence à se démocratiser chez nos clients grand compte, la majorité envisage de refondre leurs applis Java, ASP.NET ou Silverlight en HTML5 dans les 5 ans qui viennent.

Ca paraît être une valeur sûre.

En espérant avoir pu t'aiguiller.

Bon courage.

[meziantou]

Combien de tables ? Vont-elles évoluées dans le temps ? Appli tablette ou smartphone natives ou simplement un site adapté pour les mobiles ? Quels types d'informations y aura-t-il sur le site ? ...

On peut lister une quantité d'outil et de framework mais si tu veux une aide utile, il faut vraiment préciser ton besoin.

[exile69]

Nous avons environ 250 tables dans la BDD, nous voulons refaire dans un premier temps le schéma complet de la base de données, car les processus métiers ont été revus, pour les tablettes et smartphone sa sera une application native.

Nous avons besoin d'avoir accès à l'application tout le temps, réseau interne, 3g, VPN. En cas ou le serveur SQL serai à plat, un autre serveur prendrai le relais automatiquement sans que les utilisateurs ne s'aperçoivent de quelque chose.
L'application doit être fluide et rapide.

Concernant l'architecture, nous pensions mettre en place un serveur SQL + un serveur Applicatif + un serveur Web (avec service web).

Actuellement sur notre client lourd, les écrans sont très surchargés d'informations à saisir par l'utilisateur, je pense que sur l'application Web nous allons devoir faire des écrans "plus léger".

[plume13]

Pour la techno web côté serveur, je te conseille MVC4 les yeux fermés. Cela vous permettra de faire le code HTML que vous voulez le plus simplement possible.
Pour moi, les WebForms sont à proscrire (ça fait 10 ans que j'en fais, lorsque j'ai découvert le MCV, j'en ai presque pleuré : la simplicité de l'ASP "classique" mêlée à la puissance du .NET / C#, le rêve !)

[meziantou]

Pour un projet comme cela, je te conseille de partir avec une approche Model First à l'aide d'outil comme CodeFluent Entities.

Pour les applications mobiles il faudra un WebService : WCF, ServiceStack, WebAPI, ... (selon le besoin). A noter que pour exposer uniquement du JSON WCF est moins adapté comparé aux 2 autres solutions. Pour info il est possible de les générer avec CodeFluent Entities à moins d'avoir un besoin custom.

Pour le site web je ne suis pas du même avis que plume13. ASP WebForms a certes 10 ans mais a encore des avantages selon le besoin. Le HTML généré est peut-être moins clean mais les DataSources, le ViewState, etc. peuvent être très utile selon le type d'écran. De plus les composants tierces (type Telerik, DevExpress, etc) sont bien plus complet que ceux pour ASP MVC.
Je ne dis pas qu'il faut partir sur ASP WebForms, mais plutôt qu'il faut bien comparer les 2 et choisir le plus adapté en fonction du besoin.

Pour les appli mobile il existe des solutions permettant de mutualiser le développement pour les différentes plateformes. Par exemple MVVM Cross (http://stackoverflow.com/questions/1...ht-limitations).

Nous avons besoin d'avoir accès à l'application tout le temps, réseau interne, 3g, VPN. En cas ou le serveur SQL serai à plat, un autre serveur prendrai le relais automatiquement sans que les utilisateurs ne s'aperçoivent de quelque chose.

C'est plus un problème d'infra que de dév.

L'application doit être fluide et rapide.

C'est rare de vouloir l'inverse

[plume13]

Pour le site web je ne suis pas du même avis que plume13. ASP WebForms a certes 10 ans mais a encore des avantages selon le besoin. Le HTML généré est peut-être moins clean mais les DataSources, le ViewState, etc. peuvent être très utile selon le type d'écran. De plus les composants tierces (type Telerik, DevExpress, etc) sont bien plus complet que ceux pour ASP MVC.
Je ne dis pas qu'il faut partir sur ASP WebForms, mais plutôt qu'il faut bien comparer les 2 et choisir le plus adapté en fonction du besoin.

Ok, je complète ma réponse
Si jamais, par hasard, vous partez sur du HTML5, préférez plutôt le MVC, sinon, vous risquez de ne pas avoir assez de corde...

[meziantou]

Ok, je complète ma réponse
Si jamais, par hasard, vous partez sur du HTML5, préférez plutôt le MVC, sinon, vous risquez de ne pas avoir assez de corde...

Pourrais-tu donner quelques exemples de choses réellement plus simple à faire en MVC qu'en WebForms (spécifiquement pour HTML5).

A noter qu'avec WebForms 4.5 il y a eu des améliorations au niveau du support de HTML5 : http://weblogs.asp.net/sreejukg/arch...p-net-4-5.aspx

[plume13]

J'ai pas trop envie de polémiquer MVC vs WebForms, mais l'avantage principal que je vois au MVC, c'est la maitrise totale du code HTML. Et bien sûr la séparation présentation / données.
J'ai commencé sur du site web en asp (classique), du coup, le côté "c'est comme les WinForms mais en web" ne m'a jamais vraiment convaincue.
C'est pour cela que par rapport aux messages précédents préconisant le HTML5, il me semble que le MVC est plus adapté.

Bon, le problème avec les vieux/vieilles, c'est qu'ils pensent toujours avoir raison

[Isythiel]

Retour d'expérience sur un gros projet (>800k€) en ASP.NET et sans MVC : c'est le bordel à la maintenance et pour l'évolution.

Si vous êtes plusieurs développeurs à passer dessus, chacun fait à sa sauce, et réimplémente des méthodes de service lorsqu'il ne les trouve pas. Et pourtant, l'"architecte" de l'époque avait tenté de mettre en place une séparation Méthodes de service / UI
Ca a d'autres conséquences : les méthodes business avec règles de gestion importantes DIRECTEMENT implémentées dans le OnDataBinding des tableaux.
Autant dire que lorsque le client demande à ajouter de nouvelles règles, vous pleurez pour le débug et la performance.

Ceci était certainement du aussi à une absence de maîtrise d'ASP .NET (appris sur le tas par l'ensemble de l'équipe), mais pour avoir fait du MVC dans d'autres projets, je peux confirmer que ça cadre les choses et que tout le monde s'y retrouve


Note : Telerik a aussi un framework dédié à MVC

[plume13]

Chouette une autre fille, et en plus elle est d'accord avec moi

Ceci était certainement du aussi à une absence de maîtrise d'ASP .NET (appris sur le tas par l'ensemble de l'équipe)

Tout pareil ! à l'usage, je me suis rendue compte (et je m'en rend compte encore car je travaille sur de l'ASP.NET toute la journée), que la plupart des développeurs ASP.NET ne comprennent pas la logique derrière, donc développer un formulaire avec 3 inputs et 2 selects, OK, mais si on veut faire des choses plus chiadées, même avec un framework type DevEpress, ça devient vite l'enfer si on veut faire des évolutions, car chacun a fait un truc, certes qui marche, mais que personne ne comprend, avec du javascript au milieu du C#...

[meziantou]

Si vous êtes plusieurs développeurs à passer dessus, chacun fait à sa sauce, et réimplémente des méthodes de service lorsqu'il ne les trouve pas. Et pourtant, l'"architecte" de l'époque avait tenté de mettre en place une séparation Méthodes de service / UI

Cela montre bien qu'il faut une vraie couche métier et que celle-ci doit être simple pour que tout le monde y trouve ses petits (d'où mon conseil à propos de l'utilisation de CodeFluent Entities et son approche modèle first.

Ceci était certainement du aussi à une absence de maîtrise d'ASP .NET (appris sur le tas par l'ensemble de l'équipe), mais pour avoir fait du MVC dans d'autres projets, je peux confirmer que ça cadre les choses et que tout le monde s'y retrouve

Si ça peut te rassurer on peut tout aussi bien faire n'importe quoi en ASP MVC. Même si ça semble plus cadré, tu es tout aussi insité à mettre du code métier dans tes controlleurs (voire même dans la vue) . Donc même en MVC il faut faire attention.

Conseil: commencer un projet avec des gens expérimentés. Les bases seront surement plus solides et sur le long terme cela s'en ressentira.

[Isythiel]

Conseil: commencer un projet avec des gens expérimentés. Les bases seront surement plus solides et sur le long terme cela s'en ressentira.

Quand tu en as sous la main, oui, évidemment

ça devient vite l'enfer si on veut faire des évolutions, car chacun a fait un truc, certes qui marche, mais que personne ne comprend, avec du javascript au milieu du C#...

Tout pareil... En fait on est peut-être dans la même boîte ...

[meziantou]

Quand tu en as sous la main, oui, évidemment

Si tu n'en as pas sous la main, je pense qu'il vaut mieux payer un consultant senior quelques jours au début du projet. Certes il faut débourser un peu d'argent (vu la taille du projet, je ne pense pas que ce soit le plus important), mais si ça peut aider à réduire la dette technique à plus long termes l'investissement est largement rentabilisé.

[Isythiel]

Tu prêches une convaincue

Je suis tout à fait d'accord aussi sur le fait qu'on peut vite faire n'importe quoi en MVC...
Mais bon, vu la communauté derrière, tu trouves vite des références pour te remettre dans le droit chemin, je pense.

[exile69]

Merci à tous pour vos avis, mais MVC ne serait il pas plus utilisé pour des applications ou les écrans ne sont pas trop riches en contrôles ?

Notre formateur en ASP.NET MVC nous disait que MVC n'est pas trop fait pour des projets avec une multitude d'écrans, car au niveau du déboggage on s'y perd vite.

Pour info notre projet de refonte doit durer environ 5 ans pour un budget total d'environ 5 millions d'euros.

[plume13]

Bah, tu sais ce qu'on dit, les conseilleurs ne sont pas les payeurs

Pour être tout à fait honnête, à choisir je préfère travailler sur du MVC, MAIS il est vrai que j'ai beaucoup moins de recul sur le MVC que sur l'ASP.NET.
Je connais les défauts des Webforms (par coeur) et les avantages du MVC, pour l'inverse j'ai du mal

Parce que, des gens (vraiment) expérimentés, cela ne court pas les rues, en MVC ou en WebForms.

[meziantou]

Je connais les défauts des Webforms (par coeur) et les avantages du MVC, pour l'inverse j'ai du mal

Comme je l'ai dis cela dépend du type d'écran. Sur des formulaires type Grille/Insert/Update/delete je préfère largement WebForm => Un ObjectDataSource lié à mon objet métier, une GridView ou un FormView et hop ça fonctionne, tu as de la pagination, du tri, etc. et tout ça en 3 clicks et 0 ligne de code => c'est pas beau la vie !
Difficile d'être aussi productif en MVC.

Par contre pour faire du CSS et du JS c'est plus compliqué même si cela s'est amélioré (Id prédictible, Html généré plus simple, etc.)

[Graffito]

Qu'on choissise MVC ou WebForms, il est interessant d'isoler la couche métier dans un Web service.

L'avantage est (en dehors de la modularité stricte) de pouvoir écrire des programmes de tests de la couche métier ou des utilitaires d'administration (locaux ou à distance) en Winforms/WCF connectés au Web service.

[alheuredudejeuner]

En septembre, j'ai suivi une formation asp.net chez Dawan.
Nous avons fait du mvc avec des web form.
Le code html est mis en form par css.
Pour les portables, j'utilise le responsive design que je valide là : http://validator.w3.org/mobile/
A mon avis, l’avantage des webform, c’est du concret visible en dev. Pour le code sous-jacent dao et modèle, il suffit de bien nommer ces fichiers, de faire un classement le plus proche possible des conventions habituelles.
Tout cela se prépare avec l’architecture mise en place avant codage.

Maintenant j’aimerai comprendre ce qu’apporte html5 tout seul,
Ce qu’apporte le MVC à HTML5
Et pourquoi il n’y aurait pas de compatibilité entre HTML5 et webForm ?
Ceci dit, je pense que la complexité apparente vient qu’on utilisera tout en même temps.
WebForm HTML5 CSS et un MVC standart ou maison.

cordialement