问题标签 [dry]

这是我的问题：我们有 N 个应用程序在 M 个不同的环境（qa/prod/etc.）中运行，每个环境有 P 个服务器。相乘，独特配置的数量达到数百个。这些应用程序中的每一个都有一组特定于环境的属性（公共主机名、侦听端口、最大内存等）。

相乘，有数千个属性需要设置。但是，定义属性应该是什么的实际规则要简单得多。例如，在每个物理服务器有两个应用实例的生产环境中，一个应用绑定到端口 8080，另一个绑定到 8081。

这就是我想要的：一种语言 (DSL)，我可以使用它指定规定属性设置应该是什么的规则。我想避免重复自己。语言应该是声明性的。我们非常以 Java 为中心，但我需要做的就是生成名称/值对，所以我不想限制自己。

这样的事情存在吗？我什么也没找到。

我想我可以使用 Drools 或其他规则引擎，但这对于这个目的来说非常繁重。属性文件是最小的公分母。我们可以将它们放入 war/ear 文件中，在构建过程中使用它们进行基于模板的替换，等等。当然有更优雅的方法来解决这种性质的问题，但我们有点坚持我们的架构，至少在短期。

我正在 MVC 中编写一些 Web 应用程序，但我对一些一直在我脑海中的问题有疑问。我正在开发的网络应用程序主要用于瑞典语，并且由于语言的原因，我希望我的 URL 路由映射到瑞典语 URL 名称。

• mysite.com/products/details/1 （英文网址）
• mysite.com/produkter/detaljer/1 （瑞典网址）

有什么方法可以让您拥有与相同控制器/视图/操作映射的语言无关的 URL 路由？因为我还希望有相同的控制器/视图/操作可以在不同语言的站点中重用，例如英语。

我希望在 URL 和页面内容上使用相同的语言的原因是它可以让访问者更容易理解，并提高页面排名和搜索引擎优化。

我遇到了 DRY 原则（不要重复自己）和最小化围绕 Rete 规则引擎的依赖关系的问题。

大型 IT 组织中的规则引擎往往是企业级的（注意大写的“E”——这是一项严肃的业务）。所有规则都必须表达一次，既好又干，并集中在一个昂贵的规则引擎中。组维护规则引擎并且是规则集的保持者。

当该 IT 组织是美国保险公司的一部分时，往往会有很多规则。有适用于所有州和产品的规则，但每个州倾向于针对不同的产品制定自己的法律，因此规则需要反映这些怪癖。类别很多：精算、承保，甚至用于从第 3 方机构订购信用和机动车辆报告。

从设计的角度来看，我遇到的问题是集中规则和处理当然是好的和干燥的，但是有成本：

1. 额外的网络跃点以访问位于中心的规则服务并返回结果；
2. 如果规则引擎被暴露为 SOAP Web 服务，则额外的复杂性 - 消费者必须打包 SOAP 请求并将响应 OXM 回他们自己的域；
3. 维护规则引擎的企业组、设置和维护规则的业务以及使用规则的开发人员之间的附加接口；
4. 额外的复杂性——有时数据驱动的解决方案可能就足够了。
5. 额外的依赖——无法控制自己规则的组件不得不担心规则引擎的外部依赖，以进行测试、部署、发布等。

许多其他企业技术（例如，B2B 网关、ESB 等）都会出现这些问题。

相同的企业组也将 SOA 吹捧为基本原则。但我对正确服务设计的理解是，它们应该平铺业务空间，并且是幂等的、独立的和孤立的。如果服务的规则在其他地方维护，服务如何独立和隔离？

我想在简单性方面犯错，认为如果规则可以被证明仅适用于孤立的情况，那么消除依赖关系应该优先于集中化。我不确定这个争论是否会赢得胜利。

所以我的问题是：

1. 您对集中化与独立性的争论有何看法？
2. 您对规则引擎等企业工具有何经验？
3. 我怎样才能使孤立的论点更有力？
4. 如果我的观点不正确，你会提出什么论据来支持中心化？

'你好，所有。我正在尝试基于另一个模型在 Django 中创建一个模型 - 但不是子类化或与另一个模型有数据库关系。我的原始模型看起来像这样：它存储一些带有日期/时间戳的数据。

我还想使用几乎相同的模型每天汇总每个条目的数字数据。对于 DailyAvg() 变体，我们将使用 DateField() 而不是 DateTimeField()，因为每天只有一个平均值：

因此问题是：将有很多这些数据类需要存储在数据库中的相应日平均模型，并且定义几乎相同。我可以为每个数据类重新输入一个等效的 DailyAvg() 类的定义，但这似乎违反了 DRY，而且也是一个巨大的痛苦。我也不能有EntryDailyAvg 子类Entry，因为每次我保存一个新的EntryDailyAvg 时，Django 都会保存一个新的Entry 库。

