ASP.NET内联(单个文件)与代码隐藏

通常,在WebForms中工作时,我看到的趋势是使用代码隐藏。我在这个领域中看到的许多*webforms应用程序的代码太多,分离对于理解所有逻辑几乎是至关重要的。

然而,在一个设计良好的应用程序中,用户界面只做一个用户界面工作,并将所有的逻辑和繁重的工作传递给不同的应用程序层,一个单一的文件解决方案最终往往会更加优雅和容易遍历。在某种程度上,使用单文件解决方案可能——在右手边——会促使更好地分离关注点,因为您不希望一个文件(它提供了您的UI)与一堆业务逻辑混在一起。

在ASP.NET MVC模型中,默认值为单个文件。这再次强调了关注点的分离和良好的应用程序设计。(如果ASP.NET MVC工具包提供了一个代码隐藏概念,我还不太清楚。我还没有用过它。)

最终,YMMV。好的开发人员倾向于编写好的代码,不管是使用代码隐藏还是单文件模型。坏的开发人员也倾向于以任何方式编写坏的代码。

* 显然不是全部!

毫无疑问,在我看来,代码隐藏或MVC模型对于您想要做的几乎所有事情都是优越的。然而,即使在今天,我仍然发现自己在我的大部分页面中使用内联代码。为什么?因为有一个很大的场景是内联脚本真正发光的。

如果您有大量不想丢弃的传统ASP经典代码,包括深度嵌套结构,那么这些代码都存在于一个大型应用程序中,并且您希望将该应用程序与您的ASP.NET代码共享,那么您只需将内联ASP.NET页直接放到现有的Web文件系统中,它们就可以正常工作。

这听起来正是您的其他开发人员的来源。

因为codebehind只是一个类,所以它具有所有的优点,比如固有性和接口。它还增强了可读性。

对于专注于输出数据而不是实现业务逻辑的应用程序,单页主要被MVC所取代。

您是否考虑改用ASP.NET MVC?它会让你在一个非常干净的分离中克服这个迪勒姆纳。

内联代码本质上是程序化的,缺乏关注点分离…

ASP.NET的卖点之一是代码隐藏和服务器控件。有内联代码被认为是不好的。当ASP.NET MVC出现在场景中时,这种情况发生了变化——内联代码再次变成了“hip”。

如果我有选择,所有事情都是平等的,那么使用代码隐藏是一种更好的方法。我努力使尽可能多的逻辑/代码不在UI中。

即使使用后面的代码,虽然它是一个类,但它可能会变得混乱不堪。我发现,在Web表单中使用MVP或MVC的某个变体可以使开发从长远来看更易于维护。