这个问题严格来说是需要重建的现有系统的低效架构。它向具有管理此类笨拙系统经验的开发人员征求验证。我试图尽可能地将其抽象出来。
该应用程序迎合了非常复杂的需求,并且提供了非常好的服务。问题是内部管道使代码管理和可扩展性成为一场噩梦。我可以分享的关于上下文的小信息包括我们需要将代码视为数据商品的事实。换句话说,只有在持续的基础上添加实现的类时,系统才能运行。
应用程序向最终用户提供的不是数据,而是需要代码执行上下文的[Action]
。因此,应用程序必须在目标系统上执行一些代码,以便提供用户期望的内容。现在这些期望在编译时并不为人所知,而且几乎每天都需要添加新的期望。这意味着,开发人员会定期向系统添加[Actions]
。
现有系统静态链接到这些[Action]
类!这不仅会使代码管理成为一场噩梦,而且每次添加操作时都需要重新编译。
我的第一直觉是让系统在运行时动态链接到程序集,其中每个程序集都包含一堆操作。这类似于向应用程序添加可扩展性功能。我想到了MEF框架,但感觉不对。
我能想到的唯一选择是将每个操作作为源代码或编译模块存储在数据库中。每个都有自己的权衡,例如存储作为源不太安全,但让我更多地控制代码审查和持续维护。存储已编译具有服务器端程序集签名的好处。
我很欣赏有关如何构建这样的系统的一些建议。
答案 0 :(得分:1)
我认为您不需要更灵活的架构,而是需要更灵活的软件流程。大多数开发人员都会每天添加新功能。这不是插件系统的有效参数。
您不需要插件架构。您需要一个良好的软件开发方法,例如敏捷过程(例如Scrum和XP),并确保您能够执行此操作: