在Web应用程序中，在代码中使用HTML（非脚本语言，Java，.NET）是否可以接受？
有两个主要的子问题：
答案 0 :(得分：13)
通常，最好将表示（HTML）与逻辑（“后端”代码）分开。您的代码是分离的，并且更容易以这种方式维护。
答案 1 :(得分：5)
只要您的HTML编写代码与您的应用程序逻辑分开，并且HTML保证以某种方式构建良好，您应该没问题。
应该在基于标记的页面中混合的唯一代码（即包含文字HTML的代码）是用于格式化HTML的代码（例如，用于写出列表的循环）。
无论是使用HTML编写代码还是使用纯代码使用带引号的字符串文字来编写HTML，都需要权衡。
答案 2 :(得分：1)
不，如果您想构建良好且可维护的软件，并实现松耦合。
答案 3 :(得分：1)
如果我理解正确的问题，那么你会问，将标记与后端代码混合是否是一种好习惯。不会。虽然这种做法很常见，但这仍然是一个坏主意。
您应该阅读MVC范例，以及有关此问题的现有问题，例如What is the best way to migrate an existing messy webapp to elegant MVC?和Best practices for refactoring classic ASP?
答案 4 :(得分：1)
重点是保持显示逻辑与其余代码分开。在任何复杂的站点中，您都会将代码与HTML混合在一起，但代码应仅用于显示目的。它不应该进行任何复杂的计算。
例如，模板将包含循环和条件。另外，您可能会拥有一个特定于HTML的例程库，例如打印出＆lt;选项＆gt;列表基于列表对象。
想象一下，您正在编写一个具有两种输出模式的应用程序：HTML和其他东西。你会怎么写它，以避免重复代码？这可能会指出你正确的方向。
答案 5 :(得分：1)
构成视图的HTML必须以某种方式发送到浏览器。在.net中，每个服务器控件都会在页面生命周期中发出自己的HTML标记。所以是的，可以在服务器端代码中使用HTML。
也许您应该尝试遵循ASP.net模式。创建一组代表UI元素的控件，并使它们负责根据状态发出自己的HTML。
答案 6 :(得分：0)
它很脏，而不是类型安全。但是人们没有后果就做到了。我更喜欢使用DOM，或者至少使用类型安全语义来编写HTML的类。此外，将UI与逻辑混合起来并不是那么好......
答案 7 :(得分：0)
如果我需要生成HTML的方法，我通常会将它们隔离在HtmlHelpers类中。这样你就可以保持一些级别的分离。 ASP.NET MVC框架非常成功。
答案 8 :(得分：0)
如果您的意思是在代码中打印HTML，那么没有。除非你有充分理由不这样做，否则你应该使用templates
即使你认为你现在不需要这个，你总是很有可能在以后需要它。也许您希望以不同于HTML的格式输出，或者您希望对相同数据进行不同的显示。你通常需要将这些东西放在路上，所以最好从一开始就使用它。
答案 9 :(得分：0)
我讨厌开发人员打印（）一堆html。在任何以红色显示打印/回显字符串的文本编辑器中，这都是完全没必要的，看起来很丑陋。
答案 10 :(得分：0)
我同意其他人的意见，你应该尽可能努力地将HTML / XHTML标记与应用程序逻辑分开。但是，有时您需要在应用程序逻辑中生成HTML / XHTML，原因有多种。
在这些情况下，我一直在努力确保将最少量的表示代码与应用程序逻辑混合在一起，并尝试将其他所有内容迁移到表示代码中。在某些情况下，您可以将所有内容都移到表示层，这是值得的，但是将标记生成为应用程序逻辑的一部分可能会更容易一些。在这些情况下，你最好的选择可能就是在时间上最有意义的路线。
答案 11 :(得分：0)
我认为在您的业务逻辑中生成HTML没有任何借口。当它只是一个“快速修复”或者“稍后再回来修复”时，甚至不要这样做，因为这种情况从未发生过。
重申我对其他问题的立场，在HTML中使用一些控制逻辑（条件，循环）来构造它是可以的。不要在HTML中执行任何数据按摩或业务逻辑。你必须受到纪律处分，但这是值得的。如果你的顾虑（如逻辑和显示）分开，维护会更容易。
答案 12 :(得分：0)
理想情况下，您的目标是在演示文稿（UI）代码和域（业务逻辑）代码之间分离关注点。
你应该避免将这两个问题（在任何一个方向上）联系起来的原因很简单......
您只需要一个理由来更改一段代码。无论是来自html设计中的结构/样式更改，还是来自业务规则的更改，您只需要在一个地方进行更改。
在较小的程度上，虽然许多纯粹主义者不同意，但通过域代码中的HTML代码或反之亦然，您会为下一个阅读/维护它的开发人员创建噪音。
答案 13 :(得分：0)