septembre
2010
Un article de Philippe Vialatte
J’ai récemment eu l’occasion de participer à la revue d’un des livres qui sera prochainement publié par Manning, à savoir (c’est déjà dans le titre, mais, bon) ASP.NET 4.0 in practice.
C’est déjà le troisième (aprés le Brownfield Application Development et le ASP.NET MVC in Action) livre de cet éditeur que je revois, et, comme à chaque fois, l’expérience est très intéressante, ne serait-ce que pour la satisfaction de l’accès en avant-première au contenu ;).
Pour ne pas déroger à la tradition, ce livre vaut le coup (et le coût, d’ailleurs) d’être lu. Au début, je m’attendais à lire encore un manuel de développement, qui expose pas à pas le lecteur à ASP.NET. Sauf que ce n’est pas du tout le cas (contrairement à ce que le premier chapitre laisserait comprendre).
Au contraire, le livre est axé sur une logique de problème/solution/discussion, et expose un ensemble de « recettes » allant de l’accès aux données à l’optimisation, en passant par des détails sur Ajax et ASP.NET MVC. Il aborde aussi les nouveautés d’ASP.NET 4.0, en les mettant la plupart du temps en parallèle avec les version précédentes.
Après relecture, ce livre est donc plutôt à conseiller aux développeurs expérimentés qui ont envier non seulement de se former sur les quelques nouveautés d’ASP.NET 4.0, mais aussi de garder à disposition un ensemble de solution à quelques problèmes courants. Il est par contre excessivement léger sur la partie MVC.
Au final, ma recommandation est d’acheter si vous avez déjà une certaine expérience en ASP.NET, et que vous n’allez pas développer d’applications MVC. Si vous êtes dans ce cas, ce livre peut être une mine d’or 
8 Commentaires + Ajouter un commentaire
Articles récents
Archives
- janvier 2014
- septembre 2013
- août 2013
- mai 2013
- avril 2013
- janvier 2013
- août 2012
- juin 2012
- mai 2012
- avril 2012
- mars 2012
- novembre 2011
- septembre 2011
- août 2011
- juillet 2011
- juin 2011
- mai 2011
- avril 2011
- février 2011
- janvier 2011
- novembre 2010
- octobre 2010
- septembre 2010
- août 2010
- juillet 2010
- juin 2010
- mai 2010
- avril 2010
- mars 2010
- février 2010
- janvier 2010
- décembre 2009
- novembre 2009
- octobre 2009
- septembre 2009
- août 2009
- juillet 2009
- juin 2009
- mai 2009
- avril 2009
- mars 2009
- février 2009
- janvier 2009
« où il sera largement plus facilement manipulable , debuggable » => Ah bon ?
« quels control webform n’est pas disponible en jquery ou en protoype » => Il ne faut pas confondre contrôle serveur et contrôle client. Et je pense que l’auteur fait référence aux nombreux contrôles des éditeurs tiers. Exemple simple : je veux un contrôle tout en un pour requêter des cubes OLAP sur une page Web ASPX avec affichage de graphe, Drag&Drop de Mesures ou dimensions, le tout an Ajax, etc… En Web Form il existe de nombreux contrôles ASP.NET dont le plus connu est Dundas OLAP Chart (techno rachetée par Microsoft et renommée en ASP.NET Chart lol). Et en MVC qu’est ce qu’il y a pour l’instant ?
« Le coté « chaque techno a ses avantages et ses inconvénients » est très sympa, mais faut donner des cas concrets » => c’est pas l’objet du bouquin comme tu l’as dit. De plus, ce genre de cas ne sera jamais totalement admis par la partie adverse et le débat continuera….
Bref, je ne dis pas que tu as tort, et de toute façon il est toujours bon de connaître l’avis des autres et s’ouvrir aux différentes solutions. Mais il ne faut pas voir tout noir ou tout blanc
Ce paragraphe a été écris par des gens qui ont chacun sorti plusieurs livres sur asp.net une introduction du style « Fermez ce livre et achetez en un sur mvc » serait malvenue.
Le coté « chaque techno a ses avantages et ses inconvénients » est très sympa, mais faut donner des cas concrets. »but you need to implement a lot of things that WebForm gives you out of the box » … lesquelles ? quels control webform n’est pas disponible en jquery ou en protoype (ou il sera largement plus facilement manipulable , debuggable, personnalisable, etc etc).
Bon faut que je mette à bloguer plus sur MVC que sur WebForm pour faire avancer les choses lol.
Sinon j’ai regardé le premier chapitre du bouquin (je n’avais pas vu le lien tout à l’heure), et l’auteur résumer bien la chose :
« As a side note, there’s a lot of debate in the ASP.NET community regarding MVC vs WebForm. They have different ambitions and serve different kind of applications, so there’s not a good choice and a bad one. ASP.NET MVC is for markup control, while WebForm is for productivity. Keep them in mind and you’re set. MVC gives you flexibility, but you need to implement a lot of things that WebForm gives you out of the box. The rule here is not new: choose with your mind, not your heart! »
Le problème de la communauté MVC est un faux problème a mon avis, pour la bonne raison que c’est beaucoup moins une boite noire que webforms.
Quand j’ai commencé a migrer de webform vers castle j’étais très satisfait car ces framework mvc sont très très léger et au final (et tant mieux) ne font pas grand chose:
– url rewriting
– l’appel des action du controller
– le binding des paramètre
– l’envoi des donnée du controller vers la vue
– l’execution de la vue
Qui ne sont que la liaison entre la vue et le controller donc le nombre de problème spécifique est grandement réduit.
Mais comme pour toute nouvelle techno effectivement abandonner l’ancienne juste après sa sortie (1 ans et demi pour MVC) peut faire peur aux client et c’est à mon avis uniquement pour une question d’image, que pour améliorer la techno que cette nouvelle version est sortie.
PS : je parle de castle comme de asp.net mvc, mais vu les review que j’ai vu la philosophie et même l’utilisation de ces deux framework sont très très proche (je parle uniquement du cœur la). mvc vaut certainement plus le coup vu qu’il ya plus de monde dessus et que comme tu l’a dit d’ici 2 ans la communauté sera importante, et le nombre de version aussi.
@Bourgui: passer conceptuellement de Webform à MVC n’est effectivement pas un gros effort.
Personnellement, je suis moi aussi convaincu de la robustesse et de la classe générale de MVC. Par contre, regarde la situation d’un autre point de vue. Quel est l’intérêt *dans l’absolu* ?
La migration en terme de code n’est pas triviale, le cout des formations non plus. Un chef de projet, ou un DSI, te dira dans 80% des cas que c’est bien beau, mais que si dans 6 mois tu as des changements d’équipe, et qu’il faut re-former tout le monde, il partira pas sur cette techno (c’est du vécu :p)
> Webform est une perte de temps de formation et de maintenance, je dirais même une énorme perte de temps. Avec les webform tu es toujours en formation, à aucun moment tu te sent à l’aise avec les control et à face à chaque situation hors du commun
A voir…personnellement, je ne me rappelle pas avoir jamais passé plus de quelques minutes à chercher une solution potable en Webform. Par contre, il y’à un an, trouver du support sur MVC, c’était la croix et la galère (et sur certains points techniques, c’est toujours le cas).
Je pense que MVC ne verra pas d’adoption massive avant encore un ou deux ans, et même pas pour des raisons techniques, mais parce que pour l’instant, les amélioration apportées par MVC sont principalement *techniques* (même si dans technique, tu mets un design plus propre), il va donc falloir attendre que la communauté, en général y ait été suffisamment exposé
Je travaille avec asp.net 2.0 depuis 3 ans et castle monorail depuis 2 ans (y’a plus, y’a moins, mais pour dire que je ne suit pas au courant de l’asp.net que en lisant un article de temps en temps).
Ma remarque ne concerne pas spécialement le livre, mais cette techno en général et le fait de sortir des nouvelles versions. J’ai encore pas trouvé 1 article encensant les webforms, mais des tonnes relatant toujours les mêmes problème, et MS les a écouté en sortant Asp.Net MVC (je ne l’ai pas testé, mais il semble très proche de castle monorail donc…). Pourquoi continuer a sortir des mises à jour pour 2 techno dont les objectifs sont les mêmes ? Et pas sortir des outils permettant de migrer d’une techno qui était mal parti et a mal continué, vers une techno meilleure et plus simple ?
Très franchement la migration des webforms (au niveau connaissance, pas au niveau code) vers mvc (que ce soit asp.net ou castle, dans l’idée c’est kifkif) n’implique pas énormément de la part du développeur, ça sera pas « Comment on fait ce truc de webform en mvc ? » mais plutot « a cool j’ai plus a me faire ch##r a faire des astuce stupide pour arriver à mes fins ».
Webform est une perte de temps de formation et de maintenance, je dirais même une énorme perte de temps. Avec les webform tu es toujours en formation, à aucun moment tu te sent à l’aise avec les control et à face à chaque situation hors du commun (établi par ms), tu te retrouve a faire des patchaque inmaintenable (pour preuve : quand on cherche une solution, il faut passer 4j a chercher sur google pour trouver une solution non dégueulasse).
Cette remarque est typique d’un développeur qui ne voit pas plus loin que le bout de son nez
(sans vouloir t’offusquer).
Il faut penser plus large au sein d’une entreprise. Déjà, quel intérêt à changer de techno pour faire exactement le même type d’application ? S’il y a gain de temps, gain d’argent, ou gain en terme d’efficacité ou sécurité ça vaut le coup. Sinon non.
Il faut aussi penser à l’investissement nécessaire, et notamment en terme de formation (les bons développeurs MVC ne courent pas les rues). Il y a aussi les applications à maintenir. On ne passe pas une application du Web Form au MVC du jour au lendemain (surtout que ça n’a pas de sens, l’idéal reste de la recommencer à partir de zéro). Egalement, il faut voir les offres des éditeurs tiers qui est plus fournie pour Web Forms que MVC (normal vu la différence d’ancienneté). Etc… Etc… Etc…
Maintenant, je suis d’accord avec toi sur le fait que MVC sera un meilleur choix pour les nouveaux devs. Quoique Web Form garde encore le gros avantage de permettre de faire du RAD.
Sinon pour revenir au bouquin, tu peux me le passer sous le manteau Philippe ?
Ta description a aiguisé ma curiosité. Il est prévu pour quand ?
Quel et l’intérêt de continuer a utiliser les webforms sachant qu’il y a Asp.Net MVC ?