【问题标题】:Designing all pages completely in the codebehind?完全在代码隐藏中设计所有页面?
【发布时间】:2011-03-23 22:25:05
【问题描述】:

我们当前工作的 Web 门户是来自经典 ASP 代码库的端口。目前,我们项目中的所有页面都扩展了一个名为PortalPage 的自定义Page 类。它处理登录/注销,为当前经过身份验证的用户提供对公共 User 对象的访问,并将标准页眉和页脚添加到我们所有的页面。

我们网站中的每个页面都是 100% 在代码隐藏中设计的。根本不使用 ASPX 页面。每个 div、img 和文本块都被分配为一个对象并从 C# 函数中添加,即使它是完全静态的内容(我们有相当数量的内容)。

页眉示例:

HtmlGenericControl wrapperDiv = new HtmlGeneric("div");
HtmlAnchor bannerLink = new HtmlAnchor();
HtmlImage banner = new HtmlImage();

bannerLink.HRef = "index.aspx";
banner.Src = "mybanner.png";
banner.Alt = "My Site";

bannerLink.Controls.Add(banner);
wrapperDiv.Controls.Add(bannerLink);
this.Page.Controls.Add(wrapperDiv);

更糟糕的是,所有的 Javascript 都作为一大堆字符串连接添加到页面中:

ClientScript.RegisterClientScriptBlock(this.GetType(), "javascript", @"
    <script language='javascript'>
        fullUrl = '" + ConfigurationManager.AppSettings["fullUrl"].ToString() + @"';
        function showModule()
        {
            $('#" + this.userModule.ClientID + @"').css('display','block');
            $('#" + this.groupModule.ClientID + @"').css('display','none');
            $('#" + this.listsModule.ClientID + @"').css('display','none');
            $('#" + this.labelsModule.ClientID + @"').css('display','none');
        }

目前,我的一位同事争辩说,分配代码隐藏中的每个对象比使用 ASPX w/ Codebehind 方法快数百倍,而我看到其他所有 Web 应用程序都在使用这种方法。这违背了我的直觉,因为它本质上是在页面上的每一段 HTML 中添加runat="server"

他还说,所有专业商店都以这种方式编写代码,从不使用 ASPX 页面。他说所有教科书和示例代码都使用 ASPX 页面,因为它们更容易让新手编码人员理解。这是有道理的,还是我们只是为了传统而以一种令人难以置信的低效方式写作?

为了让我们切换到编写 Web 表单的“标准”方式,我需要提供一些来源来证明他的错误。

我的问题是,我从未听说过其他人在代码隐藏中编写所有内容。我见过的每个示例都将 ASPX 页面用于用户界面,并使用代码隐藏用于逻辑、数据库调用等。

总之:
1) ASPX 页面真的比 100% 代码隐藏慢得多吗?
2) 专业商店真的使用 100% 代码隐藏吗?
3) 如果 ASPX w/codebehind 是要走的路,有没有人有任何可靠的链接可以帮助我支持?

【问题讨论】:

  • 听起来像是在为他的方式做事找借口。我从未见过任何 100% 代码隐藏的地方。
  • 错误地引用 Charles Babbage 的话,“我无法正确理解可能引发这种 Web 开发方法的想法的混乱。”
  • 用技术术语来说——你的同事被打了。这一定是我听说过的最低效、最晦涩难懂的编码方式。您失去了在页面运行时调整页面布局的所有能力(考虑到您的方法,您甚至可能不知道),这一切都是为了什么?这样你就可以吹嘘自己写出了最深奥的代码?
  • @Carson63000 很有趣,我昨天才第一次读到这句话here

标签: c# asp.net webforms code-behind


【解决方案1】:
  1. 它们都被编译成程序集。 .aspx 在应用程序启动时加载一次并解析一次
  2. 不,如果他们有任何意义的话。
  3. 查看网站上有关 ASP.NET 的每一本书。他们使用.aspx

对此进行测试的一种方法是运行性能测试,使用两个完全相同的.aspx 页面。除了.aspx(解析和编译)可能出现短暂的启动延迟外,我怀疑是否会检测到任何显着差异。

使用后面的所有代码是一种错过的方式:

  • 与了解 HTML 的设计师合作
  • 能够直观地检查标记
  • 能够轻松更改布局
  • 让经验丰富的 asp.net 开发人员与您合作...
  • 有一种理智的方式来开发 asp.net
  • 出色的工具和现有集成

【讨论】:

    【解决方案2】:

    你的同事完全,可怕,错了。

    【讨论】:

    • 没有一个词可以形容他的同事有多错。
    【解决方案3】:

    我什至不知道从哪里开始。

    我无法谈论性能问题 - 但我已经开发了数十个 WebForms 应用程序,没有一个遇到性能瓶颈与使用 aspx 页面有关的问题。

    这听起来像是一场彻头彻尾的噩梦。

    1. 演示内容放在 aspx 中。

    2. 事件处理程序进入代码隐藏

    3. 业务逻辑放在一个单独的 完全上课。

    4. Javascript 是你的 朋友,单独的js文件是 在那里为您维护您的 理智。

    【讨论】:

      【解决方案4】:

      如果您在小案例级别上运行它,不会有太多显着差异。所以用小页面测试它有点困难。您会发现更复杂的用例(例如您的门户)的性能差异。

      虽然我知道您正在使用 WebForms,但请查看 ASP.NET MVC 或任何 MVC 框架以获取指导。

      1. 作为视图生成的任何内容都会进入 ASPX 页面
      2. 任何决定放入视图(控制器)的内容都放在后面的代码中
      3. 任何用于表示将进入视图的内容都在其类中。
      4. 任何旨在作为您网站的一般展示的内容都应该放在母版页中。

      当您在背后的代码(包括 JavaScript)中执行所有操作时,您会失去的不仅仅是 RAM/CPU 的性能问题。您浪费了个人时间,因为每次您想要更新网站的 UI 或客户端脚本时都必须进行编译。然后,您还必须弄乱服务器上的 DLL,而不仅仅是 ASPX 页面。

      时间就是金钱,朋友。

      【讨论】:

        猜你喜欢
        • 2020-09-27
        • 1970-01-01
        • 2011-06-23
        • 1970-01-01
        • 2012-05-17
        • 1970-01-01
        • 2020-01-19
        • 1970-01-01
        • 2010-10-09
        相关资源
        最近更新 更多