7

尽管最近 ASP.NET MVC 似乎大肆宣传，但 WebForms 仍然相当普遍。你如何保持你的项目理智？让我们在这里收集一些提示。

4

6 回答 6

3

我通常会尽量避开它......但是当我使用 WebForms 时，我会遵循以下规则：

  1. 保持生成的 HTML 干净：仅仅因为您没有手动编写<div>代码并不意味着生成的代码必须成为无法阅读的噩梦。避免产生丑陋代码的控件可以减少以后的调试时间，使问题更容易被发现。
  2. 最小化外部依赖：你不会因为调试其他人的代码而获得报酬。如果您确实选择依赖第 3 方组件，那么请获取源代码，这样您就不必浪费大量时间来修复他们的错误。
  3. 避免在一个页面上做太多事情：如果您发现自己为给定页面实现了复杂的“模式”，请考虑将其分解为多个单一模式页面，也许使用母版页来分解出共同的方面。
  4. 避免回发：这一直是个糟糕的主意，而且还没有变得更糟糕。通过不使用依赖回发的控件可以省去的麻烦是一个不错的奖励。
  5. 避免 VIEWSTATE：参见#4 的注释。
于 2008-09-22T23:17:02.037 回答
3

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

o 模型视图演示器（尽管现在是主管控制器和被动视图）。这是一个将用户界面和业务模型分开的可靠模型，您的所有开发人员都可以轻松地遵循它。生成的代码更具可测试性和可维护性。问题是它没有强制执行，您需要编写大量支持代码来实现模型。

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

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

于 2008-09-22T23:38:54.700 回答
2
  • 为不属于母版页类型内容的多个页面上显示的任何内容创建 Web 用户控件。示例：如果您的应用程序在 10 个页面上显示产品信息，最好有一个在 10 个页面上使用的用户控件，而不是剪切'n'粘贴显示代码 10 次。
  • 将尽可能少的业务逻辑放在后面的代码中。后面的代码应该遵从您的业务层来执行与将内容放在页面上并从业务层来回发送数据没有直接关系的工作。
  • 不要重新发明轮子。我见过的很多草率的代码隐藏都是由执行框架已经提供的事情的代码组成的。
  • 一般来说，避免 html 中的脚本块。
  • 不要一页做太多事情。我一次又一次地看到一个页面说有添加和编辑模式。没关系。但是，如果您要添加和编辑许多子模式，则最好为每个子模式设置多个页面，并通过用户控件重用。您确实需要避免使用一堆嵌套的 IF 来确定您的用户正在尝试做什么，然后根据它显示正确的内容。如果您的页面有许多可能的状态，事情很快就会失控。
  • 学习/了解页面生命周期并将其用于您的优势。如果编码人员更好地理解页面生命周期，我见过的许多丑陋的代码隐藏页面可能会更干净。
于 2008-09-22T23:04:31.910 回答
1

从第 1 天的 Master Pages 开始 - 重新进行改造会很痛苦。

于 2008-09-22T23:04:09.073 回答
0

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

在这里查看：演示模型

于 2008-09-23T00:32:31.607 回答
-1

使用版本控制和文件夹结构来防止太多文件都在同一个文件夹中。没有什么比等待 Windows 资源管理器加载更痛苦的了，因为一个文件夹中有 1,000 多个文件，并且必须在打开文件夹时加载所有文件。如果可能的话，提前制定一个命名变量和方法的约定也很好，这样就不会出现这种混杂的代码，不同的开发人员都把他们独特的接触和痛苦地展示出来。

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

最后，了解您的表单将遵循哪些标准：它是否仅适用于 IE 用户，或者 IE、Firefox 或 Safari 中的任何一个是否应该轻松加载表单并看起来不错？

于 2008-09-22T23:26:29.190 回答