我一直听说 DRY 原则以及它在 ASP.NET MVC 中的重要性，但是当我在 Google 上进行研究时，我似乎不太了解它是如何应用于 MVC 的。
从我读到的内容来看，它并不是我认为的复制和粘贴代码的味道，但它不仅如此。
你们中的任何人都可以深入了解我如何在我的 ASP.NET MVC 应用程序中使用 DRY 原则吗？
Elijah Manor
问问题
4536 次
8 回答
7
DRY 的意思是“不要重复自己”。确保在编写代码时只编写一次。如果您发现自己在所有 Controller 类中编写了类似的功能，请创建一个具有该功能的基本控制器类，然后从它继承，或者将功能移到另一个类中并从那里调用它，而不是在所有控制器中重复它。
于 2008-10-09T16:05:13.900 回答
4
- 使用过滤器属性来管理方面（身份验证、导航、面包屑等）
- 使用层超类型控制器（对其应用常见的控制器级过滤器，参见mvccontrib 示例）
- 编写自定义操作结果（如在 mvccontrib 中- 例如，我们制作了一个名为 logoutresult 的函数，它只执行
FormsAuthentication.Logout() - 使用视图名称约定
- 最重要的是——让你的控制器动作保持沉默，在服务中寻找重用机会
于 2008-10-12T17:47:39.513 回答
2
不要重复自己。它可以应用于编程的许多不同方面。最基本的层面是防止代码异味。我没有使用过 ASP.NET，所以我无法具体了解它和 MVC。
- 在 C++ 中，模板会阻止同一函数的多个副本。
- 在 C 中，可以以类似的方式使用 void * 指针，但要非常小心。
- 从另一个函数继承允许函数允许其他函数使用相同的代码库，而无需复制代码。
- 规范化数据库中的数据可以最大限度地减少冗余数据。还坚持 DRY 原则。
当你在一个项目中回顾一个“想法”时。问你自己。
- 我已经写过这段代码了吗？
- 这段代码在其他地方有用吗？
- 我可以通过构建以前的类/函数来节省编码吗？
于 2008-10-09T16:12:55.817 回答
1
DRY 并不特定于任何一种技术。只需确保您从功能的角度（甚至不是从复制/粘贴编码器视图）查看您的类，并查看重复发生的位置。这个过程可能不会一次性发生，并且您只会在几个月后在添加新功能时审查您的代码后才会注意到重复。如果您有单元测试，则不必担心删除该重复项。
于 2008-10-09T16:09:35.077 回答
1
MVC 与不重复自己相关的一个优点是，您的控制器可以执行一个类中所有页面共有的任务。例如，可以集中验证某些类型的恶意请求或验证身份验证。
于 2008-10-09T16:22:33.740 回答
0
DRY 不仅应该应用于代码，还应该应用于一般信息。您是否在构建系统中重复某些事情？您是否有应该移动到通用配置文件等的数据？
于 2008-10-12T18:04:20.790 回答
0
嗯，我可以给出的关于 DRY 和 UI 的最常见示例是使用 MasterPages 和 UserControls 之类的东西。
MasterPages 确保您只编写一次所有静态 HTML。
UserControls 确保代码的可重用性。例如，您将有很多表单执行基本的操作，例如 CRUD。现在，理想情况下，我们希望所有用户看到创建和更新的不同页面，尽管两者中的表单字段几乎相同。我们能做的就是把所有的常用控件组合起来，放到一个可以在两个页面上重复使用的控件中。这确保我们永远不会重新输入（或复制粘贴）相同的代码。
DRY 在 MVC 中尤其重要，因为完成相同任务的文件数量增加了。
于 2008-10-13T14:39:20.203 回答
0
似乎存在一种误解，即必须将域模型中的所有内容复制为特殊的视图模型。您可以让域模型成为域模型，但视图模型是对域细节一无所知并且更通用的东西。例如：
领域模型类：Account、Asset、PurchaseOrder
视图模型：List、Table、Tuple、SearchFormBackingModel：Checked options、Outputoptions 等。视图本身可能更特定于视图实现。
Tuple/Dictionary/Map 可能映射到 Account、Asset 和 PurchaseOrder 单个实例，但 Table 可能对它们的集合等有用。您仍然有 MVC，但您有会话数据，尚未准备好在视图模型中进行事务处理，但不一定让它违反你的域模型的规则，这是规则应该去的地方。这样，他们将不那么贫血和反模式。您可以在前面传递这些规则并在那里或只是在后面或两者都使用它们，具体取决于系统如何从客户端读取等。
于 2013-01-18T19:42:09.437 回答