我正在开发一个负责创建“作业”的项目，该作业由一个或多个“任务”组成，这些“任务”通过DAL持久保存到数据库。作业和任务列由根据业务规则设置的值组成。
现在存在的类变得复杂和笨拙，因为业务规则要求它需要访问我们系统中的许多数据库来决定是否可以创建作业和/或应该如何设置作业。 / p>
为了进一步复杂化，需要提交作业列表，并且需要以各种方式调用（作为引用的程序集，通过Windows服务或通过Web服务）。
以下是它所做的一些事例：
我的问题是：有哪些最佳做法或设计模式可以使其尽可能易于管理和简单？
答案 0 :(得分：3)
似乎类需要重构，因为它似乎违反了Single Responsibility Principle。我建议上面的每一个要点都有其独立的实现类。通过这种方式，您将实现facade pattern，其中主类表示系统正在执行的操作的高级抽象。
答案 1 :(得分：1)
如果不从头开始保持清洁，这种类型的程序可能会变得非常混乱。我自己总是试图坚持基本的3层应用程序（演示，业务，数据）。以这种方式构建应用程序有很多好的信息，最好做some demo projects，并阅读其他人对该主题的看法。这是MSDN reference。
我自己不得不重新设计一个非常相似的应用程序。一旦我将数据层分开并从其他所有内容中解脱出来，我的生活就变得容易多了。
我最好的建议是花时间去计划。使用图表，流程图等等。当程序很复杂时，我喜欢在开始编写代码之前为我的图层奠定基础。
答案 2 :(得分：0)
鉴于您对要求的描述，没有真正“简单”的方法来解决这个问题。它必不可少的功能是庞大而多样的。我唯一的建议是将整个事物变成一个DLL库（甚至是一组DLL），以分离各种前端，以便引用程序集不需要依赖Windows服务（例如）;并坚持松散耦合等基本的OOP命令。
答案 3 :(得分：0)
除了建议使用SOLID并加倍努力以保持DRY，我建议在系统中引入规则的概念。
通过对规则建模，您可以切换到更具可配置性/灵活性的方法。您可以组合多个规则来公开影响作业和相关任务结果的不同操作。
这允许您拥有由其他人组成的规则。根据您拥有的方案，这可以大大简化您处理它的方式，因为涉及遍布所有系统的隐式规则的某些操作可以表示为简单规则的组合。我会尽可能简单地保持它，但是当你扩展它时，你可能会发现需要采用不同的方法来组合规则，并且模式会自行出现。
至于SOLID，我建议检查the ebook here并尝试保持不断发展的代码方法。