使用ASP.NET WebForms避免大球泥的提示

Question

虽然ASP.NET MVC似乎现在已经全部炒作，但WebForms仍然非常普遍。你如何保持你的项目理智？我们来这里收集一些提示。

Answer 1

我一般都试图清除它......但是当我使用WebForms时，我遵循这些规则：

1. 保持生成的HTML干净：仅仅因为您没有对每个<div>进行手工编码并不意味着生成的代码必须成为难以理解的噩梦。避免产生丑陋代码的控件可以在以后减少调试时间，通过使问题更容易看到。
2. 最大限度地减少外部依赖性：您无需支付调试其他人的代码的费用。如果您做选择依赖第三方组件，那么请获取源代码，这样您就不必浪费大量时间来修复它们的错误。
3. 避免在一个页面上做太多：如果您发现自己为给定页面实现复杂的“模式”，请考虑将其分解为多个单模式页面，可能使用母版页来分解共同方面。
4. 避免回发：这总是一个糟糕的主意，并没有那么糟糕。通过不使用依赖于回发的控件来节省的麻烦是一个很好的奖励。
5. 避免VIEWSTATE ：请参阅＃4的评论。

Answer 2

对于大型项目，我能给你的最好建议是遵循一个通用的设计模式，让你的所有开发人员都接受过良好的培训并且充分了解。如果您正在处理ASP.NET，那么对我来说最好的两个选项是：

o模型视图演示者（though this is now Supervisor Controller and Passive View）。   这是一个可靠的模型，推动您的用户界面和业务模型之间的分离，您的所有开发人员都可以毫不费力地遵循这些模型。生成的代码更易于测试和维护。问题是它没有强制执行，你需要编写大量支持代码来实现模型。

o ASP.NET MVC   这个的问题是它在预览中。我与Tatham Oddie谈过，并提到它非常稳定和可用。我喜欢它，它强制执行关注点的分离，并为开发人员提供最少的额外代码。

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

Answer 3

• 为将在多个页面上显示但不属于母版页类型内容的任何内容创建Web用户控件。示例：如果您的应用程序在10页上显示产品信息，则最好使用10页上使用的用户控件，而不是将显示代码切换10次。
• 尽可能将代码中的业务逻辑放在后面。后面的代码应该遵循您的业务层来执行与在页面上放置内容并在业务层上来回发送数据无直接关系的工作。
• 不要重新发明轮子。我见过的许多草率的代码隐藏都是由代码构成的，这些代码正在处理框架已经提供的东西。
• 一般情况下，请避免使用html中的脚本块。
• 没有一页做太多事情。我一次又一次看到的东西是一个说有添加和编辑模式的页面。没关系。但是，如果要添加和编辑许多子模式，最好通过用户控件重复使用每个子模式的多个页面。你真的需要避免使用一堆嵌套的IF来确定你的用户尝试做什么，然后根据它显示正确的东西。如果您的页面有许多可能的状态，事情会很快失控。
• 了解/了解页面生命周期并将其用于您的优势。如果编码人员更好地理解页面生命周期，那么我见过的许多丑陋的代码隐藏页面可能会更清晰。

Answer 4

在第1天开始使用母版页 - 这是一次痛苦的回归改造。

Answer 5

遵循Odd所说的，我正在尝试一个名为模型演示的MVP版本，这对我来说效果很好。我仍然了解它并使其适应我自己的使用，但它从我以前写的代码中刷新。

请在此处查看：Presentation Model

Answer 6

使用版本控制和文件夹结构来防止所有文件都在同一文件夹中。没有比等待Windows资源管理器加载某些东西更痛苦的了，因为文件夹中有1,000多个文件，并且在打开文件夹时必须加载所有文件。如果可能的话，关于命名变量和方法的约定也是很好的，因此不存在这种混合代码，其中不同的开发人员都将其独特的触摸和痛苦的显示。

使用设计模式有助于组织代码并使其可以很好地扩展，例如当必须添加必须支持的新类型的产品或设备时，策略模式可以使得更容易。与使用某些适配器或外观模式类似。

最后，了解您的表单将采用何种标准：是仅适用于IE用户还是IE，Firefox或Safari中的任何一个都可以轻松加载表单并且看起来不错？