【问题标题】:Create "Engine" to allow integrations to main web application?创建“引擎”以允许集成到主 Web 应用程序?
【发布时间】:2015-06-12 06:00:42
【问题描述】:

背景:

我目前有一个基于 MVC Kohana PHP 框架的 Web 应用程序,它允许用户向他们的客户销售电子书。

Web 应用程序背后的代码全部连接在一起,除了以 API 为中心之外的所有内容。 它运行纯 MVC,然后使用 mustache 作为模板系统。

我想做的事:

我想整合各种会计服务(来自更大的北欧供应商,如 e-conomic.com),但我也想自己的整合,让用户优化他们的销售等等。

我想要做的是制作一些东西,称之为引擎,它允许将功能集成(灵活)到 web 应用程序的各个部分,无论是在视图部分还是控制器/逻辑中。

从背景和技术角度来看,有哪些方法可以做到这一点?

我的想法是,我需要在 web 应用程序的不同区域使用某种占位符。然后我需要这些占位符与“引擎”一起工作,然后检查集成是否要在这些区域“运行”?

这还能用吗?你会怎么做?


更新试图使其更清晰:

所以我想要完成的是拥有可以集成到现有主 web 应用程序中的单独功能。

假设我有一个名为 integrations/ 的文件夹,其中有两个不同的集成会影响系统的不同部分。

第一个是 Kashflow(会计软件)集成,它从我们的系统中获取一些数据并发送到 Kashflow(API 方式,很好)但也在我的 web 应用程序中的“订单”下说明它是否已同步到 Kashflow还是没有。(这是问题的一部分)

另一个集成可能是“精选电子书”集成。这只是让您选择应该展示的产品,然后在电子书商店上,特色产品将突出显示,周围有橙色边框和一些更大的文字。(这是问题所在的部分)

粗体标记是如何工作的?像 Shopify 这样的网店供应商有可以做到这一点的应用程序,而所有其他带有应用程序的 SaaS 都有这种技术解决方案。

我想知道是吗?如何允许单独的功能影响基础 web 应用?

我希望现在更清楚了。


新的更新:

我要寻找的答案是基于上述背景的答案,我如何实施一个解决方案,从我现在的位置实现这一点。

一个好的答案是,也可以以文本/伪方式描述我提到的示例插件/集成之一是如何实现的。

那么集成如何与主应用程序通信,主应用程序有什么来接受/允许功能。

【问题讨论】:

  • 您能否详细说明集成。您需要将您的功能暴露给其他服务,对吗?您想公开数据以供读取/写入,还是希望客户端能够在其页面中嵌入部分视图?
  • 请检查我更新的问题,我希望我回答了你的意见

标签: php model-view-controller architecture kohana


【解决方案1】:

根据您的更新,我认为您为需要模块化的 Web 应用程序描述了一个很好的案例。您希望能够轻松添加新模块(插件),从而为您提供不同的功能,而无需每次都更改应用程序核心。

以下是从概念角度解决您的挑战的可能解决方案。我的目的是帮助你掌握这个想法并让你开始。请记住,根据您的需要,它可以进一步简化或变得更加复杂。


事物的理论方面

  1. 插件/模块

每个插件都将启用一组特定的功能,并且必须能够独立于当前启用的其他插件工作。所有插件都必须遵循一组通用的规则和约定才能被您的应用程序识别。这将极大地简化未来的维护和扩展。例如,每个插件应该:

  • 在 Plugins/Modules 文件夹下有自己的子目录,该文件夹遵循预定义的结构(例如 Backend/Portlets/InstallScripts 等)

  • 在您的数据库中使用单独的存储沙箱,仅用于此插件。以 Kashflow 为例——插件使用的所有表都可以以 ksflw_ 前缀开头。

  • 自带部分前端视图展示(连同底层控制器逻辑和模型),实现特定功能集(例如,以橙色边框显示预选书籍)

  • 自带部分后端视图展示(连同底层控制器和模型)在站点后端处理(在 Kashflow 的情况下,您有可能呈现的 portlet 可视化手动进行同步的按钮,使您可以安排同步并显示上次同步的日期时间)

  • 有一个安装程序脚本,它可以创建表格、插入菜单项和初始化挂钩订阅(请参阅下一个项目符号)

  • 初始化 Hooks 订阅 – 只要系统中某处发生注册事件,就会调用所有订阅的插件函数。


  1. 核心功能变化

您需要在现有应用程序中添加新功能才能开始支持插件。

  • 插件管理器 - 允许您安装、删除、启用/禁用插件并允许您的客户访问它们的 GUI。

  • 部分视图管理器 - 允许用户选择在现有占位符中显示哪些插件的哪些部分视图(这将与钩子一起使用)

  • 部分视图的占位符在您希望用户显示插件 UI 和信息的位置的页面上

  • 整个应用程序的挂钩 – 每当“有趣”事件发生时,系统会检查当前是否有任何插件订阅了此事件并调用/通知它们,然后显示结果。一些值得 Hooks 的事件示例可能是:

    • 占位符渲染 - 这将触发所有订阅的功能以显示前端/后端部分视图

    • 特定业务事件 – 例如每当新书被添加到目录或正在出售时

    • 管理菜单呈现 – 在此事件中,每个安装的插件都将选择 PLUGINNAME_AdminPluginMenu 表中的所有菜单项(插件应该在安装时创建此表)并将它们全部返回到用于显示的钩子。

