创建 "Engine" 以允许集成到主 Web 应用程序？
Create "Engine" to allow integrations to main web application?
背景：
我目前有一个基于 MVC Kohana PHP 框架的 Web 应用程序，允许用户向他们的客户销售电子书。
webapp 背后的代码全部连接在一起，除了 API 以外的所有内容都是以 API 为中心的。
它是 运行 纯 MVC，然后使用 mustache 作为模板系统。
我想做的事情：
我想集成各种会计服务（来自更大的北欧供应商，如 e-conomic.com），但也想拥有集成功能，让用户优化他们的销售等等。
我想要实现的是做一些东西，称之为引擎，允许功能集成（灵活地）到 web 应用程序的各个部分，无论是在视图部分还是 controller/logic。
从背景和技术角度来看，有哪些方法可以做到？
我的想法是，我需要在 Web 应用程序的不同区域中到处使用某种占位符。然后我需要这些占位符与 "engine" 一起工作，然后检查集成是否希望在这些区域 "run"?
这样行吗？你会怎么做？
更新以使其更清楚：
所以我想完成的是拥有可以集成到现有主 Web 应用程序中的单独功能。
假设我有一个名为 integrations/ 的文件夹，其中有两个不同的集成会影响系统的不同部分。
第一个是 Kashflow（会计软件）集成，它从我们的系统中获取一些数据并发送到 Kashflow（API 方式，很好）但也在我的网络应用程序中 "orders" 说明它是否已经同步到 Kashflow。（这是问题的一部分）
另一个集成可能是 "Featured Ebook" 集成。这只是让您选择应该推荐的产品，然后在电子书商店中，推荐的产品将以橙色边框和一些更大的文本突出显示。（这是问题是关于)
粗体标记是如何工作的？像 Shopify 这样的网上商店提供商有应用程序可以做到这一点，所有其他带有应用程序的 SaaS 都有这个技术解决方案。
不知是不是？我怎样才能允许单独的功能影响基本网络应用程序？
我希望现在更清楚了。
新更新：
我要寻找的答案是基于上述背景的答案，我如何才能从我现在所在的位置实施允许这样做的解决方案。
一个很好的答案是，它也可以以文本/伪方式描述我提到的示例 plugin/integrations 中的一个是如何实现的。
那么集成如何与主应用程序通信，主应用程序有什么才能 accept/allow 功能。
根据您的更新，我认为您为需要模块化的 Web 应用程序描述了一个很好的案例。您希望能够轻松添加新模块（插件），为您提供不同的功能，而不必每次都更改应用程序核心。
以下是从概念角度解决您的挑战的可能解决方案。我的目的是帮助您掌握这个想法并让您开始。请记住，它可以进一步简化或变得更加复杂，具体取决于您的需要。
事物的理论方面
- Plugins/Modules
每个插件都将启用一组特定功能，并且必须能够独立于当前启用的其他插件工作。所有插件都必须遵循一组通用的规则和约定才能被您的应用程序识别。这将极大地简化未来的维护和扩展。例如，每个插件应该：
在Plugins/Modules文件夹下有自己的子目录，遵循预定义的结构（例如Backend/Portlets/InstallScripts等）
在您的数据库中使用单独的存储沙箱，仅专用于此插件。以 Kashflow 为例——插件使用的所有 table 都可以以 ksflw_ 前缀开头。
带来自己的部分前端视图表示（连同底层控制器逻辑和模型）实现特定的功能集（例如，显示预select橙色边框的书籍）
带来自己的部分后端视图演示（连同底层控制器和模型）在站点后端处理（在 Kashflow 的情况下）你有 portlet 可视化，它可能会呈现一个按钮来手动进行同步，使你能够安排一个并显示最后一次同步的日期时间）
有一个安装程序脚本，它创建 tables，插入菜单项，并初始化挂钩订阅（见下一个项目符号）
初始化 Hooks 订阅 – 只要系统某处发生注册事件，就会调用所有订阅的插件函数。
- 核心功能更改
您需要在现有应用程序中添加新功能才能开始支持插件。
插件管理器 – GUI 允许您安装、删除、enable/disable 插件并允许访问它们以供您使用客户.
局部视图管理器 – 允许用户select在现有占位符中显示哪些插件的哪些局部视图（这将结合使用带挂钩)
部分视图的占位符 在您希望用户显示插件UI 和信息的地方的页面上
整个应用程序的挂钩 – 每当"interesting"事件发生时，系统检查当前是否有任何插件订阅了该事件并且calls/notifies 他们，然后显示结果。一些值得挂钩的事件示例可能是：
占位符呈现 – 这将触发所有订阅的功能以显示 frontend/backend 局部视图
特定业务事件 – 例如每当新书被添加到目录或正在销售时
管理菜单呈现 – 在此事件中，每个安装的插件将select PLUGINNAME_AdminPluginMenu table 中的所有菜单项]（插件应该在安装时创建这个table）和return所有它们到钩子显示。
我相信您会想到其他相关事件，因为您最了解自己的情况。
事情的实际方面（基于问题的第二次更新）
1.利用 HMVC 可视化现有视图中的部分视图（小部件）
如前所述，Kohana 支持 HMVC 或分层模型视图控制器模式。这意味着您可以拥有这样的控制器层次结构（已在 following question 中描述）：
现在，这使您能够轻松地从其他控制器甚至直接从您的视图调用控制器！当您需要嵌入小部件时，它会产生奇迹。
您可以对 boostrap.ini 稍作修改，以启用像 widget_controller/controller_action/action_parameter 这样的路由（这在我下面给您的教程中有详细描述）。然后您可以在主视图模板中使用以下代码来呈现您的橙色书盒：
<div class="widget_sidebar">
<?php echo Request::factory('widget_orangebook/display/3')->execute(); ?>
</div>
执行时，它作为一个钩子，将调用 widget_orangebook 控制器的 action_display 方法和参数 3 - 例如你想展示 3 本书。
控制器的操作看起来像这样：
public function action_display ($number_of_books){...}
结果在<div>里面，你会看到widget_orangebook控制器在动作执行后设置的模板内容。
从某种意义上说，它给人一种 AJAX 部分渲染的错觉，但它是在服务器上执行的，没有额外的调用。它非常强大，我认为这就是您描述的案例的方法。
您可以查看 this tutorial 以查看您需要进行的所有修改的详细说明。它有点花哨 - 它是关于在小部件部分呈现多个小部件，但它遵循相同的逻辑。
注意，如果你坚持使用mustache和logicless模板，你也可以在controller中进行这种Request调用，将结果设置为一个变量，然后将该变量传递给你的mustache模板.
2。 Kohana 模块
Kohana 支持模块，允许您以有组织的方式打包您的插件。当您实现更复杂的插件时，这将变得很重要。可以看到more on Kohana Modules here.
让我从头说起。
您要查找的内容称为 service layer，应在您的应用程序中实现。它的作用是
Defines an application's boundary with a layer of services that
establishes a set of available operations and coordinates the
application's response in each operation.
Enterprise applications typically require different kinds of
interfaces to the data they store and the logic they implement: data
loaders, user interfaces, integration gateways, and others. Despite
their different purposes, these interfaces often need common
interactions with the application to access and manipulate its data
and invoke its business logic. The interactions may be complex,
involv-ing transactions across multiple resources and the coordination
of several responses to an action. Encoding the logic of the
interactions separately in each interface causes a lot of duplication.
A Service Layer defines an application's boundary [Cockburn PloP] and
its set of available operations from the perspective of interfacing
client layers. It encapsulates the application's business logic,
controlling transactions and coor-dinating responses in the
implementation of its operations.
让我用简单的术语解释一下，以便您理解。您首先要做的是在您的应用程序中定义一个服务层。由于您要使用 MVC，这可能是另一个控制器处理与此特定任务相关的所有请求。您可以为每对操作设置单独的控制器。最后你的引擎将是这些控制器集。
如果您愿意更上一层楼，您可以通过 ESB（企业服务总线）处理所有这些集成。
An enterprise service bus (ESB) is a software architecture model used
for designing and implementing communication between mutually
interacting software applications in a service-oriented architecture
(SOA). As a software architectural model for distributed computing it
is a specialty variant of the more general client server model and
promotes agility and flexibility with regard to communication between
applications. Its primary use is in enterprise application integration
(EAI) of heterogeneous and complex landscapes.
如果您需要更多信息，请告诉我。
更新
有详细记录的博客文章。请参阅下面的链接。
背景：
我目前有一个基于 MVC Kohana PHP 框架的 Web 应用程序，允许用户向他们的客户销售电子书。
webapp 背后的代码全部连接在一起，除了 API 以外的所有内容都是以 API 为中心的。 它是 运行 纯 MVC，然后使用 mustache 作为模板系统。
我想做的事情：
我想集成各种会计服务（来自更大的北欧供应商，如 e-conomic.com），但也想拥有集成功能，让用户优化他们的销售等等。
我想要实现的是做一些东西，称之为引擎，允许功能集成（灵活地）到 web 应用程序的各个部分，无论是在视图部分还是 controller/logic。
从背景和技术角度来看，有哪些方法可以做到？
我的想法是，我需要在 Web 应用程序的不同区域中到处使用某种占位符。然后我需要这些占位符与 "engine" 一起工作，然后检查集成是否希望在这些区域 "run"?
这样行吗？你会怎么做？
更新以使其更清楚：
所以我想完成的是拥有可以集成到现有主 Web 应用程序中的单独功能。
假设我有一个名为 integrations/ 的文件夹，其中有两个不同的集成会影响系统的不同部分。
第一个是 Kashflow（会计软件）集成，它从我们的系统中获取一些数据并发送到 Kashflow（API 方式，很好）但也在我的网络应用程序中 "orders" 说明它是否已经同步到 Kashflow。（这是问题的一部分）
另一个集成可能是 "Featured Ebook" 集成。这只是让您选择应该推荐的产品，然后在电子书商店中，推荐的产品将以橙色边框和一些更大的文本突出显示。（这是问题是关于)
粗体标记是如何工作的？像 Shopify 这样的网上商店提供商有应用程序可以做到这一点，所有其他带有应用程序的 SaaS 都有这个技术解决方案。
不知是不是？我怎样才能允许单独的功能影响基本网络应用程序？
我希望现在更清楚了。
新更新：
我要寻找的答案是基于上述背景的答案，我如何才能从我现在所在的位置实施允许这样做的解决方案。
一个很好的答案是，它也可以以文本/伪方式描述我提到的示例 plugin/integrations 中的一个是如何实现的。
那么集成如何与主应用程序通信，主应用程序有什么才能 accept/allow 功能。
根据您的更新，我认为您为需要模块化的 Web 应用程序描述了一个很好的案例。您希望能够轻松添加新模块（插件），为您提供不同的功能，而不必每次都更改应用程序核心。
以下是从概念角度解决您的挑战的可能解决方案。我的目的是帮助您掌握这个想法并让您开始。请记住，它可以进一步简化或变得更加复杂，具体取决于您的需要。
事物的理论方面
- Plugins/Modules
每个插件都将启用一组特定功能，并且必须能够独立于当前启用的其他插件工作。所有插件都必须遵循一组通用的规则和约定才能被您的应用程序识别。这将极大地简化未来的维护和扩展。例如，每个插件应该：
在Plugins/Modules文件夹下有自己的子目录，遵循预定义的结构（例如Backend/Portlets/InstallScripts等）
在您的数据库中使用单独的存储沙箱，仅专用于此插件。以 Kashflow 为例——插件使用的所有 table 都可以以 ksflw_ 前缀开头。
带来自己的部分前端视图表示（连同底层控制器逻辑和模型）实现特定的功能集（例如，显示预select橙色边框的书籍）
带来自己的部分后端视图演示（连同底层控制器和模型）在站点后端处理（在 Kashflow 的情况下）你有 portlet 可视化，它可能会呈现一个按钮来手动进行同步，使你能够安排一个并显示最后一次同步的日期时间）
有一个安装程序脚本，它创建 tables，插入菜单项，并初始化挂钩订阅（见下一个项目符号）
初始化 Hooks 订阅 – 只要系统某处发生注册事件，就会调用所有订阅的插件函数。
- 核心功能更改
您需要在现有应用程序中添加新功能才能开始支持插件。
插件管理器 – GUI 允许您安装、删除、enable/disable 插件并允许访问它们以供您使用客户.
局部视图管理器 – 允许用户select在现有占位符中显示哪些插件的哪些局部视图（这将结合使用带挂钩)
部分视图的占位符 在您希望用户显示插件UI 和信息的地方的页面上
整个应用程序的挂钩 – 每当"interesting"事件发生时，系统检查当前是否有任何插件订阅了该事件并且calls/notifies 他们，然后显示结果。一些值得挂钩的事件示例可能是：
占位符呈现 – 这将触发所有订阅的功能以显示 frontend/backend 局部视图
特定业务事件 – 例如每当新书被添加到目录或正在销售时
管理菜单呈现 – 在此事件中，每个安装的插件将select PLUGINNAME_AdminPluginMenu table 中的所有菜单项]（插件应该在安装时创建这个table）和return所有它们到钩子显示。
我相信您会想到其他相关事件，因为您最了解自己的情况。
事情的实际方面（基于问题的第二次更新）
1.利用 HMVC 可视化现有视图中的部分视图（小部件）
如前所述，Kohana 支持 HMVC 或分层模型视图控制器模式。这意味着您可以拥有这样的控制器层次结构（已在 following question 中描述）：
现在，这使您能够轻松地从其他控制器甚至直接从您的视图调用控制器！当您需要嵌入小部件时，它会产生奇迹。
您可以对 boostrap.ini 稍作修改，以启用像 widget_controller/controller_action/action_parameter 这样的路由（这在我下面给您的教程中有详细描述）。然后您可以在主视图模板中使用以下代码来呈现您的橙色书盒：
<div class="widget_sidebar">
<?php echo Request::factory('widget_orangebook/display/3')->execute(); ?>
</div>
执行时，它作为一个钩子，将调用 widget_orangebook 控制器的 action_display 方法和参数 3 - 例如你想展示 3 本书。
控制器的操作看起来像这样：
public function action_display ($number_of_books){...}
结果在<div>里面，你会看到widget_orangebook控制器在动作执行后设置的模板内容。
从某种意义上说，它给人一种 AJAX 部分渲染的错觉，但它是在服务器上执行的，没有额外的调用。它非常强大，我认为这就是您描述的案例的方法。
您可以查看 this tutorial 以查看您需要进行的所有修改的详细说明。它有点花哨 - 它是关于在小部件部分呈现多个小部件，但它遵循相同的逻辑。
注意，如果你坚持使用mustache和logicless模板，你也可以在controller中进行这种Request调用，将结果设置为一个变量，然后将该变量传递给你的mustache模板.
2。 Kohana 模块
Kohana 支持模块，允许您以有组织的方式打包您的插件。当您实现更复杂的插件时，这将变得很重要。可以看到more on Kohana Modules here.
让我从头说起。
您要查找的内容称为 service layer，应在您的应用程序中实现。它的作用是
Defines an application's boundary with a layer of services that establishes a set of available operations and coordinates the application's response in each operation.
Enterprise applications typically require different kinds of interfaces to the data they store and the logic they implement: data loaders, user interfaces, integration gateways, and others. Despite their different purposes, these interfaces often need common interactions with the application to access and manipulate its data and invoke its business logic. The interactions may be complex, involv-ing transactions across multiple resources and the coordination of several responses to an action. Encoding the logic of the interactions separately in each interface causes a lot of duplication.
A Service Layer defines an application's boundary [Cockburn PloP] and its set of available operations from the perspective of interfacing client layers. It encapsulates the application's business logic, controlling transactions and coor-dinating responses in the implementation of its operations.
让我用简单的术语解释一下，以便您理解。您首先要做的是在您的应用程序中定义一个服务层。由于您要使用 MVC，这可能是另一个控制器处理与此特定任务相关的所有请求。您可以为每对操作设置单独的控制器。最后你的引擎将是这些控制器集。
如果您愿意更上一层楼，您可以通过 ESB（企业服务总线）处理所有这些集成。
An enterprise service bus (ESB) is a software architecture model used for designing and implementing communication between mutually interacting software applications in a service-oriented architecture (SOA). As a software architectural model for distributed computing it is a specialty variant of the more general client server model and promotes agility and flexibility with regard to communication between applications. Its primary use is in enterprise application integration (EAI) of heterogeneous and complex landscapes.
如果您需要更多信息，请告诉我。
更新
有详细记录的博客文章。请参阅下面的链接。