Le moteur de vue ASP.NET MVC Spark pour les concepteurs, l’aime-t-il?

Question

Je suis en train de construire un grand projet Mvc asp.net et j'ai une question à propos du moteur de rendu par défaut opposé au moteur MVC Spark dans le contexte des concepteurs.

Je suis tout à fait en faveur de la réduction de ma soupe d'étiquettes et je peux voir que le moteur à étincelles est soigné, très soigné et que je l'aurais bien accueilli. Cependant, est-ce que quelqu'un a une expérience / des opinions quant à savoir si son équipe de conception l'a adoptée ou si elle s'y est opposée?

Mon équipe de concepteurs n'a pas encore développé à l'aide du framework Mvc. Ils doivent donc apprendre le moteur par défaut ou le moteur à étincelles.

Quelqu'un peut-il commenter?

Answer 1

Votre équipe de conception ne devrait avoir aucune connaissance du moteur de vue. Ils doivent uniquement connaître le produit final à partir du moteur de visualisation (à savoir le code HTML, CSS et Javascript généré).

Vos concepteurs peuvent créer des modèles à partir de HTML et de CSS simples, sans jamais voir une seule ligne de code de moteur de rendu. Il vous suffit de leur indiquer les emplacements dans le modèle où vous allez injecter le contenu.

L’intérêt des modèles CSS / HTML est de séparer le concepteur du développeur. Cela permet à ces modèles d'être transformés en un atelier de design. Vous ne voulez pas que le magasin de design se mêle de votre code de développement.

Le concepteur vous fournira également un ensemble de styles de texte: h1, h2, h3, p, etc. Vous pourrez intégrer ces styles partout où vous en aurez besoin dans le code de gabarit du moteur de rendu pour obtenir les effets souhaités. Si vous le souhaitez, vous pouvez laisser le concepteur dicter des règles relatives à la mise en page et à l'utilisation de ces styles, mais votre travail consiste toujours à écrire le code qui restitue la sortie dans le modèle de concepteur.

Pour que tout soit clair, le travail du concepteur consiste à vous créer un modèle HTML / CSS (avec un exemple de contenu et un style permettant à tous les deux de voir correctement la mise en page). Votre travail consiste à incorporer le code CSS / HTML fourni par le concepteur au code du moteur de visualisation.

Spark n’est qu’une version HTML de C # (ou VB). Toutes choses étant égales par ailleurs, Spark serait plus facile pour un concepteur, car il modifie toutes les <% { %> choses en équivalents HTML. Mais cela suppose que les concepteurs vont écrire le code de gabarit pour le moteur de vue, ce qu'ils ne seront pas.

Answer 2

Je sais que cette question est considérée comme une "réponse", mais laissez-moi répondre du point de vue du "concepteur" (nous l'appelons développeur front-end).

Nous avons une équipe back-end (C #) et une équipe front-end (HTML / CSS / Javascript) qui fonctionnent sur les applications .NET MVC. Spark est un moyen beaucoup plus naturel de créer des vues HTML. Sparks ajoute un moyen naturel de faire des ifs et des boucles en ajoutant des instructions 'if' et 'each' en tant qu'attributs de l'élément HTML au lieu de boucles en dehors des balises HTML dans & Lt;%% & Gt; Mots clés. Les partiels sont également appelés de manière intuitive. < tableau de bord / > inclura le " _dashboard.spark ".

Spark fait en sorte que tout le balisage de View ressemble au HTML, ce qui, à mon avis, est très important pour la maintenabilité. Cela oblige également à adopter de bonnes habitudes MVC en conservant le plus de logique possible dans le balisage View. L’équipe de conception et le balisage HTML permettent aux développeurs d’ajouter un peu de logique pour lancer la génération de contenu.

Avec Spark, nous avons minimisé le problème du code laid et avons maintenu le travail frontal et final séparé, tout en restant fluide et maintenable.

Answer 3

Je ne pense pas que le designer aime utiliser Spark. Il est trop compliqué d’utiliser et de mélanger une logique, une définition de variable. Le concepteur ne doit connaître aucun langage de programmation. Je préfère utiliser Velocity View Engine (VTL). C’est simplement utiliser et peut forcer le programmeur à séparer la logique du front-end.