Comment vous codez vos pages?

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...

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

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 :aie:.

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é.

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

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 !

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. :aie:

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.

Citation:

---

Envoyé par 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 !

---

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 :D

Oui c'est sur qu'on ne peut les erreurs pour une faute de frappe :p
Mais si bon moins on en utilises mieux c'est !!

Au final, on peut se retrouver avec du code aspx qui va taper directement en table et pas une seule ligne de codebehind :D

Citation:

---

Envoyé par trihanhcie

Au final, on peut se retrouver avec du code aspx qui va taper directement en table et pas une seule ligne de codebehind :D

---

Déjà le code behind qui va taper directement sans passer par BOL & DAL ça le fait moyen (chez moi, ça le fait pas, d'ailleurs).

Disons qu'il faut faire la distinction entre les défauts/contraintes de la techno et les mauvaises pratiques faites par les développeurs.

Le fait qu'une faute de frappe dans une propriété du markup d'une page ne soit pas détectée à la compilation, c'est un reproche qu'on peut faire à l'ASP.NET.

Le fait d'avoir un accès aux données dans la couche UI c'est un (grave) défaut qu'on peut imputer à celui situé entre la chaise et l'écran :aie:

PEBKAC ^^

Oui je suis d'accord... Mais je trouve ca aberrant à ce moment-la qu'ASP.Net permette de tels écarts ...

D'ailleurs une question un peu à part que je me pose depuis un moment sur asp.net (pas MVC).
Est-ce que vous avez déjà travaillé sur un projet asp.net ou il y avait des web designers (qui ne touche pas au code behind) et des codeurs (qui ne toucheraient pas au page aspx) ?

Je me demande juste "à qui" est adressée les fonctionnalités qui permettent de se connecter directement à une source de données dans la page aspx.

Même si c'est pour faire une maquette rapide, au final je suis pas sur qu'on gagne énormément de temps par rapport à passer plus de temps à faire une dal etc etc...

Citation:

---

Envoyé par trihanhcie

Je me demande juste "à qui" est adressée les fonctionnalités qui permettent de se connecter directement à une source de données dans la page aspx.

Même si c'est pour faire une maquette rapide, au final je suis pas sur qu'on gagne énormément de temps par rapport à passer plus de temps à faire une dal etc etc...

---

Il ne faut pas tout confondre. Tu peux très bien utiliser une ObjectDataSource en spécifiant les méthodes CRUD à utiliser et cette ObjectDataSource se charge d'appeler ta BLL ( et non pas ta DAL, ie on appelle depuis l'UI la couche Business Logic qui elle appelle la couche Data Access).