C# 为什么要内联使用C代码？

有一次我在采访中被问到“在aspx页面内联使用C代码的原因是什么”。我无法回答，所以我很好奇。为什么要这样做而不是使用代码隐藏？有技术上的原因吗？

我会用刻板的“视情况而定”来回答

如果是纯视图问题，我会编写内联C#（并且经常这样做）。 MVC应用程序的常见模式是在视图中使用简单的C#来完成复杂的显示相关工作

如果所讨论的代码严格地与将数据呈现到页面上相关，那么内联C#很可能是最简单、最简单的解决方案（除非您使用WebForms，其中没有简单的东西）。如果代码与渲染数据没有严格的关系，我会将渲染部分与处理部分分开，只在视图中使用渲染代码。

对于ASP.NET WebForms 通常不建议编写内联代码，因为WebForms大量使用生成HTML输出的“控件”，并且表示逻辑预期由它们处理。例如，要迭代数据数组，您宁愿使用

asp:Repeater

而不是

foreach

循环。在这种情况下使用循环会让人感觉很糟糕，让人想起经典的ASP时代，当时标记和代码就像意大利面条一样混合在一起。我只能考虑使用

Response.Write

inline来输出调试消息

对于ASP.NETMVC 这里的情况完全不同。因为MVC不鼓励使用“控件”来支持干净的、手工编码的HTML标记，内联代码是为模型视图生成HTML的首选方式。当然，这也取决于您在内联代码中到底做了什么。我的经验法则是当控制器提供渲染视图所需的所有数据时，使用内联代码。内联代码应该只包含表示逻辑，例如根据条件显示或隐藏字段、从资源获取字符串、枚举模型中的数组等。您不应该从视图中与数据库对话这是控制器的用途

---

有些人在ASP.NETMVC中使用内联代码，因为他们在编写WebForms时了解到“内联代码不好”。这是一个错误的概念，我的答案是，内联代码只有在执行表示逻辑以外的操作时才是糟糕的。在WebForms中，这种逻辑由控件处理，在MVC中由内联代码处理，因此这里没有真正的问题。

谢谢，这就是我一直在寻找的那种详细、合理的解释。我真的很喜欢“内联代码只有在做了表示逻辑以外的事情时才是糟糕的”。现在我能记得了！