laravel 架构图？

Posted 2023-03-14

【中文标题】laravel 架构图？

【英文标题】：Diagram of laravel architecture?

【发布时间】：2016-11-18 11:58:45

【问题描述】：

谁能指点我一张显示正常 MVC 位与以下内容之间关系的图表：

中间件 警卫 外墙 合同

Laravel 似乎有很多中间商，我很难看到大局。

编辑

在考虑了亚历克斯的回答（如下）后，我认为这样的图表是可能的。由于其中一些与一般 OOP 原则有关，我认为 UML 序列图将是答案。

【问题讨论】：

此链接中的图片可以帮助您了解模型视图控制器（mvc）的流程：selftaughtcoders.com/from-idea-to-launch/lesson-17/…

守卫：***.com/questions/34896130/…

外墙：***.com/questions/42223986/…

合同：***.com/a/34073024/9501353

中间件:***.com/a/43013324/9501353

【参考方案1】：

由于您的问题非常广泛，我认为在一张图片中提供所有解释就像在一个蛋糕中拥有所有味道。上面的答案中的@Alex，已经准确地涵盖了解释。这是我的看法：

MVC：设计模式建议开发人员不要将业务逻辑（模型）与表示（视图）和用户请求处理程序（控制器）混合。

要记住的要点：

MVC stands for Model, View and Controller.
Model is responsible for maintaining application data and business logic.
View is a user interface of the application, which displays the data.
Controller handles user's requests and renders appropriate View with Model data

更多详情：http://www.tutorialsteacher.com/mvc/mvc-architecture

术语：中间件、Guards、Facades、Contracts 是 Laravel 框架应用逻辑的一部分，用于不同用例的请求周期，用于隔离应用程序中的代码以提高可维护性、可理解性和内聚性。虽然即使是单页脚本也足以完成必要的工作，但维护起来会很头疼。

中间件：Laravel 过滤进入应用程序的 HTTP 请求的方法。它在请求生命周期中位于路由器之后和控制器之前。

更多信息：https://laravel.com/docs/5.6/middleware

Guards：它们定义了系统在注册和身份验证时应如何存储和检索有关您的用户的信息。

更多信息：https://laravel.com/docs/5.6/authentication

外观：外观为应用程序服务容器中可用的类提供“静态”接口。 https://laravel.com/docs/5.6/facades

Contracts：为了松散耦合和简单性。 Laravel 的 Contracts 是一组定义框架提供的核心服务的接口。例如，Illuminate\Contracts\Queue\Queue 契约定义了排队作业所需的方法，而 Illuminate\Contracts\Mail\Mailer 契约定义了发送电子邮件所需的方法。

更多详情：https://laravel.com/docs/5.6/contracts

【讨论】：

谢谢..这是迄今为止我见过的最全面的答案。

欢迎 Maxcot 并感谢您的赞赏 :-)

【参考方案2】：

对不起。这不是一个答案。但只是一些意见。

您正在尝试将“苹果”与“橙子”进行比较。

MVC 概念是专门或主要与 WEB 开发相关的概念。

它建议开发人员不要将内容（模型）与表示（视图）和逻辑（控制器）混合。

另一方面，你提到的东西：中间件、守卫、门面、合同。

它们大多是关于一般编程概念和类部分或 OOP 原则的扩展。

不要谈论您的具体条款：middleware, Guards, facades, Contracts，而只是谈论 OOP。

任何 OOP 原则都可以应用于 MVC 的任何部分。

我们可以使用 OOP（类、接口等）创建模型，或者我们可以通过一些程序方式或 OOP、程序和经典意大利面条的组合来实现。

View 和 Controller 相同。您可以使用一些 OOP 原则和技术，也可以限制它们的使用或忽略它们。这取决于开发人员和/或可能取决于项目范围和设计。

回到您的列表：中间件、守卫、外观、合同。我想说这些只是现代软件开发世界中存在的一大组 OOP 术语和实践的一部分。我的意思是不幸的是，我们不能在 MVC 和一些 OOP 实践列表之间做任何相似之处。

我要指出的另一个想法是，OOP 比 MVC、WEB 和数据表示逻辑类软件更通用。

假设我们需要开发新的操作系统内核。我会说没有太大的空间来为此类应用程序应用 MVC。但是 OOP 可能仍然有用。嵌入式系统或某些特定软件、驱动程序、服务器等也是如此......

【讨论】：

如果你有时间和意愿，问题更多的是（我觉得）请求-响应流中的守卫、中间件在哪里；立面和合同是不同的概念，但其余部分的流程图会给我 50 分

谢谢亚历克斯，我想你有我在那儿： 你正试图将“苹果”与“橙子”进行比较。

...这让我想到了。如果它是一般的 OOP 事物，那么 UML 就是答案。那么 UML 序列图呢？