php项目数据库控制器代码

by Alexandre Levacher

亚历山大·莱瓦彻(Alexandre Levacher)

如何为大型代码库组织Express控制器 (How To Organize Express Controllers For Large Codebases)

Three years ago, I started developing an Express.js API for a company. I wondered what could be the best controllers architecture to stay organized as the codebase grows.

三年前，我开始为一家公司开发Express.js API。 我想知道随着代码库的增长，保持组织良好的最佳控制器架构是什么？

Influenced by Sails or Rails and by my research, I came to create my own system. I did not want to overload my project using a complete framework like Sails, but rather pick lighter dependencies when needed.

受Sails或Rails以及我的研究的影响，我开始创建自己的系统。 我不想使用像Sails这样的完整框架来重载项目，而是在需要时选择较轻的依赖项。

So I created an organization system for the app’s controllers which I paired with a homemade loader. Since then, I improved both of them thanks to the experience I gained by implementing it on other projects.

因此，我为应用程序的控制器创建了一个组织系统，并与一个自制的加载器配对。 从那时起，由于我在其他项目中实现了这方面的经验，因此我对两者进行了改进。

Today, I’m confident enough with this method to share it, as the results are convincing.

今天，我对这种方法很有信心，可以分享它，因为结果令人信服。

From what I know, it’s used by a few large companies. It simplifies onboarding new developers as it makes the codebase easier to read.

据我了解，一些大公司正在使用它。 它简化了新开发人员的入职，因为它使代码库更易于阅读。

✅ Here’s how to set up a clean controllers architecture.

✅这是设置干净控制器架构的方法。

结构 (The Structure)

If you don’t anticipate the growth of your app, you’ll quickly have an unorganized codebase. I designed the organization method to have wide compatibility, which means that someday you’ll not be locked into a kind of use case you can’t solve with this method.

如果您不期望应用程序的增长，您将很快拥有一个无组织的代码库。 我将组织方法设计为具有广泛的兼容性，这意味着有一天您不会陷入使用该方法无法解决的用例中。

设置您的文件树 (Setup your file tree)

• Group routes in controllers控制器中的组路由
• Create folders for each controller为每个控制器创建文件夹

• Create a routing file in each controller which describes the path of each route, the method to call, its optionally associated middleware, and the restriction level.

  创建在其每一个描述了每个路由的路径 ，则该方法到呼叫，其任选地相关联的中间件，和限制电平控制装置的路由文件。

• Create a file for each controller's actions which contains the method to execute and the middlewares.

  为每个控制器的操作创建一个文件，其中包含要执行的方法和中间件 。

• Create a spec file for testing

  创建规格文件进行测试

Let’s see how it looks.

让我们看看它的外观。

Don’t be afraid to create a lot of files. It does not slow down the development, and it makes your codebase neat and airy. ✨

不要害怕创建很多文件 。 它不会减慢开发速度，并且会使您的代码库更加整洁和流畅。 ✨

载入路线 (Load your routes)

To make things work following the structure defined above, we need to use a simple loader I created: Lumie. It will go through your controllers, read the definition files, and load your routes.

为了使事情遵循上面定义的结构，我们需要使用我创建的一个简单的加载器： Lumie 。 它将通过您的控制器，读取定义文件，并加载您的路由。

It’s a small package, you can check to code source on GitHub.

这是一个小包，您可以在GitHub上检查代码源。

路由文件 (Routing Files)

They have been designed to be easy to read. The purpose is to be able to identify methods to update in development by having a quick look in your .routing files. In the following example, three routes will be created:

它们被设计为易于阅读。 目的是通过快速浏览.routing文件来确定要在开发中更新的方法。 在以下示例中，将创建三个路由：

• [ PUT ] /user

  [PUT] /用户

• [ GET ] /user

  [GET] /用户

• [ GET ] /user/reset-password

  [GET] /用户/重置密码

You are wondering why routes are prefixed with “user” although it’s not described in the routing definition. Lumie uses the name of the folder in which the routing file is to prefix routes.

您想知道为什么路由的前缀是“ user ”，尽管在路由定义中没有描述。 Lumie使用路由文件在其中添加路由前缀的文件夹的名称。

Here, we are in controllers/user/user.routing.js . If the user folder has been in a subfolder admin for example, the routes would have been prefixed by admin/user.

在这里，我们在controllers/user/user.routing.js 。 例如，如果user文件夹位于子文件夹admin中，则路由将以admin/user为前缀。

Note that you can pass an optional path field to the routing definition so it will be used instead of the default one.

请注意，您可以将可选的path字段传递给路由定义，以便将其用作默认值。

动作与中间件 (Actions & Middlewares)

As you can see above, each routes configuration have an action method which is nothing more than the logic to execute when we call your API route. I recommend keeping in one file: one action method and its optional associated middleware.

正如您在上面看到的，每个路由配置都有一个action方法，无非就是我们调用您的API路由时要执行的逻辑。 我建议保存在一个文件中： 一种操作方法 及其可选的关联中间件 。

限制条件 (Restrictions)

For each routes configuration, you’ll choose the restriction level associated. The level value will be passed to the restriction function you’ll create to make Lumie work. See how to initialize Lumie with your own restriction function.

对于每个路由配置，您将选择关联的限制级别。 级别值将传递到您将创建的限制功能，以使Lumie正常工作。 了解如何使用您自己的限制功能初始化Lumie 。

This should be just a function that returns a classic express middleware.

这应该只是返回经典快速中间件的函数。

结论 (Conclusion)

I’ve been using this method for a while now. I like to have this kind of opinionated framework to follow when I develop. At the end of the day, it’s helping me to keep a nice codebase and not to take shortcuts like writing too much logic in one file or defining a route in an inappropriate file.

我已经使用这种方法已有一段时间了。 我喜欢在开发时遵循这种自以为是的框架。 归根结底，这有助于我保持良好的代码库，而不是采取捷径，例如在一个文件中编写过多的逻辑或在不合适的文件中定义路由。

Thanks for reading. Tell me in the comments what you think about organizing controllers this way.

谢谢阅读。 在评论中告诉我您对以这种方式组织控制器的看法。

If you found this article helpful, drop some? ?

如果您发现这篇文章对您有所帮助，请删除一些内容吗？ ？

翻译自: https://www.freecodecamp.org/news/how-to-organize-express-controllers-for-large-codebases-2d8284bbf817/

php项目数据库控制器代码