有没有办法自动（-magically？）生成 DailyAvg() 类？

提前致谢！

ASP.NET MVC 2 Preview 1 中的一项新功能是支持编辑器模板和显示模板的概念，它允许您使用简单的 HTML 帮助程序调用预定义如何呈现给定对象以进行显示或编辑：

这很酷，但我并没有真正看到这与用于相同目的的局部视图之间的区别。此外，在示例中，我看到编辑器模板不包含实际的表单标签，并且如果我需要为给定的编辑器提供一些客户端功能（比如通过 jQuery），我无法安全地将该代码放入模板，因为我在客户端中添加逻辑的表单上没有静态句柄。在我正在处理的应用程序中，我混合了编辑器模板和部分视图，我渲染它们以编辑内容。根据我创建编辑器的表单的复杂性，我选择了一种方法而不是另一种方法，但这当然会给应用程序增加不希望的不一致程度。

为什么在局部视图上使用模板，反之亦然？此外，当使用编辑器模板时，将客户端逻辑添加到编辑器而不将其复制到使用该编辑器的每个视图中的理想方法是什么？

我有一个带有几个模型-视图-控制器的 Rails 应用程序，它们具有一些相似的特征，例如可以评论、投票或标记 5 个不同的模型，我也大量使用外部插件。

目前我只对单个模型（及其视图和控制器）引入了评论、投票、标签等。但是，既然我对结果感到满意，我想从一个模型的特定 MVC 中删除这个通用功能，并允许从所有其他模型访问它。

在我开始这样做之前的一些问题（也许一些一般性的建议也会很好）：

1 - 我应该怎么做？我正在考虑在“lib”目录中创建一个模块（它与 mixin 类相同吗？），然后将可重用的视图代码移动到常见的部分。控制器代码呢？

2 - 因为我在第一个模型的编码过程中刚刚学习 Ruby on Rails，所以我采用了一种可能不正确的方式，将一堆方法添加到控制器中。我有一个添加评论（addcomment），添加投票（addvote）等的方法。所有这些方法都需要通过：collection 进行非标准（非RESTful）路由。据我了解，正确的方法是将注释控制器功能移至其自己的控制器并通过标准 RESTful 路由访问。这是我应该做的吗？

3 - 许多插件（例如act_as_commentable）并不明确要求加载模块，只是模型中某处的一行“act_as_commentable”。我可以将这样的东西用于我的常用功能吗？它是如何工作的？

在 XSLT 中，当涉及到 'if' 时，保持代码 DRY 的首选方法是什么？

目前我正在这样做：

我宁愿只写一次“select/some/long/path”。

在努力实现 const 正确性的同时，我经常发现自己在编写这样的代码

对于很多方法，例如bar(). 编写这些手动调用 const 的非常量方法很乏味；此外，我觉得我在重复自己——这让我感觉很糟糕。

我能做些什么来减轻这个任务？（不允许使用宏和代码生成器。）

编辑：除了 litb 的解决方案，我也喜欢我自己的解决方案。:)

我有一些功能重叠的模块。根据 DRY，我想把它移到另一个位置，这样我需要维护的代码就更少了。最好的地方在哪里？如果我只是制作一个模块（并使其成为需要它的模块的依赖项），我能否保证其中定义的常量、函数和变量始终可用？

我一直在做一个需要用价格结果填充条形图的项目。该图表显示给定价格范围内的商品数量。例如，如果亚马逊上有 9 件商品的价格范围在 0 美元到 10 美元之间，那么 x 轴将显示 0 美元到 10 美元，而 y 轴将填充值 9。

我的条形图有 8 个条形图，均具有相似的价格范围。0-10 美元、10-20 美元、20-30 美元……等等。

我的问题是：定义这些点的最佳方法是什么？这些项目之间没有共同的价格范围，因此x 轴不能是静态数字。它们必须在结果范围内动态计算。

因此，目前我正在创建 x 轴点，如下所示：

我取最低的结果： @numbers[0] = results[0];

我拿了最高的结果： @numbers[8] = results[-1];

然后我找到两者的中位数： @numbers[4] = (@numbers[0]+@numbers[8])/2;

然后我再重复这个过程 6 次

@numbers[2] = (@numbers[0]+@numbers[4])/2; @numbers[6] = (@numbers[4]+@numbers[8])/2; @numbers[1] = (@numbers[0]+@numbers[2])/2; @numbers[3] = (@numbers[2]+@numbers[4])/2; @numbers[5] = (@numbers[4]+@numbers[6])/2; @numbers[7] = (@numbers[6]+@numbers[8])/2;

这给了我我需要的结果，但它似乎非常重复，我想有更好的方法。

我尝试创建一个循环，但我无法以一种不那么冗长的方式编写它。

有没有更快的方法来做到这一点，或者可能是更符合 DRY 的方法？