处理许多参数和业务规则的设计模式答案

【问题标题】：Design pattern for handling many parameters and business rules处理许多参数和业务规则的设计模式
【发布时间】：2010-09-28 01:32:17
【问题描述】：

我正在从事一个项目，该项目负责创建一个“作业”，该“作业”由一个或多个“任务”组成，这些“任务”通过 DAL 持久化到数据库中。作业和任务列由根据业务规则设置的值组成。

现在存在的类变得越来越复杂和笨拙，因为业务规则规定它需要访问我们系统中的许多数据库来决定是否可以创建作业和/或应该如何设置它。

为了使事情更加复杂，需要提交作业列表，并且需要以多种方式调用（作为引用的程序集、通过 Windows 服务或通过 Web 服务）。

以下是它所做的一些示例：

我的问题是：有哪些最佳实践或设计模式可以使其尽可能易于管理和简化？

【问题讨论】：

【解决方案1】：

似乎该类需要重构，因为它似乎违反了Single Responsibility Principle。我建议上面的每个要点都有其单独的实现类。通过这种方式，您将实现 facade pattern ，其中您的主类代表系统正在执行的高级抽象。

【讨论】：

【解决方案2】：

如果不从头开始保持清洁，这种类型的程序会变得非常混乱。我自己总是尝试坚持使用基本的 3 层应用程序（演示、业务、数据）。以这种方式构建应用程序有很多很好的信息，最好是some demo projects，并阅读其他人对该主题的看法。这是MSDN reference。

我自己不得不重新设计一个执行非常相似的应用程序。一旦我将我的数据层分离出来并与其他所有东西一起解决问题，我的生活就变得轻松多了。

我最好的建议是花时间计划很多。使用图表、流程图等。当程序如此复杂时，我喜欢在开始编写代码之前为我的图层奠定基础。

【讨论】：

这绝对是一个例子，它最初是一个狭义的提交流程的简单实现，后来发展到包含多种工作类型和日益复杂的业务规则。它已经重新设计过一次，并且再次变得笨拙。我同意它需要根据您的建议重新设计。
另外，现有的 DAL 很干净并且运行良好。定义每种 DAL 类型使用的业务规则变得复杂。

【解决方案3】：

鉴于您对要求的描述，没有真正的“简单”方法可以解决这个问题。它的必要功能是庞大而多样的。我唯一的建议是将整个东西变成一个 DLL 库（甚至是一组 DLL），以分离各种前端，以便引用程序集不需要依赖于 Windows 服务（例如）；并坚持基本的 OOP 规则，例如松散耦合。

【讨论】：

当前实现有一个公共项目，其中包含一个包含单个作业提交逻辑的类以及一个处理作业列表的类。此外，还有不同类型的工作，每种类型共享大部分功能，但根据业务规则以不同的方式变化。有一个单独的 Windows 服务项目，它封装了公共库并且可以通过 WSE3 调用。

【解决方案4】：

除了建议使用 SOLID 并加倍努力保持 DRY 之外，我建议在系统中引入规则的概念。

通过对规则进行建模，您可以切换到更可配置/更灵活的方法。您可以组合多个规则来公开影响作业和相关任务结果的不同操作。

这允许您拥有由其他规则组成的规则。根据您所拥有的场景，这可以大大简化您处理它的方式，因为一些涉及分布在所有这些系统中的隐式规则的操作可以表示为简单规则的组合。我希望它尽可能简单，但是当你扩展它时，你可能会发现需要不同的方法来组合规则，并且模式会自行出现。

至于 SOLID，我建议检查 the ebook here 并尝试保持不断发展的代码方法。

【讨论】：