项目组织和命名约定

Question

这有点是Repeating module name for each module component问题的后续行动。

我们已经决定遵循Best Practice Recommendations for Angular App Structure博客文章角度项目组织和命名惯例中的建议，同时构建一个用于衡量连接质量的小型内部应用程序。

这就是我们目前所得到的：

$ tree -L 1
.
├── app-config-service.js
├── app-config-service_test.js
├── app-connection-service.js
├── app-connection-service_test.js
├── app-controller.js
├── app-controller_test.js
├── app-countdown-directive.js
├── app-countdown-directive_test.js
├── app-footer-directive.js
├── app-footer-directive_test.js
├── app-footer-service.js
├── app-footer-service_test.js
├── app-math-service.js
├── app-math-service_test.js
├── app-stats-directive.js
├── app-stats-directive_test.js
├── app-status-directive.js
├── app-status-directive_test.js
├── app-status-service.js
├── app-status-service_test.js
├── app-time-directive.js
├── app-time-directive_test.js
├── app.css
├── app.js
├── bower_components
├── config.json
├── countdown.html
├── footer.html
├── img
├── index.html
├── ping
├── stats.html
└── status.html

正如您所看到的，有几个指令，服务，部分，单个控制器，模块声明文件以及与主题文件无关的配置和应用程序特定。这实际上变成了一堆乱七八糟的文件，并且不易读取且易于使用。

这可能是因为我们只有一个模块并且将所有内容保存在其中。

对于这样一个简单的应用程序，是否可以使用旧的面向组件的方法并为services，controllers，directives和partials设置特殊目录？这是否意味着新的＆＃34;按功能组织＆＃34;方法只适用于非平凡的大型应用程序？

Answer 1

你说你决定“按照Best Practice Recommendations for Angular App Structure博客文章中的建议”，但你似乎没有遵循它......

---

根据推荐的方法，每个组件/功能都应位于其自己的目录中（在components目录下）。

由Gil Birman指出的原因以及前面提到的blog post以及Repeating module name for each module component中详述的原因，按功能组织目录更有意义（例如{{ 1}} - 功能目录包含与该功能相关的所有指令，服务，控制器，部分等），而不是按类型组织（例如，一个目录中的所有控制器，另一个目录中的所有服务）等。

---

在任何情况下，以上所有都是指导方针（更多的是一种思考方式），而不是精确的配方或确定性算法，可以决定你在哪里放置每个文件（例如，是否会有{{1}目录，服务是否会进入功能目录或foo目录下等。） 您需要了解指南（以及尝试实现的目的/需求）并制定适合您团队风格的惯例。

有时您无法确定放置文件的位置。你可以与团队进行辩论，做出决定并坚持下去。 这是完全正常的（特别是在开始时），但你会发现随着时间的推移，这种情况会越来越少。

---

那就是说，我希望你的目录和文件结构更像那样（做一些关于哪些服务可能更通用/类似实用程序的假设）：

components/lib/

Answer 2

模块化架构模仿我们的大脑如何运作

即使对于一个小项目，我仍然会将项目分成 module 文件夹，原因很简单，因为它使更容易找到您需要处理的代码。那是因为我们程序员通常在每个模块的基础上工作。

例如，我们将在一小时内处理页脚模块，其中包含将驻留在footer目录中的指令和服务。相比之下，我们不太可能决定在一小时内我们必须处理指令文件夹中的各种指令，并且从不接触任何服务。

模块化架构可以更轻松地跨项目翻录代码

当我开始一个新项目时，无论项目的大小如何，我通常都是从现有项目中删除模块开始的。采用模块化架构，非常简单直观。

当然，如果一个模块是高度可重复使用的，你应该把它打包成一个凉亭模块，但大多数小模块最终会按照每个项目进行定制。

Answer 3

首先，我建议坚持使用 yeoman 生成器提供的项目组织： http://yeoman.io/

它使用面向组件的方法;并提供多个生成器，将代码放在预期位置，为它们生成单元测试，保持文件名模式，设置 grunt build 描述等。

示例项目结构如下所示：

使用结构方法即使是简单的应用程序也是值得的。将有很多可能在代码库中创建一个混乱，所以更好地开始整齐:)问题可以到达规模的另一端 - 同时你可能需要更多然后只是一个模块，标准的自耕农发电机不能很好地支持它。

