原文链接：http://www.infoworld.com/article/3204205/node-js/7-keys-to-structuring-your-nodejs-app.html

为了易排查故障、维护和扩展你的Node.js app，此文章提供以下的建议让你考虑。

Node.js 正迅速赶上Java, Ruby, Python 和 .Net的步伐，成为开发新的网络app的偏好语言。Node.js的团队每天都在优化JavaScript，让产品的运行时（runtime）更好、更快、更稳定。与此同时，用户社区也正在飞速增长着。

随着Node.js的走红，越来越多的开发者将踏上Node.js的学习曲线，也将共同面对一些相似的问题以及编写对应的功能。好消息是，针对这一点，Node.js社区已经建立了一些体系和设计模式。它们不仅可以解决一些共同的问题，也助于构建app。

通常实施MV模式，例如模型-视图-控制器 (model-view-controller, MVC), 模型-视图-视图模型 (model-view-viewmodel, MVVM), 模型-视图-表示层(model-view-presenter，MVC), 或者只是 MV。架构也能告诉你模型（models）、视图（ views）和控制器（controllers）的代码应该在什么地方，你的路线（routes）应该在什么地方，以及你应该在哪里添加上你的配置。很多年轻的开发者和Node.js爱好者并不完全了解设计模式或者OOP(Object Oriented Programming)图像如何与他们app代码的一行行及结构相对应。

这时候就需要例如Express.js 和 Sails.js 的Node.js体系了。这些架构的都可以帮助推动网络app的开发。不管你用什么体系，在组织你的app的时候，你得考虑一些因素。

下面是我在筹划一个Node.js app时候会考虑的七个关键点。

1. 针对app的正确目录结构 在决定app的目录结构时，你应该考虑所选的设计模式。这能够帮助更快的上手、寻找代码以及隔离问题。我个人倾向于在组织一个Node.js app的时候使用一个MVC模式。这帮助我更好地开发，也提供了为同样的数据创建不同视图（views）的灵活性，以及异步交流和MVC组件之间的隔离。而以上提及的只是众多好处中的几个罢了。

我推荐使用上图显示的目录结构。它是在Ruby on Rails 和 Express.js两者结合的基础上建立的。

2. 将ER图像与模型进行匹配 正如 Techopedia中所定义的那样：“一个ER图像（ERD）是一种数据建模技术，它以图像的形式展示了一个信息系统的实体（entities）以及这些实体之间的关系。”一个ER图像概述了各式各样将参与我们系统的实体，并这样定义它们之间所有的交互： 任何抽象或者物质的“事物”都成为了模型中的一个实体 一个模型与我们数据库中的某个图表相对应 某个实体的性质或属性转换为了模型的一个属性，而该属性转而成了一个表中的一个列

例如，你的实体是一个用户，那么与之相对应的模型就是“用户”。这模型的属性包括数据库中的姓、名和地址以及某个相对应的表格和列。

通过运用一个简单的数据结构，你就能够更轻松地在一个新的schema被创建时跟踪你的数据库和文件扩展了。

3. 使用MVP模式 实施MVP不只是指为控制器、视图和模型创造文件夹。你还需要根据MVC去划分你的编码和逻辑。你模型中的代码应该严格限制于数据库schema的定义。开发者们通常忘记了一件事——模型同样含有执行CRUD操作的代码。而且，任何特定于某个模型的函数（function）或操作都应该存在在这个文件里面。大多数关乎某个模型的业务逻辑应该显示在这个文件里面。

一个常见的错误是把所有的业务逻辑放进控制器中。控制器应该只用于在模型或其他组件中触发函数；在组件之间传输数据；以及控制请求的流程。视图文件夹则与之相反——它应该只存有把对象（objects）转换为人类可读形式的代码。任何像数据格式化、排序及过滤的逻辑都不应该在视图里面执行。视图的整洁不仅可以提供一个更佳的用户体验，也能帮你在不改变其他组件的情况下切换视图。

4. 把逻辑分解成模块 作为开发者，我们总是被告知应该把代码整理成文件以及模块。但这并不意味着我们应该使劲把整个app都塞进一个文件。将你的代码根据逻辑及作用进行划分才是最佳操作。将关乎某个实体或者对象的函数分类到一个单独的文件中，以及将目录的结构根据逻辑进行整理具有许多优势。首先，在决定聚焦哪个函数来修理某个故障的时候，它能节省大量的时间。其次，它能帮助分离结构中的所有组件，这样子，我们能够在不改变其他任何一条代码的情况下，替换掉不相关的功能。第三，它有助于编写测试用例。

5. 测试用例（test cases）的重要性 在建立测试用例的时候，含糊马虎是最忌讳的，因为测试就像是你代码库的保卫者。随着你的app日益壮大，要记住编写代码时所有需要囊括的场景也就更加困难了。测试用例有助于保持你的代码库的稳定。测试能够防止衰退，也就能节省掉珍贵的开发时间和精力。它能够确保新的功能能推行得准确无误。它也能通过在正式生产前捕捉故障的方式，来改善代码的质量。最重要的是，测试能够给予“代码不会崩溃”的信心。

6. 日志记录的重要性 日志记录有利于调试以及了解app的状况。它们能为app的行为提供宝贵的见解。下面简单列举了利用日志时的注意事项： 在日志记录时，找到正确的平衡点。“过量的信息”并不是一件坏事，但过度的日志记录会让你的工作更艰难。针是更容易在小的干草堆里面被找到的。相反地，过少的日志记录会导致存有过少的信息，也就会给排除故障和诊断增加难度。 把线上和线下的日志分开。然后在那里把最近的记录整理出来，以便更快的调取查看及处理。而那些更早的日志则应该进行存档或者转存为文件。 考虑一下日志的使用频率和时长，因为它会影响你所需的存储容量。通常情况下，你所需的存储容量是与你日志的数量成正比的。

记住，不要将敏感信息（例如邮箱ID、密码、信用卡信息和电话号码）进行记录。这样做不仅是一个巨大的安全风险，而且很多时候它也是非法的。

7. app如何扩展？ 应用开发中的最要不得的方式便是考虑在你拥有流量后应该怎么进行扩展。你应该建立一个可以从一开始就选可扩展的结构，这样能够节省时间和提高效率。

扩展服务器并不是扩展；将负荷分配给不同的资源才是。但这并不意味着你不该在负荷增长的时候生成新的服务器。首先，你应该在你现有资源内布置一个负荷平衡，以此来应付负荷扩展。当这个负荷平衡机制不能有效率地处理工作量的时候，我们就可以进行横向的规模增长和生成新的服务器。你可以通过一个独立的进程或使用模块来做到这一点。每个进程或模块都会单独、独立地进行工作。这不仅可以帮助你的app更有效率地扩展，也能使你的系统更能经受住故障和更快地恢复正常。 如何构建一个网络app就跟选择正确的技术一样重要。如果基础都有缺陷，那么app最终会崩溃、或无法扩展、或在某些情况下根本无法启动。如果没有适当的规划和结构，急匆匆地开发新的功能或新的主意显然是不妥的。一个坏的建筑或结构就像一个定时炸弹，是随时可能爆炸的。