2009-06-12 4 views
0

J'ai lu quelques articles de blog et des didacticiels présentant le mélange de jQuery et des éléments d'interface utilisateur pour Views dans une application Web .NET MVC. Mais généralement ciblé sur les développeurs avec une compréhension globale du cycle de développement complet et des variations des technologies back/middle tier. En tant que développeur front-end, je propose une interface utilisateur jQuery uniquement pour le développement back-end, il met en garde contre une interface non-webforms pour le pov de maturité du code.Alimentation .NET MVC Affichage de la façon d'utiliser l'interface utilisateur jQuery

J'essaie de répondre avec "bien ... c'est votre modèle ... n'est-ce pas élémentaire à MVC? Pas de logique dans la vue? Je suis en train de lire que ce sont des trucs côté serveur Vous ne faites que sérialiser les propriétés que je demande, ou mieux ... laissez-moi facilement découvrir ce que vous pouvez m'envoyer ... je vais pouvoir implémenter l'interface utilisateur via l'interface utilisateur jQuery.

Alors, quelle est ma position?

La grille de jQuery peut-elle gérer au moins les 85% inférieurs du contrôle natif de .net (nombre de lignes faible à modéré)?

Qu'en est-il de l'édition en ligne? ... de la grille?

Travailler exclusivement dans les services Web simplifierait-il sa vie? et si oui, cela ne serait-il pas logique de construire une relation .net-to-jQuery? - ajax liaison twixt serveur (méthodes .net WS) et client?

MNY thx --Steve ...

Répondre

0

Si cela est une interface d'administration, et le client a accepté que les utilisateurs Javascript doit être activé alors je pense à l'aide de JavaScript pour créer des widgets sur la page est une meilleure option que d'utiliser les contrôles du serveur asp.net. Si toutefois il s'agit d'un site Web public, je dirais qu'une approche purement html et css est beaucoup mieux, puis utiliser javascript pour améliorer progressivement la page!

Maintenant, je ne préconise jamais l'utilisation de contrôles de serveur asp.net, car ils crachent hors balisage pauvres et ils sont trop compliqués à utiliser. Au lieu de cela, j'ai utilisé jQuery pour faire le travail de grognement et l'interrogation dom et la traversée. Je ne recommande pas d'utiliser jQuery UI car il manque des widgets très essentiels, par exemple pas de datatable, pas de treeview etc. Je sais qu'il y a beaucoup de plugins pour jQuery mais ils ne sont pas composants et donc chaque plugin doit réinventer la roue réaliser tout ce dont il a besoin. Une fois que vous avez inclus toutes vos bibliothèques de plugins et CSS, vous vous retrouvez souvent avec une très grande empreinte de page. De plus, chaque plugin a souvent une page d'accueil différente et une documentation qui peut être ou ne pas être à la hauteur.

Je pense que la meilleure bibliothèque d'interface utilisateur est YUI, et vous pouvez facilement le combiner avec jQuery. Parce que chaque widget est composé de composants de base, le poids total du téléchargement est plus petit. Aussi vous avez toute la documentation en un seul endroit avec 100 d'exemples de travail. Cela signifie également travailler avec le même ensemble de modèles javascript à travers le tableau, donc avec chaque widget, vous en apprendrez de plus en plus sur la bibliothèque. J'espère que jQuery UI rattrapera, mais personnellement, je suis impatient de YUI 3 qui, pour moi, pourrait signifier tomber jQuery tout à fait ...

+0

Considérez-vous qu'il s'agit d'un problème de «maturité du code»? L'empreinte de la taille semble considérable, mais sacrément ces sélecteurs et comment il s'intègre bien avec le travail de la CSS semble difficile à discuter. Mais le vôtre est irrésistible. – justSteve

+0

Lire jQuery en action (Si ce n'est pas déjà fait) C'est un livre fantastique, c'est l'un des meilleurs livres techniques que j'ai jamais lus et si bien écrits. J'ai arrêté d'utiliser asp.net classic il y a plus d'un an et je n'ai jamais regardé en arrière. Il y a tellement de choses qui ne vont pas avec le classique. ViewState - horrible (juste le faire sur le serveur avec memcached ou un cache DB). Sortie html brute - dégoûtant. Abstractions dans vos vues - architecture trop compliquée Astronautisme: P Gross Leaky Abstractions sucent dur. – superlogical

2

Ne pas combattre la plate-forme. De cette façon, il y a la douleur et la souffrance.

Les objets de vue MVC sont très différents des formulaires web asp.net avec des contrôles serveur - vous obtenez directement html. Vous obtenez jquery et ajax essentiellement gratuitement, avec (presque) le traitement d'appel ajax côté serveur magique.

Ils sont conçus pour faire ce que vous demandez. Écrire votre propre jquery ui réinvente la roue.

Non seulement ce serait une tonne de travail supplémentaire pour aucun gain. Vous seriez le seul développeur à essayer de le faire, et quand vous aviez besoin d'aide, peu d'entre vous pouvaient donner des conseils.

0

jQuery est une bibliothèque très mature. Il est utilisé par des milliers de personnes sur Internet, et je ne pense pas avoir jamais rencontré un bug. YUI est dogfooded par YAHOO ainsi lui aussi est durci au combat. Une chose que je n'ai pas mentionnée est que j'utilise le moteur de vue webforms par défaut avec asp.net mvc. Je pense que c'est toujours la meilleure option lorsque vous obtenez intellisense et Resharper refactoring recherche même vos vues, et la solution statique anaylsis peut trouver des erreurs de code dans vos vues.

Pour la construction de mon balisage, j'ai utilisé MvcContrib Fluent Html mais vous pouvez également consulter le this article qui a très bien défendu le principe DRY.

Questions connexes