我有兴趣阅读其他开发人员和架构师处理为某些站点定制其应用程序某些区域的各种方式。调用客户实现的前后处理、执行相同操作的事件、允许覆盖业务逻辑方法、使用具有可插拔模块的策略、数据可配置流程(例如规则引擎、脚本等)。
清单可以继续,但我要问的是谁使用了这些方法,每种方法的优缺点是什么,以及还有哪些其他方法。
这假设我们不创建客户特定的代码分支来适应这些定制。
我有兴趣阅读其他开发人员和架构师处理为某些站点定制其应用程序某些区域的各种方式。调用客户实现的前后处理、执行相同操作的事件、允许覆盖业务逻辑方法、使用具有可插拔模块的策略、数据可配置流程(例如规则引擎、脚本等)。
清单可以继续,但我要问的是谁使用了这些方法,每种方法的优缺点是什么,以及还有哪些其他方法。
这假设我们不创建客户特定的代码分支来适应这些定制。
MS 正在 .NET 中为此开发两个不同的框架:托管可扩展性框架和 System.Addin。
应用程序暴露可扩展性的最常用方式可能是通过依赖注入/控制反转与运行时类型解析相结合。这意味着,您让外部实体在运行时“注入”接口的实现,而不是在编译时绑定到特定的实现。您的代码不关心您的 IRepository 是由您的公司还是由第三方编写的。通过针对接口进行编码并使用 DI/IOC 框架(此链接提供了 .NET 框架的一个很好的概述),您可以轻松地自定义您的应用程序。
我倾向于构建所有模块化的东西,然后根据客户的要求将东西添加到程序中。您可以将其与客户可以控制的应用程序设置相结合,允许他们自行添加和删除模块。在这种情况下,您要做的就是设置默认配置。
一种方法是嵌入脚本语言(python 和 javascript 似乎很流行)并通过脚本扩展公开 API 的重要块。您可能会发现用脚本语言实现部分应用程序也更容易。
对于我使用的产品,由服务组为给定客户构建的定制,或者有时由客户自己构建的定制,被共享给团队的其他成员(对于我们制作的东西),并且经常被“产品化”在以后的版本中。
我们支持 [几乎] 完全访问 API,它可以用来做 [几乎] GUI 可以做的任何事情,但以自动化的方式。
我们鼓励客户编写自定义脚本,然后与我们分享。通过扩展来增加产品的可用用途,无论它们是得到官方支持还是保留社区工具,都有助于在您的客户群中产生善意。
对于我们构建的定制,初始工作虽然向特定客户收费,但随后可以在其他地方快速实施,从而使当前和未来的用户在使用产品时更加灵活。
我发现将您的应用程序创建为可通过良好的嵌入式脚本语言访问的模块库(Lua正是为此而创建的!)为您提供了极大的灵活性,不仅对用户而言;但也为你自己。