代码之家  ›  专栏  ›  技术社区  ›  Agora

使用zend框架创建灵活的基础应用程序

  •  2
  • Agora  · 技术社区  · 15 年前

    我们正在利用zend框架开发一个电子商务平台。我们有几个应用程序实例正在运行,使用相同的代码库。配置设置用于区分不同的商店。

    我们面临的挑战是,我们希望保持通用平台现在的样子,并对其进行扩展,而不是使用上面概述的配置方法。通用平台(或基础应用程序)应包含通用控制器、模型和视图。特定于特定实例的自定义功能(控制器、模型和视图)应包含在单独的扩展中,并以插入核心平台的方式进行。这样,共享代码库就保持干净,不会过度膨胀。

    有没有人有这种方法的经验?有什么最佳实践吗?

    任何指点都非常感谢!

    3 回复  |  直到 13 年前
        1
  •  2
  •   simonrjones    15 年前

    我最近一直在我的代理机构研究同样的问题,我目前正在测试的解决方案涉及以下应用程序文件夹结构:

    app/
        default/
                controllers/
                models, etc
        ecommerce/
                  controllers/
                  models, etc
    lib/
        S24/
            ComponentCode.php
    modules/
            ecommerce/
                      admin/
                            controllers/
                            models, etc
                      default/
                              controllers/
                              models, etc
    data, public web, temp, other ZF folders
    

    其思想是通用组件代码存储在 lib ,模块化应用程序存储在 modules 个人客户网站代码存储在 app .

    这个 lib/S24 modules/ecommerce 文件夹将是通用的,每个项目都是相同的(我们将这些文件夹放在外部)。

    应用程序 是一个模块目录,所以 default ecommerce 文件夹在zf中创建模块。 app/default 用于默认(即无模块)控制器。 app/ecommerce 将包含一组控制器,这些控制器仅在 modules/ecommerce/default/controllers .

    然后,可以在 app/ecommerce/controllers 如果您愿意,或者添加新功能。

    由于我们希望保持模块管理系统不变,并且还支持多个管理系统(在URL中,如www.domain.com/admin/ecommerce和www.domain.com/admin/user),因此我们直接从 模块 文件夹。然后可以添加任何自定义管理页。 app/admin/controllers .

    // Add Controller folder
    $front->addControllerDirectory('/path/to/modules/ecommerce/admin/controllers', 'ecommerceAdmin');
    
    // Add route
    $router->addRoute(
        'ecommerceAdmin',
        new Zend_Controller_Router_Route('admin/ecommerce/:controller/:action',
                                         array('module' => 'ecommerceAdmin', 
                                               'controller' => 'index',
                                               'action' => 'index'))
    );
    

    正如我所说,我目前正在测试这个,但我希望它能给你自己的系统一些想法。一旦我完全稳定下来,我希望能写一篇关于这个话题的博客文章。

        2
  •  0
  •   David Snabel-Caunt    15 年前

    我们将软件作为服务应用程序进行操作,听起来与您的平台类似,在我们的例子中,所有实例数据都存储在实例自己的数据库中。

    至于处理自定义功能(代码),如果它完全被定制,那么我认为将定制代码模块化或打包到容器中是有意义的,该容器可以由客户的唯一标识符引用,并按需加载代码。对于模块来说,这很简单,但如果您需要单独的控制器甚至操作,则显然更为复杂。

    有些系统在自己的事件/回调系统中构建,允许注入功能,尽管这在公共api中更为常见。

        3
  •  0
  •   Community Marks    7 年前

    编辑:我没有注意到各种各样的评论。因此,定制的代码不在一个包中,它添加了功能并且不重写。

    这里的问题是,您提到的代码没有覆盖任何内容,而是添加了功能。你可能会看到某种形式的插件系统,在那里你会读到一个带有类名的配置文件。这些类将提供关于每个插件的信息(即,如果您的ui使用tab s,它将有一个tab名称的属性)。

    这实际上取决于每种实现的不同功能。有更多的信息来提供高层次的解决方案可能会有帮助。

    我使用php autoload的方式(请参见: How does OOP manage to 'include' classes stored in different files )根据类名创建单独的文件夹。这可能有助于将代码与其他实现分离。