Discussion :

[trihanhcie]

Bonjour à tous,

Je voulais savoir comment vs codiez vos pages en général.
Par exemple
- est ce que vous utiliser les fonctions Eval ou plutot vous faites dropdownlist.datasource = .... ?
- Est ce que vous utiliser les <sqldatasource> et autre ou vous faites un bind dans le code behind ?
J'ai vu 2 3 projets ou il y avait tellement de sources de données dans la pages aspx que j'avais l'impression qu'il n'y avait plus rien dans le code behind...

Quelle est la "bonne" manière de coder (s'il y en a une) ?

Personnellement je préfère largement tout faire dans le code behind car s'il y a une erreur, on le voit tout de suite au moment de la compilation et on peut passer en mode debug facilement.

Je trouve qu on permet de charger de plus en plus la page aspx et ca devient très compliqué de s'y retrouver...

[lutecefalco]

Je fais tout en code behind.
Dans les .aspx, je ne mets que la partie html, css & js

[Nicolas Esprit]

Bonjour,

Il n'y a pas de "bonne manière" au sens général. Il y a des "Best Pratices" pour un problème donné cependant.

Avec ASP.NET, la tentation est grande de faire du Smart UI, c'est à dire de l'Anti-Pattern. Par exemple avec une SQLDataSource, on peut vite embarquer la logique métier dans la couche UI. De plus lorsqu'on a besoin de fonctionnalités semblables dans une autre page on duplique du code, ce qui ne respecte pas le principe DRY.

Il faut également différencier l'approche ASP.NET Web Forms de l'approche ASP.NET MVC...

Je suis justement entrain d'écrire une série sur les Best Pratices et l'utilisation de Design Pattern pour des applications ASP.NET. Cette série est en cours et j'en arrive à la partie "développement en couche". Il va falloir me laisser un peu de temps avant de voir arriver un article complet sur Developpez .

Ok Smart UI n'est pas une bonne chose. Cependant, pour réaliser un pilote ou une application pour répondre à un besoin évènementiel et qui n'évoluera plus ensuite, il n'y a rien de plus rapide.

Bref, c'est un sujet vaste.

En espérant t'avoir aidé.

[getule]

en ce qui me concerne, aimant la facilité, je suis souvent attiré par le code automatique dû à l'utilisation direct des controles et leurs parametrages. toute fois, rares mes pages ne contenant pas à un tas de code en vb ou c# car plus précis et moins encombrant quand le projet l'exige... pour vous dire c'est souvent le cas.

voila

[trihanhcie]

C'est bien pour les projets asp.net dont je parle et pas asp.net mvc.

Il est sur que c'est plus "pratique" en utilisant les smartui mais je trouve ca horrible à maintenir.

Même pour une simple modification (genre rajouté une liste déroulante et la lié à une source) ca prend 3 lignes de code en code behind.... ce qui fait à peu près une minute de codage et je suis gentil ^^

C'est juste à titre informatif que je poste cela... je me suis retrouve avec des projets ou je vois des "Eval()" de partout et je trouve ca horrible car tu ne peux pas débugger cela !! Tu fais une faute dans la nom de la propriété mais tu ne le sais pas ... bref pas pratique du tout !

Ce qui me surprend, c'est que microsoft permet ce genre de "pratique" pas pratiques pour le développeur !

[Nicolas Esprit]

Hum, c'est pareil dans toutes les technos. Tu as beau faire du MVVM tout beau tout propre en Silverlight par exemple, tu n'en seras pas moins obligé dans ta vue Xaml de bien spécifier le nom des propriétés à Binder.

Mais je comprends ce que tu veux dire, cela peu être frustrant à cause d'un caractère mal saisi, de ne pas voir son code s'exécuter correctement.

Malheureusement pour ce genre de choses : difficile de le vérifier à la compilation. Quoique avec Silverlight, tu peux utiliser des données pour le mode Design et vérifier ainsi directement si les bonnes propriétés sont spécifiées pour le Binding.

Ensuite, même en codant un maximum dans le code-behind, tu pourras toujours avoir des erreurs de saisie dans le nom de propriétés et tu ne t'en apercevra qu'au moment de l'exécution.

[Nathanael Marchand]

C'est bien pour les projets asp.net dont je parle et pas asp.net mvc.

Il est sur que c'est plus "pratique" en utilisant les smartui mais je trouve ca horrible à maintenir.

Même pour une simple modification (genre rajouté une liste déroulante et la lié à une source) ca prend 3 lignes de code en code behind.... ce qui fait à peu près une minute de codage et je suis gentil ^^

C'est juste à titre informatif que je poste cela... je me suis retrouve avec des projets ou je vois des "Eval()" de partout et je trouve ca horrible car tu ne peux pas débugger cela !! Tu fais une faute dans la nom de la propriété mais tu ne le sais pas ... bref pas pratique du tout !

Ce qui me surprend, c'est que microsoft permet ce genre de "pratique" pas pratiques pour le développeur !

C'est les restes du Quick'n'Dirty qu'il y avait en Visual Basic. Si ils commencent à virer ca, y'a tous les anciens qui vont gueuler