我相信您会想到其他相关事件,因为您最了解自己的情况。


事物的实际方面(基于问题的第二次更新)

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){...}

结果在&lt;div&gt; 中,你会在执行动作后看到widget_orangebook 控制器设置的模板内容。

在某种意义上,它给人一种 AJAX 部分呈现的错觉,但它在服务器上执行而无需额外调用。它非常强大,我认为这是您描述的案例的方法。

您可以查看this tutorial 以查看有关您需要进行的所有修改的详细说明。它有点花哨 - 它是关于在一个小部件部分中呈现多个小部件,但它遵循相同的逻辑。

请注意,如果您坚持使用 mustache 和无逻辑模板,您也可以在控制器中进行这种 Request 调用,将结果设置为一个变量,然后将该变量传递给您的 mustache 模板。

2。 Kohana 模块

Kohana 支持模块,允许您以有组织的方式打包插件。当您实现更复杂的插件时,这将变得很重要。可以看more on Kohana Modules here.

【讨论】:

  • 很好的答案,但对我来说仍然不清楚。您的回答有点告诉我我已经知道的(我需要占位符/钩子),并且它是插件需要通过它们进行通信的那些。但在实践中我将如何做到这一点?请检查我的最新更新。谢谢!
  • 您好,感谢您的赞许!我试图在第二点中解释这一点,但我是在高层次上解释的,因为我担心它会变得太长。今天晚些时候,我将根据您的情况,用更详细的示例扩展描述。
  • @Karem,我按照承诺更新了我的答案,希望它能为你解决一些问题。如果您需要更多信息,请告诉我。
  • 嘿!哇太棒了!我现在想我明白了!我将在今天晚些时候阅读教程并跟进。目前我对 kohana 模块只有一件事,我已经在使用 kohana 模块并且它工作得很好(我的主要网络应用程序有一组模块)。但是当代码应该是“独立的”并且不应该连接到其他模块时,您认为 Kohana 模块如何与插件相关?
  • 嗨,卡雷姆!我很高兴你能掌握!关于模块:您可能拥有 Kohana 的可用模块之一。我的想法更像是在 Kohana 中创建自己的插件作为模块。这完全取决于您的实现,您不必将其连接到其他模块。请参阅 Kohana 用户指南中的模块部分(此处:kohanaframework.org/3.3/guide/kohana/modules)。它确实是非常简单和灵活的功能,开箱即用,可以帮助您更好地组织代码,而无需创建自己的插件目录。
【解决方案2】:

让我从头开始。

您要查找的内容称为service layer,应在您的应用程序中实现。它的作用是

用一层服务定义应用程序的边界 建立一组可用的操作并协调 应用程序在每个操作中的响应。

企业应用程序通常需要不同类型的 它们存储的数据和它们实现的逻辑的接口:数据 加载器、用户界面、集成网关等。尽管 它们的用途不同,这些接口通常需要通用 与应用程序交互以访问和操作其数据 并调用其业务逻辑。交互可能很复杂, 涉及跨多个资源的事务和协调 对一个动作的几个反应。编码的逻辑 每个界面中单独的交互会导致大量重复。

服务层定义了应用程序的边界 [Cockburn PloP] 和 从接口的角度来看它的一组可用操作 客户层。它封装了应用程序的业务逻辑, 控制事务和协调响应 执行其操作。

让我用简单的术语解释一下,以便您理解。您首先要做的是在您的应用程序中定义一个服务层。由于您使用 MVC,这可能是另一个控制器处理与此特定任务相关的所有请求。您可以为每对操作设置单独的控制器。最后,您的引擎将是这些控制器集。

如果您愿意更上一层楼,您可以通过 ESB(企业服务总线)处理所有这些集成。

企业服务总线 (ESB) 是一种使用的软件架构模型 用于设计和实现相互之间的通信 在面向服务的体系结构中交互软件应用程序 (SOA)。作为分布式计算的软件架构模型 是更通用的客户端服务器模型的特殊变体,并且 促进之间通信的敏捷性和灵活性 应用程序。它的主要用途是企业应用程序集成 (EAI) 异构和复杂的景观。

如果您需要更多信息,请告诉我。

更新

有详细记录的博客文章。请参阅下面的链接。

【讨论】:

  • 我将如何从现在的位置开始,使用服务层?您能否提供一个关于模块/服务如何将功能“集成”到主 Web 应用程序中的示例。另请阅读我的最新更新。
  • 请首先浏览更新后的链接并了解基本概念。然后,如果您有任何问题,请告诉我。我认为重新发布基本内容没有必要,因为它们有据可查。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-04-13
  • 2020-11-02
  • 2016-07-04
  • 2011-11-08
  • 1970-01-01
相关资源
最近更新 更多