【问题标题】:What Does the DRY Principle Actually Look Like in ASP.NET MVC?DRY 原则在 ASP.NET MVC 中实际上是什么样的?
【发布时间】:2008-10-09 15:36:58
【问题描述】:

我一直听说 DRY 原则以及它在 ASP.NET MVC 中的重要性,但是当我在 Google 上进行研究时,我似乎不太了解它是如何应用于 MVC 的。

从我读到的内容来看,它并不是真正的复制和粘贴代码气味,我认为是,但不仅如此。

你们中的任何人都可以对我如何在我的 ASP.NET MVC 应用程序中使用 DRY 原则提供一些见解吗?

【问题讨论】:

  • 只是不要重复自己。 :)(对不起,忍不住)

标签: asp.net asp.net-mvc dry


【解决方案1】:

DRY 的意思是“不要重复自己”。确保在编写代码时只编写一次。如果您发现自己在所有 Controller 类中编写了类似的功能,请创建一个具有该功能的基本控制器类,然后从它继承,或者将功能移到另一个类中并从那里调用它,而不是在所有控制器中重复它。

【讨论】:

    【解决方案2】:
    • 使用过滤器属性来管理方面(身份验证、导航、面包屑等)
    • 使用layer supertype 控制器(对其应用常见的控制器级过滤器,请参阅mvccontrib for an example
    • 编写自定义操作结果(如in mvccontrib - 例如,我们制作了一个名为 logoutresult 的函数,它只执行 FormsAuthentication.Logout()
    • 对视图名称使用约定
    • 最重要的是 - 让您的控制器操作愚蠢,在服务中寻找重用机会

    【讨论】:

    • (7 年后...)保持控制器操作“哑”是什么意思?
    • 当然,这意味着动作方法中的几行代码。在设计方面,这意味着控制器操作应该负责管理应用程序的情节提要流程(例如,重定向后获取),并将处理输入模型或构建视图模型留给其他事情。
    • 谢谢马特,我现在明白了
    【解决方案3】:

    不要重复自己。它可以应用于编程的许多不同方面。最基本的层面是防止代码异味。我没有使用过 ASP.NET,所以我无法具体了解它和 MVC。

    • 在 C++ 中,模板会预先设置同一函数的多个副本。
    • 在 C 中,可以以类似的方式使用 void * 指针,但要非常小心。
    • 从另一个函数继承允许函数允许其他函数使用相同的代码库,而无需复制代码。
    • 对数据库中的数据进行规范化可以最大限度地减少冗余数据。同时遵守 DRY 原则。

    当您回顾项目中的“想法”时。问问自己。

    1. 我已经写过这段代码了吗?
    2. 此代码在其他地方是否有用。
    3. 我可以通过构建以前的类/函数来节省编码吗?

    【讨论】:

      【解决方案4】:

      DRY 并不特定于任何one 技术。只需确保您从功能的角度(甚至不是从复制/粘贴编码器视图)查看您的类,并查看重复发生的位置。这个过程可能不会一次性发生,并且您只会在几个月后在添加新功能时审查您的代码后才会注意到重复。如果您有单元测试,则不必担心删除该重复项。

      【讨论】:

        【解决方案5】:

        MVC 与不重复自己相关的一个优点是,您的控制器可以执行一个类中所有页面共有的任务。例如,可以集中验证某些类型的恶意请求或验证身份验证。

        【讨论】:

          【解决方案6】:

          DRY 不仅应应用于代码,还应应用于一般信息。您是否在构建系统中重复某些事情?你有数据应该移动到一个通用的配置文件等。

          【讨论】:

            【解决方案7】:

            嗯,我能给出的关于 DRY 和 UI 的最常见示例是使用 MasterPages 和 UserControls 之类的东西。

            MasterPages 确保您只编写一次所有静态 HTML。

            用户控件确保代码的可重用性。例如,您将有很多表单执行基本的操作,例如 CRUD。现在,理想情况下,我们希望所有用户看到创建和更新的不同页面,尽管两者中的表单字段几乎相同。我们能做的就是把所有的常用控件组合起来,放到一个可以在两个页面上重复使用的控件中。这确保我们永远不会重新输入(或复制粘贴)相同的代码。

            DRY 在 MVC 中尤其重要,因为完成相同任务的文件数量会增加。

            【讨论】:

              【解决方案8】:

              似乎存在一种误解,即必须将域模型中的所有内容都复制为特殊的视图模型。您可以让域模型成为域模型,但视图模型是对域细节一无所知并且更通用的东西。例如:

              领域模型类:Account、Asset、PurchaseOrder

              View Model:List、Table、Tuple、SearchFormBackingModel:Checked options、Outputoptions 等。视图本身可能更具体的视图实现。

              元组/字典/映射可能映射到 Account、Asset 和 PurchaseOrder 单个实例,但表可能对它们的集合等有用。您仍然有 MVC,但您有会话数据,尚未准备好在视图中进行交易模型不一定违反你的域模型的规则,这是规则应该去的地方。这样,他们将不那么贫血和反模式。您可以在前面传递这些规则并在那里或只是在后面或两者都使用它们,具体取决于系统如何从客户端读取等。

              【讨论】:

                猜你喜欢
                • 1970-01-01
                • 1970-01-01
                • 1970-01-01
                • 1970-01-01
                • 1970-01-01
                • 1970-01-01
                • 2021-09-07
                • 1970-01-01
                • 2021-05-12
                相关资源
                最近更新 更多