6

我想知道您对如何使用 MVC（例如骨干网）在大型 Web 应用程序中组织文件/目录的看法。
我会做以下（*）。请告诉我你的意见。

( * )

js
js/models/myModel.js
js/collections/myCollection.js
js/views/myView.js
spec/model/myModel.spec.js
spec/collections/myCollection.spec.js
spec/views/myView.spec.js
4

2 回答 2

3

这就是我传统上组织文件的方式。但是，我发现对于较大的应用程序，让所有内容保持组织、唯一命名等确实变得很痛苦。我一直在做的一种“新”方式是按功能而不是类型来组织我的文件。因此，例如：

js/feature1/someView.js
js/feature1/someController.js
js/feature1/someTemplate.html
js/feature1/someModel.js

但是，通常有您需要的全局“事物”，例如“用户”或用户构建的位置集合。所以：

js/application/model/user.js
js/application/collection/location.js

向我建议这种模式是因为您可以使用 requirejs 轻松处理功能集、打包和部署它们。它还减少了功能集之间发生依赖关系的可能性，因此如果您想删除一个功能或使用全新的代码更新它，您可以只替换一个“stuff”文件夹，而不是寻找每个文件。此外，在 IDE 中，它只会使您正在处理的文件更容易找到。

我的两分钱。

编辑：规范文件呢？

一些想法 - 你只需要选择我认为对你来说最自然的一个。

  1. 您可以对规范文件遵循相同的“功能文件夹”模式。好处是所有规格都在一个地方。缺点是现在，就像您当前所做的一样，您必须为一个功能的文件放置位置。
  2. 您可以将规格放在功能文件夹的“规格”文件夹中。好处是您现在拥有可以打包在单个 zip 文件中的实际包，而不会破坏其他工作。为编写测试找到直接相关的文件也更容易——它们都在同一个父文件夹中。缺点是现在您的生产代码和测试代码在同一个文件夹中，将其（可能）发布到世界各地。当然，您可能最终会在某个时候将生产 javascript 编译成一个文件。所以我不确定这是一个很大的问题。
  3. 我的建议 - 如果这是一个大型应用程序，并且您认为您将有几只手接触文件，请在文件夹中保留类似“package.json/yml/xml”的文件。在那里，列出测试所需的生产、规范和任何数据文件（您很可能可以编写一个快速的 shell 脚本来为您执行此操作）。然后编写一个快速脚本来查看您的源文件夹中的“package.whateverYouChose”文件，获取测试文件，然后使用它构建您的单元测试页面。因此，假设您添加了另一个包.. 运行“updateSpecRunner”或您命名脚本的任何名称，它会为您生成另一个 SpecRunner.html 文件（或您命名的运行规范的文件）。然后你可以在浏览器中手动测试它，或者使用 phantomjs/rhino 自动化它。

那有意义吗？

于 2012-05-25T13:45:44.510 回答
1

你可以找到一个很好的例子来组织你的应用程序到这个链接

骨干茉莉花示例

它看起来或多或少像您的实现。

于 2012-05-25T14:35:12.950 回答