Is inline code in your aspx pages a good practice?如果使用以下代码，我将无法右键单击后面代码中的变量并对其进行重构(在这种情况下为重命名)
我到处都可以看到这种做法，但是对我来说似乎很奇怪，因为如果更改属性名称，我将再也无法得到编译时错误。
，然后在 后面的代码中
我真的很想听听人们是否认为上述方法更好，因为这是我在流行的编码网站和博客(例如Scott Guthrie)上经常看到的内容，并且它的代码较小，但是我倾向于使用ASP.NET，因为它已被编译，并且希望知道在编译时(而不是运行时)是否有问题。 我不会称其为不好的做法(有些人会不同意，但是为什么他们会首先给我们这个选择？)，但是我想说，如果您不遵循这种做法，将会提高整体的可读性和可维护性。 。您已经传达了一个很好的观点，那就是IDE功能限制(即设计时间检查，编译时间警告等)。 我可以继续探讨它违反了多少条原则(代码重用，关注点分离等)，但是我可以想到那里的许多应用程序破坏了几乎所有的原则，但几年后仍然有效。我一个，更喜欢使我的代码尽可能模块化和可维护。 我仅偶尔使用它，并且通常出于某些特定原因。我将永远是一个快乐的开发人员，我的代码与HTML标记完全分开。这在某种程度上是个人喜好，但是我会说这是一种更好的做法。 这被称为意大利面条代码，许多程序员认为它令人反感...然后，如果您和公司的其他开发人员认为它可读性和可维护性，我想告诉您该怎么做。 但是请确保使用include来减少冗余(DRY-不要重复自己) 通常我是这样使用的。
不是，但有时是必须的邪恶。 以您的情况为例，尽管后面的代码似乎可以更好地分离关注点，但问题在于它可能无法如您所愿地清楚地分离关注点。通常，当我们编写东西背后的代码时，我们并不是在MVC框架中构建应用程序。无论如何，至少与MVC相比，代码背后的代码也不容易维护和测试。 如果您要构建ASP.NET MVC应用程序，那么我认为您肯定会陷入内联代码中。但是就可维护性和可测试性而言，以MVC模式进行构建是最好的方法。 总而言之：内联代码不是一个好习惯，但这是必不可少的。 我的2美分。 如果不能很好地封装它，这只是一个不好的做法。 与其他所有内容一样，您可以创建令人讨厌的，不可读的意大利面条代码，只是现在您有了内容标签，而这些标签在设计上并不是世界上可读性最高的东西。 我尝试将大量if模板保留在模板之外，但是过多的封装导致不得不查看13个不同的位置，以了解div x为何不向客户触发，因此这是一个折衷。 如果从模板开发的angular考虑它，那么将其保持在视图中而不是在后面的代码中是明智的。如果需要使用不引人注意的JS从锚点更改为列表项以处理点击该怎么办？是的，这不是最佳示例，而仅仅是示例。 我总是试图考虑是否有设计师(HTML，CSS等)，他将要做什么以及在后面的代码中将要做什么，以及我们如何不互相依赖？脚趾。 我认为有趣的是，更多的asp.net在aspx页面中需要代码。 3.5中的listview，甚至ASP.NET MVC。 MVC基本上没有任何代码，但是页面中的代码用于呈现信息。 由您决定。有时，" spagehetti"代码比为简单的事情构建/使用完整的模板系统更容易维护，但是一旦您获得相当复杂的页面，或更具体地说，一旦您开始在页面本身中包含很多逻辑，它就可以维护真的很脏。 |
