2009-04-08 17 views
28

Ich verstehe den Grund für die HTML-Helfer in ASP.NET MVC und erweitern, um Ihre eigenen zu bieten, aber ich frage mich, ob die Verwendung von HTML-Helfern eine gute Idee ist.ASP MVC HTML-Helfer - gut oder schlecht?

Ich dachte, einer der Vorteile von ASP.NET MVC ist die Kontrolle über das HTML. Wenn Sie anfangen, es in Hilfsfunktionen zu verstecken, die HTML generieren, verlieren Sie nicht die Sichtbarkeit? Ich denke, das ist kein Problem, wenn Sie einfache Steuerelemente wie eine Schaltfläche generieren, aber ich habe die Verwendung von HTML-Helfern gesehen, um Raster und komplexere HTML-Ausgaben zu erstellen.

Jetzt verstehe ich auch den Grund dafür ist, die Dinge trocken zu halten, Vermeidung von Doppelarbeit. Aber besteht hier nicht die Gefahr, dass Code-Behind etwas mit sich bringt? Und was ist, wenn Sie mit Designern zusammenarbeiten? Im Allgemeinen erstellt der Designer das Markup und das Anwenden von Styling. Wenn Sie beginnen, Ihre Ansicht mit Helfern zu versehen, die Markup generieren, erschwert dies nicht die Zusammenarbeit?

+0

Nein. Solange Helfer nicht gegen die Bedenken von MVC verstoßen, das heißt, sie tun etwas, das keine Präsentationslogik ist, dann ist nichts falsch an ihnen. Ja, einige komplexe Helfer könnten tatsächlich die Trennung von Bedenken verletzen, aber das ist wirklich ein anderes Argument, ob die Helfer selbst gut oder schlecht sind. –

Antwort

14

"Kontrolle über die HTML" ist Microsoft Marketing-sprechen, und ist, wie sie die Marke zu brandmarken wählen. Der Sinn von ASP.net MVC ist, dass es einfacher und besser für Webapps geeignet ist als das gesamte Stateful-Event-gesteuerte Modell von Webforms, und etwas, das so ziemlich jeder außerhalb des Microsoft-Bereichs vor Jahren bewegte. Microsoft kann das jedoch nicht sagen, weil sie sehr viel in Webformulare investieren und es ein wichtiger Teil ihrer Unternehmensgeschichte ist.

Das gesagt, wenn Sie Geschäftslogik in Ihren Helfern haben, verwenden Sie sie falsch. Es ist im Grunde Code nur für Präsentationslogik, die über mehrere Seiten dupliziert wird, und das Ziel ist es, Scriptlet-Tags im Markup so einfach wie möglich zu halten.

Solange Sie die Helfer so verwenden, wie sie verwendet werden sollten, sollte es für die Konstrukteure ziemlich trivial sein zu lernen, wie man sie benutzt. Denken Sie daran, dass es das Ziel ist, die Dinge einfach zu halten, wenn sie die Dinge komplizierter machen, das bedeutet, dass sie nicht richtig verwendet werden.

9

Großer Kommentar, Matt. Es bleibt die Frage, ob HTML-Helfer in einer "reinen" MVC-Implementierung eine gute Idee sind. Ich denke, das ist das Zauberwort "rein". Immer wenn ich langsamer werde, um über den "richtigen" Weg nachzudenken, versuche ich wirklich zu sehen, ob ein bestimmter Ansatz zu der Vision des Puristen passt. Würde ein Purist HTML-Helfer benutzen?

Ich bin über 8/10 puristisch und ich würde sie nicht verwenden. Ich habe gesehen, dass dieses Argument die Technologie transzendiert und das Problem mit MVC in PHP und dem Zend-Framework aufgeworfen hat. Es fühlt sich einfach nicht richtig an und für mich ist das die beste Maßnahme, die man sich vorstellen kann.

+1

Im MVC-Muster gibt es nichts, das besagt, dass Sie keine Hilfsfunktion zum Generieren von Vorlagenauszeichnungscode verwenden können. MVC spricht nur über die Trennung von Bedenken. Solange Ihre Hilfsfunktionen nicht die Grenzen von Bedenken verletzen, hat MVC nichts darüber zu sagen. Ein solcher "reiner" MVC kommt aus einem streng musterhaften Blickwinkel nicht in Betracht, da es nichts gibt, was sich mit irgendeinem der Aspekte von MVC befasst. Diese Helfer sind nur ein Merkmal der Ansicht (das V in MVC). –

3

Es ist definitiv nichts falsch mit den Helfern. Sie werden verwendet, um Ihre Ansichten sauber und deklarativ zu halten. Es gibt ein Sprichwort, das so etwas wie "Wenn es ein" if "Statement aus deiner Sicht gibt, machst du es falsch". Sie werden in vielen bekannten MVC-Frameworks wie Ruby On Rails und Cake PHP verwendet. Schauen Sie sich this post an. "Puristisch" oder nicht, Helfer sind eine gute Sache und nicht mit schlechter Übung oder undichten Abstraktionen zu verwechseln.

1

Ich denke, ein wichtiger Punkt, den die anderen nicht erwähnt haben, ist die Portabilität Ihrer Ansichten.

Sie können Ihr HTML, JavaScript und CSS sofort in eine Anwendung auf einer anderen Plattform verschieben. Sie müssen nicht alle hässlichen HTMLHider konvertieren .. Entschuldigung, HTMLHelpers .. zu tatsächlichen HTML.

Während ich das .NET-Framework, das meine Entwicklungszeit reduziert und meine Arbeit erleichtert, am meisten schätze, bin ich der festen Überzeugung, dass Ansichten nicht-proprietär sein sollten.

Sie können den Rahmen des Modells und des Controllers trotzdem fast vollständig nutzen. Das Einbetten von Abhängigkeiten vom Framework in Ihrer Präsentationsebene ist den Kompromiss, IMO, nicht wert.

Verwandte Themen