Frage

Wenn ich den folgenden Code verwenden, verliere ich die Möglichkeit, auf Variablen im Code klicken, um direkt hinter und Refactoring (umbenennen in diesem Fall) sie

<a href='<%# "/Admin/Content/EditResource.aspx?ResourceId=" + Eval("Id").ToString() %>'>Edit</a>

Ich sehe diese überall Praxis aber es scheint mich seltsam, wie ich nicht mehr in der Lage ist zu bekommen Zeitfehler kompilieren, wenn ich die Eigenschaftsnamen ändern. Mein bevorzugter Ansatz ist, so etwas zu tun

<a runat="server" id="MyLink">Edit</a>

und dann in dem Code hinter

MyLink.Href= "/Admin/Content/EditResource.aspx?ResourceId=" + myObject.Id;

Ich bin wirklich interessiert, wenn die Leute denn das ist der obige Ansatz ist besser denken zu hören, was ich sehe immer auf populäre Codierung Websites und Blogs (zB Scott Guthrie) und es ist kleiner Code, aber ich neige dazu, ASP.NET, weil es zu benutzen kompilierte und zu wissen, es vorziehen, wenn etwas bei der Kompilierung gebrochen ist, nicht an der Zeit ausgeführt werden.

War es hilfreich?

Lösung

Ich werde nicht nenne es schlechte Praxis (manche würden nicht einverstanden ist, aber warum haben sie uns diese Option in erster Linie?), Aber ich würde sagen, dass Sie allgemeine Lesbarkeit verbessern würden und Wartbarkeit, wenn Sie auf diese Praxis nicht einreichen . Sie vermittelt bereits einen guten Punkt aus, und das ist IDE-Funktion Begrenzung (das heißt, Entwurfszeit-Inspektion, Kompilierung Warnung, usw.).

könnte ich weiter und weiter gehen, wie viele Prinzipien, die sie verletzt (Code-Wiederverwendung, Trennung von Bedenken, etc.), aber ich kann viele Anwendungen denken gibt, die fast jedes Prinzip brechen, aber noch nach mehreren Jahren arbeitet. Ich für meinen Teil ziehe meinen Code als modulare und wartbare wie möglich zu machen.

Andere Tipps

Es ist, als Spaghetti-Code bekannt, und viele Programmierer finden es anstößig ... dann wieder, wenn Sie und die anderen Entwickler in Ihrem Unternehmen lesbar und wartbar finden, wer bin ich, Ihnen zu sagen, was zu tun ist.

Für Sie sicher, obwohl die Verwendung beinhaltet Redundanz zu reduzieren (DRY - nicht selbst wiederholen)

Ich benutze es nur gelegentlich und in der Regel aus bestimmten Gründen. Ich werde immer ein glücklicher Entwickler mit meinem Code vollständig von meinem HTML-Markup getrennt werden. Es ist ein wenig eine persönliche Präferenz, aber ich würde sagen, dass dies eine bessere Praxis.

Es ist bis zu Ihnen. Manchmal ist „Spagehetti“ Code leichter zu pflegen als der Bau / Verwendung eines Voll auf Template-System für etwas einfach, aber wenn man ziemlich komplizierte Seiten bekommen, oder genauer gesagt, sobald Sie anfangen, viel Logik in die Seite, einschließlich sich selbst, kann es bekommen wirklich schnell schmutzig.

Ich denke, es ist interessant, dass mehr asp.net Code in den aspx Seiten ist erforderlich. Die Listenansicht in 3,5, und auch die ASP.NET MVC. Die MVC hat im Grunde keinen Code hinter, aber Code auf den Seiten Informationen zu machen.

Wenn Sie es in Bezug auf die Template-Entwicklung denken, dann ist es ratsam, sie im Auge zu behalten, und nicht in der Code-behind. Was passiert, wenn bei Bedarf von einem Anker auf ein Listenelement mit unaufdringlich JS zu ändern, um einen Klick zu behandeln? Ja, das ist nicht das beste Beispiel, und nicht nur das, und Beispiel.

Ich versuche immer, in Bezug auf die zu denken, wenn ich einen Designer hatte (HTML, CSS, alles), was hätte ich ihm tun, und was würde ich hinter im Code tun, und wie treten wir nicht gegenseitig auf die Zehen.

Es ist nur eine schlechte Praxis, wenn Sie es gut nicht einkapseln können.

Wie alles andere, können Sie böse, unleserlich Spaghetti-Code erstellen, außer Sie jetzt Tags haben mit zum Inhalt, die durch Design sind nicht die lesbar Dinge in der Welt.

Ich versuche, und halte Tonnen, wenn die aus hte-Vorlage, aber übermäßiger Verkapselung führen in 13 diferent Orten suchen zu müssen, um zu sehen, warum div x nicht an den Client feuert, so dass sie ein Trade-off.

Es ist nicht, aber manchmal ist es ein notwendiges Übel.

Nehmen Sie Ihren Fall für ein Beispiel, wenn auch hinter Code scheint eine bessere Trennung von Sorge zu haben, aber das Problem mit ihm ist, dass es nicht die Bedenken trennen kann so klar wie Sie es wünschen. Normalerweise, wenn wir den Code hinter Sachen tun wir nicht bauen die Anwendungen in MVC-Framework. Der Code hinter Code ist auch nicht einfach irgendwie zu halten und zu testen, zumindest wenn Vergleich zu MVC.

Wenn Sie bauen ASP.NET MVC-Anwendungen dann denke ich, Sie sicherlich mit Inline-Code stecken. Aber Gebäude in MVC-Muster ist die beste Art und Weise in Bezug auf die Wartbarkeit zu gehen über und Testbarkeit.

Um es zusammenzufassen: Inline-Code keine gute Praxis ist, aber es ist ein notwendiges Übel.

Meine 2cents.

Normalerweise verwende ich wie auf diese Weise.

<a href='<%# DataBinder.Eval(Container.DataItem,"Id",""/Admin/Content/EditResource.aspx?ResourceId={0}") %'>
Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top