Laravel Web和API控制器结构.单独vs干 [英] Laravel Web and API controller structure. Separate vs DRY

问题描述

我想构建一个同时使用Web和API部分的Laravel应用程序.常见的问题(也是我的问题)是是否使用单独的控制器.

有2个选项:

1. 单独的控制器 Laravel API控制器结构?

2. 使用一个控制器并检查请求类型(是Ajax还是取决于请求链接)，然后返回JSON或HTML.适用于API和非API的Laravel资源控制器-API使用

具有第一见解的人不会解释DRY问题的解决方案-Web和API控制器将是相同的，除了return语句(JSON或HTML视图).但是由于大多数帖子建议将控制器分开，所以我怀疑我对DRY问题解决方案一无所知.

我看不到第二种方法的任何缺点.但是人们会说

如果仅使用一个控制器，很快就会出现混乱的类，包含数千行.这不仅不能很好地扩展规模，而且对您和您的队友也很难与之合作.

请向我解释第一种方法(单独的控制器)的DRY问题解决方案，以及第二种方法(单个控制器)的可能的水下岩石问题

请说明哪种方法更可取.

解决方案

我认为这是一个很好的问题，我也很想看到答案.

我可以看到两种方法的论点.但是，我将创建和维护单独的控制器，同时使用服务在已知不会改变的控制器之间共享通用逻辑.

例如，如果您允许用户上传头像图像.我会将这样的逻辑放入服务中，并在两个控制器中使用该服务.

在我看来，采用这种方法的原因是Web和API逻辑可能会有所不同，因此在不影响彼此的情况下进行迭代很容易.

如果这不太可能，那么我仍将创建单独的路由，但将它们都指向同一控制器，以便将来将来发生更改时，您只需将API路由重新指向其自己的控制器即可./p>

I want to build a Laravel application which users both web and API parts. The common (and mine as well) question is whether to use separate controllers or not.

There are 2 options:

1. Separate controllers Laravel API controller structure?

2. Use one controller and check the request type (is Ajax, or depending on the request link) and return either JSON or HTML. Laravel resource controllers for both API and non-API use

Those who have the 1-st opinion doesn't explain the DRY problem solution - web and API controllers would be the same except the return statement (JSON or HTML view). But since most post recommend to separate controllers I suspect I don't understand something about the DRY problem solution.

I don't see any disadvantage of the second method. But people say something like

If you use only one controller, you will end up soon with a messy class with thousands of lines. Not only this is not going to scale well, but it will be hard to work with for you and your teammates.

Please explain me the DRY problem solution for the first approach (separate controllers) and the possible underwater rocks in the second approach (single controller)

Please explain which approach is preferable.

解决方案

I think this is a great question, and I too am keen to see the responses.

I can see the arguments for both approaches. I however would create and maintain separate controllers, whilst using services to share common logic between the controllers where it is known that this will never change.

For example, if you allow users to upload avatar images. I would put such logic in a service and consume this service in both controllers.

The reason for this approach in my mind, is that the web and API logic may diverge and it would therefore be easier to iterate each without impacting the other.

If this is unlikely, then I would still create separate routes, but point them both at the same controllers, so that if it did change in the future, you can simply re-point the API routes to their own controllers.

这篇关于Laravel Web和API控制器结构.单独vs干的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！