哪种Web应用程序模块化结构更好？

Question

backend/
     module1
     module2
     module3

frontend/
     module1
     module2
     module3

或者

modules/
       module1/
              frontend               
              backend
       module2/
              frontend               
              backend
       module3/
              frontend               
              backend

- simple

---

第一个版本看起来更简洁，因此更美观，所以会更好；顺便说一句，第一个版本似乎是“面向范围”的，听起来不错。 - rubber boots

Answer 1

根据您提供的信息，我会选择第二个选项。这样，我就知道模块及其所有依赖项都驻留在此文件夹中。删除此文件夹，模块就会消失。如果您需要更新/禁用/替换模块，则仅更新一个文件夹很方便。

但是，如果模块不是100％独立的，并且在某些情况下依赖其他模块，则我会选择第一个选项。

- Vidar Vestnes

Answer 2

这其实完全是个人选择。我把我的系统构建成了将后端代码与前端隔离开来，这样我就可以严格而精确地控制网站数据被编辑的时间和地点，但这只是我的方法。就我个人而言，我并不认为其中一种方式一定比另一种更好；只要你保持一致，无论哪种都可以。

- Nathan Taylor

Answer 3

许多框架采用类似于您第一种方法的方式。对于团队开发来说，这种方式非常有效，因为前端开发人员可以更容易地被隔离（使用SVN等工具）到前端目录中。

- webbiedave

---

Symfony PHP框架宽松地遵循第一种选择。我认为这更好，因为只有一个部门，而不是几个子部门。 - Christopher Altman

Answer 4

选择取决于您想要实现什么。第一种架构是分层的，第二种是组件化的。MVC与组件（如桌面GUI等）之间也存在类似的争论。层使您能够逐层隔离模块，这意味着您可以在现有层上构建。这也用于IO / OSI TCP / IP堆栈中。另一方面，组件更加细粒度，可以直接重用 - 例如，您可以从“小部件”组合桌面GUI。那么对于Web来说哪个更好？从主流来看，即MVC，第一层架构似乎被更多地使用。也许这个问题与询问asp.net是否比sp.net mvc更好有关...

- Gabriel Ščerbák

Answer 5

如果您要跨越两个物理层（Web 服务器和业务服务器）部署应用程序，选项1可能是最适合的。这样部署（如复制式部署或基于安装的部署）会更容易配置或运行。

我喜欢选项2的易维护性，您可以轻松地告诉开发人员去处理“模块A”，所有他们需要的代码都在一个地方。

基本上，这完全是您和团队的偏好。我已经使用过两种方法，这取决于您的环境，如开发人员数量和部署策略等因素。

- Mike Ohlsen