code-behind 不足之处

  大家都知道：ASP.NET通过code-behind 技术立刻带来了表现层和业务逻辑的分离。虽然微软的目的是好的，而且对一般的应用程序也有较好的表现，但是在开发企业级WEB应用程序的时候，code-behind 在很多方面都还比较欠缺： 1.code-behind 带来了表现层、业务逻辑、数据库访问层代码的混合。这是因为code-behind常常扮演事件处理器（event handler）、工作流控制器（a workflow controller）、表现层和业务逻辑层的中介者（mediator ）、表现层和数据访问层的中介者（mediator ）.赋予code-behind 这么多职责往往会带来难以管理的代码。在企业级应用的开发中，好的设计必须遵循一个原则：在各层之间保持适当的分离，尽可能的保持code-behind 的职责单一（keep the code-behind as clean as possible）。用Model-View-Presenter模式，我们将看到code-behind职责非常的单一化，并且对表现层的细节严格管理（kept strictly to managing presentation details.）

       2.code-behind 模式的另一个缺点是，如果不利用helper/utility 之类的类重复的代码抽离出来，在code-behind页间将很难对表现层逻辑进行重用。显然，这也是一个妥善的解决方案。但是这又常常导致低内聚的类，就象ASP中包含很多其他的对象一样。正确的设计，每个类都应该是高内聚、有单一的职责－－－如果把一个类命名为ContainsDuplicatePresentationCodeBetweenThisAndThat.cs ，就不合格了。

       3.由于code-behind页是和表现层页（aspx）紧密绑定的，所以几乎就很难进行单元测试。虽然也可以选择如：NUnitAsp 之类的产品进行测试。但是相当的耗时，影响单元测试的性能－－－单元测试应该是很简单快速的。