8

在 Web 应用程序中,是否可以在代码中使用 HTML(非脚本语言、Java、.NET)?

有两个主要的子问题:

  1. 您应该使用代码来打印 HTML,还是直接创建显示的 HTML?
  2. 您应该在 HTML 页面中混合代码吗?
4

14 回答 14

14

通常,最好将演示文稿 (HTML) 与逻辑(“后端”代码)分开。您的代码以这种方式解耦并且更易于维护。

于 2008-09-15T17:07:38.780 回答
5

只要您的 HTML 编写代码与您的应用程序逻辑是分开的,并且可以保证 HTML 以某种方式格式正确,那么您应该没问题。

唯一应该在基于标记的页面(即包含文字 HTML 的页面)中混合的代码是用于格式化 HTML 的代码(例如,用于写出列表的循环)。

无论是将代码与 HTML 一起放入,还是使用纯代码使用带引号的字符串文字将 HTML 写出,都需要权衡取舍。

于 2008-09-15T17:09:01.180 回答
1

不,如果您想构建良好且可维护的软件,并实现松散耦合。

于 2008-09-15T17:09:19.103 回答
1

如果我正确理解了这个问题,那么您是在问将标记与后端代码混合是否是一种好习惯。不。虽然这很常见,但这仍然是一个坏主意。

您应该阅读MVC范式以及有关此问题的现有问题,例如将现有凌乱的 web 应用程序迁移到优雅的 MVC 的最佳方法是什么?重构经典 ASP 的最佳实践?

于 2008-09-15T17:13:09.610 回答
1

关键是将显示逻辑与其余代码分开。在任何复杂的站点中,您都会将代码与 HTML 混合在一起,但代码应仅用于显示目的。它不应该进行任何复杂的计算。

例如,模板将包含循环和条件。另外,您可能会拥有一个特定于 HTML 的例程库,例如基于列表对象打印出 <option> 列表。

想象一下,您正在编写一个具有两种输出模式的应用程序:HTML 和其他模式。您将如何编写它,以避免重复代码?这可能会为您指明正确的方向。

于 2008-09-15T17:16:05.437 回答
1

构成视图的 HTML 必须以某种方式发送到浏览器。在 .net 中,每个服务器控件都会发出自己的 HTML 标记作为页面生命周期的一部分。所以是的,在服务器端代码中使用 HTML 是可以的。

也许您应该尝试遵循 ASP.net 模式。创建一堆代表 UI 元素的控件,并让它们负责根据它们的状态发出自己的 HTML。

于 2008-09-15T17:19:32.900 回答
0

它的丑陋,而且不是类型安全的。但人们这样做没有任何后果。我更喜欢使用 DOM,或者至少使用旨在使用类型安全语义编写 HTML 的类。此外,将 UI 与逻辑混合并不是那么好......

于 2008-09-15T17:08:09.730 回答
0

如果我需要生成 HTML 的方法,我通常将它们隔离在 HtmlHelpers 类中。这样你就可以保持一定程度的分离。ASP.NET MVC 框架非常成功地做到了这一点。

于 2008-09-15T17:11:58.443 回答
0

如果您的意思是在代码中打印出 HTML,那么不会。除非您有充分的理由不这样做,否则您应该使用模板

即使你认为你现在不需要它,你也很有可能以后需要它。也许您希望以不同于 HTML 的格式输出,或者您希望对相同的数据进行不同的表示。您通常会在以后需要这些东西,因此最好从一开始就使用这些东西。

于 2008-09-15T17:14:15.037 回答
0

我讨厌开发人员 print() 一堆 html。在任何以红色显示打印/回显字符串的文本编辑器中,这完全没有必要并且看起来很丑陋。

于 2008-09-15T17:16:53.530 回答
0

我同意其他所有人的观点,即您应该尽可能努力地将 HTML/XHTML 标记与应用程序逻辑分开。但是,有时出于各种原因,您确实需要在应用程序逻辑中生成 HTML/XHTML。

在这些情况下,我一直在尝试做的是确保将最少量的演示代码与应用程序逻辑混合,并尝试将其他所有内容迁移到演示代码中。毫无价值的是,在某些情况下,您可以将所有内容都移至表示层,但生成标记作为应用程序逻辑的一部分可能会更容易一些。在这些情况下,您最好的选择可能是走在时间上最有意义的路线。

于 2008-09-15T17:25:02.997 回答
0

我认为在业务逻辑中生成 HTML 没有任何借口。当它只是一个“快速修复”或者当你“稍后再修复它”时,甚至不要这样做,因为这永远不会发生。

从其他问题重申我的立场,在 HTML 中使用一些控制逻辑(条件、循环)来构造它是可以的。不要在 HTML 中进行任何数据按摩或业务逻辑。你必须遵守纪律,但这是值得的。如果您的关注点(如逻辑和显示)分开,维护会容易得多。

于 2008-09-15T17:29:14.470 回答
0

理想情况下,您的目标是在演示 (UI) 代码和域(业务逻辑)代码之间分离关注点。

您应该避免耦合这两个问题(在任一方向)的原因很简单......

您将只有一个理由更改一段代码。无论是您的 html 设计中的结构/样式更改,还是您的业务规则更改,您都应该只需要在一个地方进行更改。

To a lesser extent, although many purists would disagree, by sprinkling HTML code through your domain code or vice versa you are creating noise for the next developer who comes along to read/maintain it.

于 2008-09-15T17:49:23.237 回答
0
  1. I try to avoid using code to print HTML "directly". It is difficult to maintain, edit, add styles and etc. Some cases like generating an HTML email in the code, I create a text file or HTML file with markers like, [name], [verification code] and etc. I load this from the code and replace those markers. This way, you can edit the style of the email without re-compiling your code. Separating "presentation" and "logic" is a good practice in my opinion.
  2. Mixing code within HTML is generally not a good practice in similar reasons as said in #1. However, I do use code in HTML for things like simple dynamic strings that are displayed multiple times on a page or pages. I think this is better than creating multiple server controls for same exact values to set. Since this is not code "logic" mixed in the HTML, I think this is ok.
于 2008-09-15T18:19:02.180 回答