Answer 4

正如ExpertSystem所述，您当前的目录结构与博客Best Practice Recommendations for Angular App Structure无关。

我与ExpertSystems以及Gil Birman合作，设计应用程序结构的方法应该是模块化的。如您所知，Angular本身遵循模块化结构，因此无论您是拥有多个模块还是单个Angular模块，您都需要根据您所服务的功能进行思考。例如，如果你有一个＆＃39; CountDown＆＃39;功能它应该有自己的结构。

为什么这很重要？

<强> 1。代码维护：随着代码的增加，您的维护成本也会增加。例如，如果在生产环境中，您的角度代码出现错误，并希望使用1小时的KRA进行纠正，则首先需要在本地复制场景，然后遍历该特定文件。如果它是模块，你会知道要定位哪个文件夹，并且你可以快速获得解决方案。

<强> 2。开发轻松：您可以在多个开发人员之间拆分多个功能，他们可以定位不同的功能文件夹，以便他们不会触及相同的文件。合并冲突可以减少。

第3。更快的评论：由于应用程序被分解为功能，因此可以更快地完成评论，并且可以轻松地知道该文件夹的代码是针对该特定功能的。

<强> 4。 TDD实施：该结构可用于启动测试驱动开发（TDD）。此article

中提到了TDD的好处

开发和生产代码/结构之间的差异

在开发中，您可以根据功能获得结构。但是，为了提高Web应用程序（或混合移动应用程序）的性能，最好的方法是连接所有文件，缩小它并使用GRUNT对其进行模糊处理。将给出相同的GRUNT文件样本。您可以使用任何持续集成工具（例如Jenkins）在每次部署期间运行该脚本。

Answer 5

我更喜欢在顶级基于特征（模块）的方法中组织我的项目，在较低级别上基于类型（指令，控制器）组织我的项目：

在这个例子中，我有3个独立的（根）模块回家，搜索和共享。这些模块是我的应用程序的根部分。每个模块可能包含指令，服务，视图，较少的文件等。一般来说，我更喜欢尽可能地保持我的应用程序的相关部分。这就是我将新闻指令的每个部分分组到新闻文件夹中的方式。但请记住，此新闻指令仅用于我的家庭模块。如果它将用于多个模块（主页和搜索），那么我将把新闻文件夹移动到共享文件夹中。

这是与此问题（Repeating module name for each module component）基于前缀的方法类似的方法，但我使用文件夹而不是前缀。

Answer 6

启动项目时，不仅要考虑文件结构。我建议你考虑如何创建模块以及如何注入依赖项，以及如何缩小应用程序。

github.com上的Angular样板文件是一个样板项目，它允许您使用grunt构建应用程序，使用bower进行depandancies，实时重新加载浏览器并允许您使用LESS而不是CSS。

它包含一个这样的起始结构：

ng-boilerplate/
|- grunt-tasks/
|- karma/
|- src/
|  |- app/
|  |  |- <app logic>
|  |- assets/
|  |  |- <static files>
|  |- common/
|  |  |- <reusable code>
|  |- less/
|  |  |- main.less
|- vendor/
|  |- angular-bootstrap/
|  |- bootstrap/
|  |- placeholders/
|- .bowerrc
|- bower.json
|- build.config.js
|- Gruntfile.js
|- module.prefix
|- module.suffix
|- package.json

它还包含有关如何设置所有内容的指南。快乐的黑客！

https://github.com/ngbp/ngbp