aspx 页面中的内联代码是一个好的做法吗？

题

如果我使用以下代码，我将无法右键单击后面代码中的变量并重构（在本例中重命名）它们

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

我到处都看到这种做法，但对我来说这似乎很奇怪，因为如果更改属性名称，我将不再能够得到编译时错误。我首选的方法是做这样的事情

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

然后在后面的代码中

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

我真的很想知道人们是否认为上述方法更好，因为这是我总是在流行的编码网站和博客上看到的（例如Scott Guthrie），它的代码较小，但我倾向于使用 ASP.NET，因为它是编译过的，并且更喜欢在编译时（而不是运行时）知道某些内容是否损坏。

解决方案

我不会称其为不好的做法（有些人会不同意，但为什么他们首先给我们这个选择？），但我想说，如果您不遵守这种做法，您将提高整体可读性和可维护性。您已经表达了一个很好的观点，那就是 IDE 功能限制（即设计时检查、编译时警告等）。

我可以继续谈论它违反了多少原则（代码重用、关注点分离等），但我可以想到许多应用程序几乎打破了所有原则，但几年后仍然可以工作。我个人更喜欢使我的代码尽可能模块化和可维护。

其他提示

它被称为意大利面条代码，许多程序员发现它令人反感......话又说回来，如果您和公司的其他开发人员发现它可读且可维护，我有什么资格告诉您该怎么做。

但可以肯定的是，使用包含来减少冗余（DRY - 不要重复自己）

我只是偶尔使用它，并且通常是出于某些特定原因。当我的代码与 HTML 标记完全分离时，我将永远是一个更快乐的开发人员。这在某种程度上是个人喜好，但我想说这是更好的做法。

由你决定。有时，“spagehetti”代码比为简单的事情构建/使用完整的模板系统更容易维护，但是一旦您获得相当复杂的页面，或者更具体地说，一旦您开始在页面本身中包含大量逻辑，它就会变得脏得很快。

我认为有趣的是，越来越多的 ASP.NET 需要在 aspx 页面中编写代码。3.5 中的 listview，甚至 ASP.NET MVC。MVC基本上没有后台代码，而是在页面中渲染信息的代码。

如果您从模板开发的角度考虑它，那么明智的做法是将其保留在视图中，而不是保留在后面的代码中。如果需要使用不显眼的 JS 将锚点更改为列表项来处理点击怎么办？是的，这不是最好的例子，而只是一个例子。

我总是尝试思考如果我有一个设计师（HTML，CSS，任何东西），我会让他做什么，我会在后面的代码中做什么，以及我们如何不踩到彼此的脚趾。

如果你不能很好地封装它，这只是一个不好的做法。

与其他所有事情一样，您可以创建令人讨厌的、不可读的意大利面条式代码，但现在您需要满足于标签，而从设计上来说，这些标签并不是世界上最易读的东西。

我尝试将大量 if 保留在 hte 模板之外，但过度封装导致必须查看 13 个不同的位置才能了解为什么 div x 没有向客户端触发，因此这是一种权衡。

事实并非如此，但有时这是一种必要的罪恶。

以您的情况为例，虽然代码隐藏似乎有更好的关注点分离，但它的问题是它可能无法像您希望的那样清晰地分离关注点。通常，当我们编写后台代码时，我们不会在 MVC 框架中构建应用程序。无论如何，代码背后的代码也不容易维护和测试，至少与 MVC 相比是这样。

如果您正在构建 ASP.NET MVC 应用程序，那么我认为您肯定会陷入内联代码的困境。但就可维护性和可测试性而言，构建 MVC 模式是最好的方法。

合计：内联代码不是一个好的做法，但却是一种必要的罪恶。

我的2美分。

通常我这样使用。

<a href='<%# DataBinder.Eval(Container.DataItem,"Id",""/Admin/Content/EditResource.aspx?ResourceId={0}") %'>

许可以下： CC-BY-SA 和归因