多个Zend应用程序代码组织


10

在过去的一年中,我一直在研究一系列基于Zend框架的应用程序,并集中于一个复杂的业务逻辑,即所有应用程序即使不使用全部也必须具有访问权限(比每个应用程序具有多个库文件夹更容易)应用程序,因为它们都通过一个公共中心链接在一起)。

在不深入讨论项目具体目的的情况下,我正在寻找一些有关如何“分组”我的代码的输入(因为我正在单独处理项目)。我试图将其拆分为尽可能消除依赖项的方式。

我试图在逻辑上尽可能地保持分离,因此在12个月的时间内,其他任何人都可以毫无疑问地扩展我的作品。

示例结构:

applicationStorage\ (contains all applications and associated data)
applicationStorage\Applications\ (contains the applications themselves)

applicationStorage\Applications\external\ (application grouping folder) (contains all external customer access applications)
applicationStorage\Applications\external\site\ (main external customer access application)
applicationStorage\Applications\external\site\Modules\ 
applicationStorage\Applications\external\site\Config\
applicationStorage\Applications\external\site\Layouts\
applicationStorage\Applications\external\site\ZendExtended\ (contains extended Zend classes specific to this application example: ZendExtended_Controller_Action extends zend_controller_Action )
applicationStorage\Applications\external\mobile\ (mobile external customer access application different workflow limited capabilities compared to full site version)

applicationStorage\Applications\internal\ (application grouping folder) (contains all internal company applications)
applicationStorage\Applications\internal\site\ (main internal application)
applicationStorage\Applications\internal\mobile\ (mobile access has different flow and limited abilities compared to main site version)

applicationStorage\Tests\ (contains PHP unit tests)

applicationStorage\Library\
applicationStorage\Library\Service\ (contains all business logic, services and servicelocator; these are completely decoupled from Zend framework and rely on models' interfaces)
applicationStorage\Library\Zend\ (Zend framework)
applicationStorage\Library\Models\ (doesn't know services but is linked to Zend framework for DB operations; contains model interfaces and model datamappers for all business objects; examples include Iorder/IorderMapper, Iworksheet/IWorksheetMapper, Icustomer/IcustomerMapper)

(注意:Modules,Config,Layouts和ZendExtended文件夹在每个应用程序文件夹中都是重复的;但是我已将它们省略,因为出于我的目的它们不是必需的。)

对于库,它包含所有“通用”代码。Zend框架是所有应用程序的核心,但是我希望我的业务逻辑与Zend框架无关。所有模型和映射器接口都没有对Zend_Db的公共引用,但实际上将其私有包装。

因此,我的希望是,将来,如果我想将业务逻辑(服务)移动到一个数据库,则我将能够重写映射器和dbtables(包含扩展Zend_Db_Table_Abstract的Models_DbTable_Abstract),以便将业务逻辑与Zend框架分离。非Zend框架环境(也许是其他一些PHP框架)。

通过使用serviceLocator并在每个应用程序的引导程序中注册所需的服务,我可以根据请求和访问哪个应用程序来使用同一服务的不同版本。

示例:所有外部应用程序都将注册一个service_auth_External实现service_auth_Interface。

与内部使用Service_Auth_Internal实现service_auth_Interface Service_Locator :: getService('Auth')的应用相同。

我担心这可能会遗漏一些可能的问题。

我半想着的是一个用于所有外部设备的config.ini文件,然后是一个覆盖或添加到全局外部config.ini的单独的应用程序config.ini。

如果有人有任何建议,我将不胜感激。

我已经在单个应用程序中为AJAX功能使用了上下文切换功能,但是内部和外部都有很大的机会为它们创建Web服务。同样,由于授权和不同的可用服务,这些将被分开。

\applicationstorage\Applications\internal\webservice 
\applicationstorage\Applications\external\webservice

Answers:


1

最终,某些代码将特定于您应用程序的“业务逻辑”,而某些则是“库代码”。例如,验证表单输入的内容通常可以被视为“库”,而可以帮助您计算给定月份内客户X可用报价的内容显然是“业务逻辑”。

这更多的是版本控制问题,并且有很多方法可以使这只猫变皮。诸如Maven之类的工具(在某种程度上还包括Phing / Ant)是根据各种外部配置文件(通常为XML)从各种不同的来源组装应用程序而构建的。这意味着您可以为代码维护单独的存储库,并在需要时将其导入到Application X中。

如果您可以控制主机,则可以考虑将库内容移入包含路径-并将其作为单独的长期项目进行维护。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.