改进 Meteor 应用程序中项目结构的开发人员指南

在过去的几年里，可用的 JavaScript 框架的数量急剧增加。 从久经考验的 AngularJS 到每月发布的大量框架，有令人印象深刻的多样性可供选择。 几年前引起我注意的是一个名为 Meteor 的框架。 与大多数框架不同，Meteor 旨在成为 JavaScript 应用程序开发的完整平台。 对于那些不熟悉 Meteor 的人，我鼓励您在他们的网站上查看。 本文不会是 Meteor 的介绍。 相反，我们将探索一些在 Meteor 项目中引入结构的简单方法。

Meteor 的一大好处是可以很容易地用它来快速制作复杂的 JavaScript 应用程序原型。 因为 Meteor 是前端模板和渲染的混合体，再加上与 MongoDB 交互的基于节点的服务器（一个统一的解决方案），所以创建全栈 Web 应用程序所需的大部分初始设置已经为您完成。 但是，这提供的开发便利性可能是一个陷阱。 在构建 Meteor 应用程序时，很容易陷入不良实践并最终得到一堆乱七八糟的非结构化代码。 对于如何避免这种情况，我有一些建议。

脚手架：Meteor 中的可管理目录层次结构

首先，在构建应用程序时保持推荐的文件夹结构很重要。 默认情况下，Meteor 允许您将文件放置在项目文件夹中的任何位置 - 如果您愿意，您甚至可以将所有代码放在一个文件中。 虽然这可能适用于黑客马拉松项目，但如果没有健全的结构，通常生产级、可扩展的应用程序所产生的复杂性很难管理。

为了解决这个问题，我建议查看 Chris Mather 的 npm 包 Iron。 该包具有多种配置选项，因此很难在此处描述，但通常它构建的项目结构如下所示：

 my-app/ |- .iron/ |- config.json |- bin/ |- build/ |- config/ |- development/ |- env.sh |- settings.json |- app/ |- client/ |- collections/ |- lib/ |- stylesheets/ |- templates/ |- head.html |- lib/ |- collections/ |- controllers/ |- methods.js |- routes.js |- packages/ |- private/ |- public/ |- server/ |- collections/ |- lib |- methods.js |- publish.js |- bootstrap.js

但是，对于某些项目来说，像这样的文件夹和文件结构可能是多余的。 并不是每个项目都需要这种细粒度的组织级别，在服务器上对集合、方法和发布代码进行分离。 对于那些没有太大项目或者只是不想安装和学习另一个 npm 包的人，我推荐这个基本的文件夹结构：

关键元素是一个公用文件夹，其中包含您的网站图标和其他静态资产等文件，以及客户端、公共和服务器文件夹。 客户端和服务器文件夹（当然）应该包含分别在客户端和服务器上执行的代码。 公共文件夹包含客户端和服务器都必须可以访问的代码。 Schema 代码就是一个例子，我们稍后会讨论。

有两种方法可以进行最低级别的组织：一种是按文件类型，第二种是按功能。 按文件类型组织意味着在您的客户端/模板文件夹中，例如，您将拥有三个文件夹 - 一个用于 JavaScript 文件，一个用于 CSS，一个用于 HTML。 HTML 文件夹将包含您的所有模板 HTML 文件，例如 Login.html、Main.html 等。 JavaScript 和 CSS 文件夹将分别包含其类型的模板文件。 另一方面，按功能组织意味着按文件所体现的概念进行组织。 例如，在客户端/模板中，我将有一个“登录”文件夹，其中包含与应用程序登录过程相关的所有 JavaScript、CSS 和 HTML 文件。 我更喜欢按功能组织，因为它可以让您更清楚地知道在哪里可以找到某些文件或代码片段。 然而，这并不是纯粹的黑白，大多数个人和团队都会尝试混合使用这些方法来构建他们的文件和文件夹。

Schema：即使您的数据库不需要，您的应用也需要它

