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

Question

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

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

为了进一步复杂化，需要提交一份作业列表，并且需要以各种方式（作为引用程序集，通过Windows服务或通过Web服务）进行调用。

下面是它做的事情的一些例子：

• 生成作业成本估计
• 采取的帐户和/或用户到该工作分配
• 发出事件的作业提交进步来自外部，用户自定义列表跟踪数据
• 合并（的.csv，.xls的，等。）
• 从本地驱动器可访问网络驱动器复制文件（如有必要）

我的问题是：什么是最佳实践或设计模式，使其尽可能易管理和简单？

Answer 1

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

Answer 2

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

Answer 3

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

我自己不得不重新设计一个非常相似的应用程序。一旦我将我的数据层分离出来并从其他所有方面中解放出来，我的生活变得更加容易了。

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

Answer 4

除了推荐使用SOLID并且花费更多的时间来保持干燥之外，我会建议在系统中引入规则的概念。

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

这使您可以制定由其他人组成的规则。根据您的情况，这可能会大大简化您处理它的方式，因为涉及隐含在所有这些系统中的规则的操作可以表示为简单规则的组合。我会尽可能保持简单，但随着您的扩展，您可能会发现需要采用不同的方式来组合规则，并且模式会自行出现。

至于SOLID，我建议检查the ebook here，并尝试保持演变的代码方法。