尽管这些天来ASP.NET MVC似乎大肆宣传，但WebForms仍然很普及。我们如何使项目保持理智？让我们在这里收集一些技巧。

解决方案

从第一天的母版页开始，痛苦就回到了改造上。

• 创建Web用户控件，以便将不属于母版类型内容的任何内容显示在一个以上的页面上。示例：如果应用程序在10页上显示产品信息，则最好让用户控件在10页上使用，而不是将显示代码粘贴10次。
• 在代码中尽可能少地添加业务逻辑。后面的代码应交给业务层执行与将内容放在页面上以及从业务层来回发送数据不直接相关的工作。
• 不要重新发明轮子。我看到的许多草率的代码隐藏都是由正在执行框架已经提供的功能的代码组成的。
• 通常，请避免在html中使用脚本块。
• 没有一页做太多的事情。我一次又一次看到的页面是具有添加和编辑模式的页面。没关系。但是，如果要添加和编辑许多子模式，则最好让每个子模式具有多个页面，并通过用户控件重复使用。我们确实需要避免使用一堆嵌套的IF来确定用户要尝试执行的操作，然后根据该操作显示正确的内容。如果页面有许多可能的状态，事情很快就会失控。
• 了解/掌握页面生命周期，并利用它来发挥优势。如果编码人员更好地了解页面生命周期，那么我见过的许多丑陋的代码隐藏页面可能会变得更整洁。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

我通常会尽量避免这种情况...但是当我使用WebForms时，我会遵循以下原则：

• 保持生成的HTML整洁：仅仅因为我们没有对每个<div>进行手工编码，并不意味着所生成的代码就必须成为难以理解的噩梦。避免产生丑陋代码的控件可以使问题更容易发现，从而在以后减少调试时间中获得回报。
• 最小化外部依赖性：我们无需付钱调试其他人的代码。如果我们确实选择依赖第三方组件，则可以获取源代码，这样我们就不必浪费大量时间来修复其错误。
• 避免在一页上做太多事情：如果发现自己在给定页面上实现了复杂的"模式"，请考虑将其分为多个单模式页面，也许可以使用母版页来考虑常见方面。
• 避免回发：这始终是一个糟糕的主意，而且也没有那么糟糕。如果不使用依赖于回发的控件，我们将可以省下很多麻烦，这是一个不错的选择。
• 避免使用VIEWSTATE：请参阅第4条注释。

使用版本控制和文件夹结构来防止太多文件全部位于同一文件夹中。没有什么比等待Windows资源管理器加载东西更痛苦的了，因为文件夹中有1,000多个文件，并且在打开文件夹时必须加载所有文件。如果可能的话，事先约定变量和方法的命名约定也是一个好习惯，这样就不会有代码混搭的情况，不同的开发人员会全力以赴，并且痛苦地表现出来。

使用设计模式有助于组织代码并使其具有良好的扩展性，例如当必须添加一种必须支持的新型产品或者设备时，一种策略模式可以导致更轻松的时间。与使用某些适配器或者外观模式类似。

最后，知道表单要遵循哪些标准：是仅适用于IE用户，还是IE，Firefox或者Safari中的任何一个都应该轻松加载表单并看起来不错？

对于大型项目，我能给最好建议是遵循一种通用的设计模式，我们所有的开发人员都应受过良好的训练，并且广为所知。如果我们正在使用ASP.NET，那么对我来说最好的两个选择是：

o模型视图演示器(尽管现在是Supervisor控制器和被动视图)。
这是一个坚实的模型，可将用户界面和业务模型分开，所有开发人员都可以遵循而没有太多麻烦。生成的代码更具可测试性和可维护性。问题是它没有被强制执行，并且我们需要编写许多支持代码来实现该模型。

o ASP.NET MVC
这个的问题在于它处于预览状态。我与Tatham Oddie进行了交谈，并被提及它非常稳定且可用。我喜欢它，它强制执行关注点分离，并为开发人员提供了最少的额外代码。

我认为无论我们选择哪种模型，最重要的是拥有一个模型并确保所有开发人员都能坚持使用该模型。

按照Odd所说的，我正在尝试一个名为Model Presentation的MVP版本，到目前为止对我来说效果很好。我仍然对它有所了解，并将其调整为适合自己的用途，但是它从我以前编写的代码中得到了刷新。

在此处查看：演示模型