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

Question

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

c#asp.net

5

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

- 333Mhz

2个回答

2

我会给出一个经典的答案：“这取决于情况”。

如果涉及纯粹的视图问题，我会使用内联C#（并且经常这样做）。在MVC应用程序中，通过在视图中使用简单的C#代码来完成复杂的显示相关操作是一种常见的模式。

如果所讨论的代码严格涉及将数据呈现到页面上，则内联C#很可能是最简单、最容易的解决方案（除非您使用WebForms，否则没有任何东西是简单的）。如果代码与呈现数据无关，则我会将呈现部分与处理部分分开，并仅在视图中使用呈现代码。

- Tigraine

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Dan Abramov · Accepted Answer

对于ASP .NET WebForms

通常不建议编写内联代码，因为WebForms 重度使用“控件”，生成HTML输出和展示逻辑都由它们处理。例如，要迭代数据数组，您应该使用asp:Repeater而不是foreach循环。在这种情况下使用循环会让人想起经典的ASP天，当时标记和代码混在一起就像意大利面条一样。我只能想到使用Response.Write来输出调试消息。

对于ASP .NET MVC

这里情况完全不同。因为MVC不鼓励使用“控件”，而是支持干净、手写的HTML标记，所以内联代码是为模型视图生成HTML的首选方法。当然，这也取决于内联代码正在做什么。我的经验法则是当控制器提供了呈现视图所需的所有数据时，请使用内联代码。内联代码只应包含呈现逻辑，例如根据条件显示或隐藏字段、从资源获取字符串、枚举模型中的数组等。您不应该从视图中与数据库交互 - 这就是控制器的作用。

有些人不喜欢在ASP .NET MVC中使用内联代码，因为他们学习了“内联代码是不好的”这一点，当编写WebForms时也是如此。这是一个误解，我对此的回答是仅当内联代码执行除呈现逻辑以外的操作时才不好。在WebForms中，该逻辑由控件处理，在MVC中，该逻辑由内联代码处理，因此这里没有实际问题。