Maintenabilité des projets ASP.NET MVC
9 views
Skip to first unread message
Denis Dollfus
Nov 19, 2008, 5:34:03 PM11/19/08
to paris.alt.net
Bonjour à tous,
Ce post de l'inimitable Justice Gray laisse penser que les projets qui
reposent sur le framework MVC de MS peuvent être difficiles à
maintenir sur le long terme à cause du manque de lisibilité du code
mixé HTML/C#.
Qu'en pensez vous ?
Ce post de l'inimitable Justice Gray laisse penser que les projets qui
reposent sur le framework MVC de MS peuvent être difficiles à
maintenir sur le long terme à cause du manque de lisibilité du code
mixé HTML/C#.
Qu'en pensez vous ?
Denis Dollfus
Nov 19, 2008, 5:54:20 PM11/19/08
to paris.alt.net
Gauthier Segay
Nov 19, 2008, 6:08:47 PM11/19/08
to paris.alt.net
J'ai lu le post en diagonale, mais j'ai plus l'impression qu'il parle
de l'avenir pour ceux étant capable de maintenir des projets webform:
"""
If only you knew how much people like me make cleaning up WebForms
projects gone wrong!!! With every half-assed DotNetNuke
implementation I save somebody from, it's another *10 billion dollars*
in my pocket.
"""
Pour la question maintenabilité, sans vouloir être expéditif (je pense
que cela soulève un débat intéressant et j'y reviendrais surement),
j'ai beaucoup plus de mal à maintenir une bouillie de tag asp.net avec
un comportement statefull (mhh viewstate, mmh OnRowDataBound de 1000
lignes) qu'une boucle foreach ou deux dans le code d'une vue (sachant
que le binding avec le protocole http est beaucoup plus sain avec une
approche MVC) et de quelques appels ajax fait explicitement (sans drag
& drop d'un updatepanel au dernier moment).
Pour peu que l'on ai un minimum reflechi au jeu de donnée à
communiquer à la vue, je ne vois pas comment faire plus élégant et
concis.
J'attends d'autres avis, mais j'ai commencé les webforms depuis fin
2002 et disposais (bien heureusement pour moi) d'une expérience web
pré-existante, j'interviens encore sur des projets webforms
rencontrant des problèmes de performance ou autre joyeusetés, mais je
ne commencerais pas de nouveaux projets avec ce framework, et je suis
bien heureux que Microsoft sorte un framework MVC au cas ou un client
serait totalement réticent à utiliser monorail.
Le framework des webform est "puissant", mais il doit y avoir 1% des
développeurs l'utilisant capables de le faire correctement, de manière
optimisée avec à l'issue une architecture "maintenable", je pense que
le ratio des appli maintenable pour les autres langages web est bien
plus avantageux.
de l'avenir pour ceux étant capable de maintenir des projets webform:
"""
If only you knew how much people like me make cleaning up WebForms
projects gone wrong!!! With every half-assed DotNetNuke
implementation I save somebody from, it's another *10 billion dollars*
in my pocket.
"""
Pour la question maintenabilité, sans vouloir être expéditif (je pense
que cela soulève un débat intéressant et j'y reviendrais surement),
j'ai beaucoup plus de mal à maintenir une bouillie de tag asp.net avec
un comportement statefull (mhh viewstate, mmh OnRowDataBound de 1000
lignes) qu'une boucle foreach ou deux dans le code d'une vue (sachant
que le binding avec le protocole http est beaucoup plus sain avec une
approche MVC) et de quelques appels ajax fait explicitement (sans drag
& drop d'un updatepanel au dernier moment).
Pour peu que l'on ai un minimum reflechi au jeu de donnée à
communiquer à la vue, je ne vois pas comment faire plus élégant et
concis.
J'attends d'autres avis, mais j'ai commencé les webforms depuis fin
2002 et disposais (bien heureusement pour moi) d'une expérience web
pré-existante, j'interviens encore sur des projets webforms
rencontrant des problèmes de performance ou autre joyeusetés, mais je
ne commencerais pas de nouveaux projets avec ce framework, et je suis
bien heureux que Microsoft sorte un framework MVC au cas ou un client
serait totalement réticent à utiliser monorail.
Le framework des webform est "puissant", mais il doit y avoir 1% des
développeurs l'utilisant capables de le faire correctement, de manière
optimisée avec à l'issue une architecture "maintenable", je pense que
le ratio des appli maintenable pour les autres langages web est bien
plus avantageux.
Julien Lavigne du Cadet
Nov 20, 2008, 2:08:02 AM11/20/08
to paris.alt.net
J'ai également l'impression qu'il parle plus des webforms que
d'asp.net mvc :).
Cependant, en ce qui concerne la mixité c#/html, il y a effectivement
débat dans la communauté .Net (mais aussi sur d'autres technos!). Je
pense notamment à cet article :
http://www.codinghorror.com/blog/archives/001155.html
Mon expérience personnelle est que ca peut rapidement devenir le
bordel si on ne se fixe pas certaines règles. Par exemple, je ne fais
pas :
<%= Html.Image("/url/de/mon/image.jpg") %> mais <img src="/url/de/mon/
image.jpg" />. L'implémentation fournie de Html.Image n'a pour moi
aucun intérêt vu qu'elle n'offre aucune fonctionnalité additionnelle.
Le HTML gère déjà très bien ce concept donc autant en rester la!
L'autre problème est la mauvaise lisibilité des accolades. Exemple :
<% if(true) { %>
<!-- du code html... -->
<% } %>
le <% } %> n'est souvent pas très visible au milieu du code, mais on
s'y fait. J'aurai bien aimé qu'ils implémentent un système à la PHP,
un peu plus lisible :
<?php if(true): ?>
<!-- du code html... -->
<?php endif; ?>
Dernier conseil :
Utiliser au maximum le système de RenderPartial pour simplifier les
vues!
Ce qui est sur c'est qu'en terme de maintenabilité, asp.net mvc est à
des kilomètres des webforms (beurk!)!
Julien
d'asp.net mvc :).
Cependant, en ce qui concerne la mixité c#/html, il y a effectivement
débat dans la communauté .Net (mais aussi sur d'autres technos!). Je
pense notamment à cet article :
http://www.codinghorror.com/blog/archives/001155.html
Mon expérience personnelle est que ca peut rapidement devenir le
bordel si on ne se fixe pas certaines règles. Par exemple, je ne fais
pas :
<%= Html.Image("/url/de/mon/image.jpg") %> mais <img src="/url/de/mon/
image.jpg" />. L'implémentation fournie de Html.Image n'a pour moi
aucun intérêt vu qu'elle n'offre aucune fonctionnalité additionnelle.
Le HTML gère déjà très bien ce concept donc autant en rester la!
L'autre problème est la mauvaise lisibilité des accolades. Exemple :
<% if(true) { %>
<!-- du code html... -->
<% } %>
le <% } %> n'est souvent pas très visible au milieu du code, mais on
s'y fait. J'aurai bien aimé qu'ils implémentent un système à la PHP,
un peu plus lisible :
<?php if(true): ?>
<!-- du code html... -->
<?php endif; ?>
Dernier conseil :
Utiliser au maximum le système de RenderPartial pour simplifier les
vues!
Ce qui est sur c'est qu'en terme de maintenabilité, asp.net mvc est à
des kilomètres des webforms (beurk!)!
Julien
Denis Dollfus
Nov 20, 2008, 4:05:00 PM11/20/08
to paris.alt.net
Oui en fait je pensais à l'article que tu cites Julien et à
l'introduction de celui-ci (très instructif pour moi)
http://blog.wekeroad.com/blog/asp-net-mvc-avoiding-tag-soup/ que j'ai
découvert en partant du post de Justice Gray par je ne sais plus quel
chemin (il faut que j'arrête les posts après 23h00...).
J'interprète vos réponses comme ça : le codage des vues c'est pas top
top, mais l'apport réel du framework MVC est ailleurs, dans
l'isolation claire des controleurs et du modèle et dans la gestion
simple de http et du binding.
Personnellement le code des vues (le coup des accolades) me rappelle
les pages ASP "classique" 3.0 (j'en ai fait aux alentours de 1998 et
après), qu'on critiquait méchamment pour leur manque de séparation
html/code. Et de fait c'était infernal à maintenir. Mais il n'y avait
ni C# ni pattern MVC, ce qui conduisait effectivement à de la soupe en
l'absence de volonté forte de structurer le VBScript ou le JScript.
La réaction "mix HTML/Code = mauvaise techno" est sans doute liée à
ceux qui ont connu les affres d'ASP (tout court) et qui jugent ASP.NET
MVC sur la mine.
On Nov 20, 8:08 am, Julien Lavigne du Cadet <julien.lavi...@gmail.com>
wrote:
> > > Qu'en pensez vous ?- Hide quoted text -
>
> - Show quoted text -
l'introduction de celui-ci (très instructif pour moi)
http://blog.wekeroad.com/blog/asp-net-mvc-avoiding-tag-soup/ que j'ai
découvert en partant du post de Justice Gray par je ne sais plus quel
chemin (il faut que j'arrête les posts après 23h00...).
J'interprète vos réponses comme ça : le codage des vues c'est pas top
top, mais l'apport réel du framework MVC est ailleurs, dans
l'isolation claire des controleurs et du modèle et dans la gestion
simple de http et du binding.
Personnellement le code des vues (le coup des accolades) me rappelle
les pages ASP "classique" 3.0 (j'en ai fait aux alentours de 1998 et
après), qu'on critiquait méchamment pour leur manque de séparation
html/code. Et de fait c'était infernal à maintenir. Mais il n'y avait
ni C# ni pattern MVC, ce qui conduisait effectivement à de la soupe en
l'absence de volonté forte de structurer le VBScript ou le JScript.
La réaction "mix HTML/Code = mauvaise techno" est sans doute liée à
ceux qui ont connu les affres d'ASP (tout court) et qui jugent ASP.NET
MVC sur la mine.
On Nov 20, 8:08 am, Julien Lavigne du Cadet <julien.lavi...@gmail.com>
wrote:
>
> - Show quoted text -
Julien Lavigne du Cadet
Nov 21, 2008, 2:22:31 AM11/21/08
to paris.alt.net
J'ajouterai aussi une chose, on se plaint souvent du mixe HTML/langage
(langage pouvant être du c#, du php, du ruby etc.) mais au final cela
reste de loin la solution la plus rapide en terme d'execution.
Si on est moins regardant, il est tout à fait possible de passer par
des moteurs de templates qui offriront quelque chose de plus propre,
avec l'inconvénient de perdre l'intellisense en .NET.
Asp.net mvc en à quelques uns : NVelocity (provenant de monorail),
NHaml, SparkEngine, etc.
On 20 nov, 22:05, Denis Dollfus <denis.doll...@gmail.com> wrote:
> Oui en fait je pensais à l'article que tu cites Julien et à
> l'introduction de celui-ci (très instructif pour moi)http://blog.wekeroad.com/blog/asp-net-mvc-avoiding-tag-soup/que j'ai
(langage pouvant être du c#, du php, du ruby etc.) mais au final cela
reste de loin la solution la plus rapide en terme d'execution.
Si on est moins regardant, il est tout à fait possible de passer par
des moteurs de templates qui offriront quelque chose de plus propre,
avec l'inconvénient de perdre l'intellisense en .NET.
Asp.net mvc en à quelques uns : NVelocity (provenant de monorail),
NHaml, SparkEngine, etc.
On 20 nov, 22:05, Denis Dollfus <denis.doll...@gmail.com> wrote:
> Oui en fait je pensais à l'article que tu cites Julien et à
Reply all
Reply to author
Forward
0 new messages