使应用程序可定制的最佳实践？答案

【问题标题】：Best practices for making an application customizable?使应用程序可定制的最佳实践？
【发布时间】：2008-11-05 14:16:46
【问题描述】：

我有兴趣了解其他开发人员和架构师处理针对某些网站定制其应用程序的某些区域的各种方式。调用客户实施的前后处理，事件执行相同的操作，允许覆盖业务逻辑方法，使用具有可插拔模块的策略，数据可配置流程，例如规则引擎、脚本等。

列表可以继续，但我想问的是谁使用了这些方法，每种方法的优缺点是什么，以及还有哪些其他方法。

这假设我们不创建客户特定的代码分支来适应这些自定义。

【问题讨论】：

标签： architecture customization extensibility

【解决方案1】：

MS 正在 .NET 中为此开发两个不同的框架：Managed Extensibility Framework 和 System.Addin。

应用程序暴露可扩展性的最常用方式可能是通过依赖注入/控制反转与运行时类型解析相结合。这意味着，您让外部实体在运行时“注入”接口的实现，而不是在编译时绑定到特定的实现。您的代码不关心您的 IRepository 是由您的公司还是由第三方编写的。通过针对接口进行编码并使用 DI/IOC 框架(this link provides a great overview of .NET frameworks)，您可以轻松地自定义您的应用程序。

【讨论】：

DI/IOC 可能是要走的路。控制权被赋予一个标准模块，或者是（甚至可能是热的）可与自定义控制交换的。您是否在 IOC 接口中公开 IOC 接口，允许客户端选择您的低级服务来实现其高级服务？

【解决方案2】：

我倾向于将所有东西都模块化，然后根据客户的要求将东西添加到程序中。您可以将其与客户可以控制的应用程序设置相结合，允许他们自行添加和删除模块。在这种情况下，您要做的就是设置默认配置。

【讨论】：

我的意思是允许对核心流程进行自定义更改，其中添加和删除模块意味着将这些流程分解到非常精细的粒度，但这是一个不错的方法。
保持一切模块化还有一个额外的好处 - 发送错误修复意味着发送一个新模块，而不是一个全新的程序，并且客户可以将旧模块换成新模块。跨度>
好点，但是如何在没有每个模块的方法的情况下构建它？我仍然认为人们（大多数不是您）没有理解我的观点，即自定义处理不是附加组件，而是替代。

【解决方案3】：

一种方法是嵌入脚本语言（python 和 javascript 似乎很流行）并通过脚本扩展公开 API 的重要块。您可能会发现用脚本语言实现应用程序的某些部分也更容易。

【讨论】：

【解决方案4】：

对于我使用的产品，由服务组为给定客户构建的定制，或者有时由客户自己构建的定制，被共享给团队的其他成员（对于我们制作的东西），并且经常得到在以后的版本中“产品化”。

我们支持 [几乎] 完全访问 API，它可用于执行 [几乎] GUI 可以执行的任何操作，但以自动化方式。

我们鼓励客户编写自定义脚本，然后与我们分享。通过扩展来增加产品的可用用途，无论它们是得到官方支持还是保留为社区工具，都有助于在您的客户群中产生善意。

对于我们构建的定制，最初的工作虽然向特定客户收费，但随后可以在其他地方快速实施，从而使当前和未来的用户在使用产品时更加灵活。

【讨论】：

【解决方案5】：

我发现，将您的应用程序创建为可通过良好的嵌入式脚本语言访问的模块库（Lua 正是为此创建的！）为您提供了极大的灵活性，不仅对用户而言；但也为你自己。

【讨论】：