此代码是否被视为不好的做法：

这是我工作过的一个小Web应用的default.aspx中的一段代码。它工作得很好，运行得很快，但和往常一样，我意识到，仅仅因为它工作，并不意味着它是好的。

基本上，displaymeetings子例程输出一组格式化的HTML(实际上是无序的列表)，没有格式化，只有必需的HTML，然后我的CSS执行所有必需的格式化。

用于生成列表的数据来自SQL Server数据库(参数控制返回的行数)，我使用存储过程和DataReader进行快速访问。这使我的前端非常简单和干净，imho，并让我在一个单独的模块中用vb或c完成所有工作。

当然，我可以使用数据绑定中继器(可能还有6种或更多其他方法)来完成相同的任务，但是它们是否更好呢？除了失去VS2010的设计时功能之外？

这不是我愿意做的事。我不喜欢在网络表单中使用<%= %>。可悲的是，这也是常见的做法。

我可能要做的是构建一个用户控件来表示我想要的标记并将其放到表单上。这样做的好处是使元素更加可重用、可测试，并使您能够更好地控制在页面生命周期中调用代码的位置。

你的方法唯一"错误"的地方是它混合了代码和显示，你通常希望尽可能避免这种情况。如果必须有一个按程序生成的HTML部分(因为它很难处理控件或其他内容)，请创建一个负责生成该HTML的控件，并将其嵌入包含该HTML的较大页面/控件中。

is the"wrong" part, that the subroutine is returning HTML, or is it that I have a code-snippet executed from within the HTML markup?

在某种程度上，两者都是。也不是。

使用<%= foo %>没有直接的"错误"；如果有，它就不会是框架的一部分。它的"错误"在于它建立了一个双向的依赖关系，而您不一定想要它。您的HTML标记依赖于并且必须了解代码隐藏。它必须调用方法，而该方法又专门用于标记，而不是其他任何方法。如果要更改输出，可能需要更改方法、标记或两者都更改。

我想说的是，您所做的工作会降低代码的可维护性，降低下次打开引擎盖时修改代码的灵活性。

如果这是解决问题的唯一方法，那么这是唯一的方法，并且没有任何问题。但如果可能的话，一般来说，这是应该避免的事情。

我该怎么做？坦率地说，这取决于具体情况。如果我可以使用数据绑定的标准组件，我会这样做的。这是最好的选择。如果HTML太复杂而无法使用组件，我将使用文本控件作为标记的占位符，并在单独的组件(可能是用户控件)中生成标记。

关键是，标记对用于生成其他标记的方法一无所知，它只是说"这里有东西"，并依赖其代码来处理决定将哪个标记放入其中。

数据绑定中继器可以使您在需要更改布局时修改HTML变得更简单。如果您有单独的HTML工作人员和服务器端代码工作人员，这也很好。

我通常的规则是对任何稍微复杂的HTML使用转发器。我不从我的aspx/ascx文件调用方法-我只插入我在代码中填充的受保护字符串变量的值。然而，这些都是个人偏好，我看不出你所做的有什么真正的错误。

您的代码(看不见)可能比中继器快，因为没有涉及数据绑定，但除非页面非常、非常流行，否则它可能不是一件大事。