我想讨论的第二种结构与数据库相关联。 本文假设您使用的是 MongoDB。 如果你不是，这些概念可能仍然适用，但细节不会。 使用 MongoDB 的人知道，它允许我们存储数据的方式是非结构化的。 由于 MongoDB 是一个 NoSQL 文档存储数据库，因此对于任何“类型”的数据都没有固定的模式。 这种自由意味着您不必担心确保所有对象都标准化为某种严格的形式，事实上，如果您愿意，您的应用程序的所有数据都可以放入单个集合中。 然而，当谈到制作生产质量的应用程序时，这并不是那么理想。 为了管理这一点并添加有用的功能，例如验证写入请求，我们可以求助于两个出色的 Meteor 包：Aldeed 的 SimpleSchema 和 Collection2。

顾名思义，SimpleSchema 包允许您响应式地验证应用程序中的对象。 查看 GitHub 上的文档。 Collection2 包从 SimpleSchema 引导，并允许您将适当的模式带入 Meteor 集合。 这可以自动验证客户端和服务器端对任何附加了模式的集合的写入请求。 这两个包都非常深入且可定制，因此很难在几段中完全理解它们。 相反，我建议您查看 Aldeed 为具体细节编写的详细自述文件。 我将简单谈谈我是如何从这些软件包中获得价值的。 他们启用的最好的事情之一是验证用户的表单输入。 这对于验证 Meteor 用户文档（来自 Accounts 包）非常有用。 默认情况下，Meteor 用户有一个非常复杂的隐式模式。 这是 Aldeed 提供的代码中的一部分图片：

 Schema.UserProfile = new SimpleSchema({ firstName: { type: String, optional: true }, lastName: { type: String, optional: true }, birthday: { type: Date, optional: true }, gender: { type: String, allowedValues: ['Male', 'Female'], optional: true }, organization : { type: String, optional: true }, website: { type: String, regEx: SimpleSchema.RegEx.Url, optional: true }, bio: { type: String, optional: true }, country: { type: Schema.UserCountry, optional: true } });

这只是用户配置文件对象的架构。 如果没有像 SimpleSchema 这样的专用包，尝试验证所有 User 对象将是一团糟。 虽然所有这些字段在图片中都是可选的，但如果您想要一个经过适当验证的用户模式，它们可能不会，并且诸如“Schema.UserCountry”之类的内容实际上会重定向到其他模式进行验证。 通过将此模式附加到 User 对象并将其反应性地集成到我们的表单中，也许使用像 Aldeed 的 AutoForm 这样的包，我们可以很好地控制哪些内容进入我们的数据库，节省时间和精力在我们的应用程序中如何处理数据的概念模型，可以指出并以具体术语进行讨论。

角色：适用于 401 和 403

我对构建和改进 Meteor 项目的最后建议是 Alanning 的 Roles 包。 这是 Meteor 的授权系统，它允许您检查 Web 应用程序任何部分的用户访问级别。 权限以字符串的形式附加到用户配置文件中，稍后当用户尝试访问发布到客户端的任何 Meteor 方法或数据时，这些权限将被验证或失效。 例如：

 if (Roles.userIsInRole(Meteor.userId(), "admin")) { tabsArr.push({ name: "Users", slug: "users" }); }

尽管系统的核心相对简单，但它允许对应用程序的任何部分进行复杂且细粒度的权限。 由于所有角色都存储为字符串，因此您可以设置一个任意深度的系统 - “admin”、“admin.division1.manage”、“admin.division1.manage.group2”等。

这个包允许的自由度的问题是很难跟踪高度精细的角色系统。 该包确实提供了诸如“getAllRoles”之类的功能，顾名思义，它检索您创建的所有角色，但由您来跟踪它们的所有含义以及给定角色何时应该使用。 对于那些好奇“角色”和“权限”之间有什么区别的人来说，就这个包的目的而言，它们本质上没有什么不同。

包起来

不幸的是，由于文章的广度（这里提到的每个包都应该有自己的教程），不可能详细介绍任何特定的包，但我希望我能阐明如何努力实现“标准化” 您可以放心的 Meteor 应用程序将在生产和规模化中运行良好。 如果您正在寻找更多信息，请查看我发布的链接并查看本文中没有包含但在 Meteor 应用程序中有用的另一件事：Restivus 包，它允许您轻松为您的应用公开 REST API。

作为免责声明，我不是任何这些软件包的作者，如果我歪曲了任何软件包的任何功能或目的，我深表歉意。 感谢您的阅读，希望这篇文章对您有所帮助。 如有任何问题，请随时与我联系，或在下方发表评论。