在过去的几周里,我看到了一些Zend Framework 2项目。在比较它们时,我注意到它们基本上都遵循相同的结构:
名为application
的模块处理网站的所有操作 - "前端逻辑"对于应用程序的不同部分(如新闻帖子,用户个人资料,电子邮件设置等)。
对于应用程序的每个部分,至少有一个模块,但只包含"后端逻辑" (添加新闻,删除用户等)。
我认为它们都建立在Zend Framework 2 Skeleton Application之上。
这是最佳做法还是有关于如何构建应用程序的任何其他常见或推荐模式?为什么我不能写一个包含后端&的新闻帖子模块?前端部分?
此外,我应该如何模块化我的模块 - 我的意思是可以将简单的功能分散到几个模块中,但这样做可能并不总是明智的。有没有指标?
答案 0 :(得分:3)
这是最佳做法还是有其他常见或推荐 关于如何构建应用程序的模式?
答案是否定的, Zend Framework 2应用程序没有预先设定的结构,与ZF1相反。您可以自由定义适合您需求的结构。这是由Zend\Loader\StandardAutoloader构建通过将该命名空间的基目录路径添加到类名称而引用的类的路径,然后包含该类。因此,可以根据需要组织应用程序文件夹目录的结构。
骨架应用程序使用的这个标准结构只是ZF2团队的推荐。如果您认为您的需求最适合不同的结构,那么您没有义务遵循它。
zf2application
├── config
│ ├── application.config.php
│ └── autoload
│ ├── global.php
│ └── local.php.dist
├── data
│ └── cache
├── init_autoloader.php
├── module
│ └── Application
├── public
│ ├── css
│ ├── images
│ ├── index.php
│ └── js
└── vendor
├── ZF2
└──init_autoloader.php
Zend团队定义和推荐的模块结构尊重PSR0标准。您可以添加具有与推荐结构不同的结构的模块,但除了PSR0标准之外,您还必须遵守一些规则,以及模块根目录中的module.php
文件。
你可以在Rob Allen的帖子中阅读更多内容:Thoughts on module directory structure,它解释了如何在尊重推荐标准的同时更改模块目录结构。
另外,我应该如何模块化我的模块?
模块是重组应用程序的一个或多个功能(前端/后端/设计)的组件。使用模块的主要优点是它们可以分离您的代码,并且可以在许多其他应用程序中重复使用。记住这个想法,你将能够知道何时应该创建一个模块,什么时候不应该。
你也可以参考how to write better Zend Framework 2 modules上的这篇优秀文章。
答案 1 :(得分:0)
这仅仅取决于开发人员的个人偏好。骨架应用程序只从一个名为“Application”的模块开始,这就是为什么你会看到很多。它不是必需的 - 我通常将它重命名为更合适的东西。
您可以根据需要组织模块。您当然可以创建一个具有前端和后端功能的新闻模块 - 以适合您应用程序的任何方式构建它们。
在考虑如何制作“模块化”时,请考虑您是否可能希望将来在其他项目中重用该功能。如果是,那么将它变成自己的模块可能是有意义的。