如何组织我的代码？
How to organize my code?
我仍处于 PHP 和 Laravel 5 的学习阶段，自从我升级到 L5 后，我一直在为我的代码所属的位置而苦苦挣扎。有如此多的文件和文件夹似乎具有相同的用途，或者至少非常相似。有命令、控制器、事件、服务、请求等。我给出了我的工作流程示例以及代码放置位置，我希望你们和 correct/help 我可以对此发表评论。
情况
我想在我的应用程序中注册一个新用户，并在他注册成功后发送一封欢迎邮件。
工作流程
- 控制器（UserController）： Returns请求查看（注册）。
- 请求（RegisterRequest）： "RegisterRequest" 验证输入的数据。
- 控制器（UserController）：将经过验证的数据传递给'App/Services'中的"UserRegistrar"（服务）。
- Service (UserRegistrar):创建一个新用户并将其保存到数据库。
- 控制器 (UserController): 触发 "UserWasRegistered" 事件。
- 事件 (UserWasRegistered): 此事件调用 "SendWelcomeEmail" 命令。
- 命令 (SendWelcomeEmail): 此命令将 send/queue 欢迎电子邮件。
- Controller (UserController): 将用户重定向到一个视图，其中包含他已成功注册并已向他发送消息的信息。
逻辑
好吧，让我们讨论一些逻辑：
- 控制器：
- 代码不多。
- 主要是 return 次观看（包含请求的数据）。
- 处理工作流和 "connects" 模块（服务、请求、事件）。
请求：验证指定请求的数据
服务：一个服务"does"什么的。例如，它正在向数据库发出请求。
- 事件：事件是调用一个或多个任务的中心位置（如果它被触发（SendConfirmationMail、SendWelcomeMail））。
- 命令： 主要用于处理一项特定任务的逻辑。例如发送确认邮件。另一个命令将保存发送欢迎邮件的逻辑。在前面描述的事件中调用了这两个命令。
- 存储库： 那是什么？！
这就是我的理解。请帮助我并为我提供信息。
谢谢，
鲁马
您的问题有点含糊，可能会因为 "too broad" 而引起反对票。也就是说，这是我对此的看法...
我看到的最大问题是您的应用程序结构与推荐的 L5 结构 - 甚至是标准 MVC 结构 - 非常不同，难怪您会感到困惑。
让我们谈谈你的 "Logic" 部分：
controller - 你在正确的轨道上。控制器是模型和视图之间的粘合剂。它可以进行 一些 处理，但大多数应该卸载到处理特定任务的 classes。
请求 - 这是什么？ L5 包含一个 Request class，其中包含用于检查从客户端收到的 HTTP 请求的方法。您是在谈论 subclassing 吗？为什么？如果您对 "request" class 的想法主要与检查输入有关，您可以在您的模型中执行此操作（即在将其粘贴到数据库之前验证内容）或在您的控制器中执行此操作（请参阅 L5 docs on controller validation)
service - 再说一次，这是什么？你说的是 "doing requests to the database"，但 L5 提供了一个 class (DB)。在更高的层次上，数据库访问应该主要通过模型来完成，模型抽象掉了大部分低层次的数据库访问。至于其他服务，我通常做的是创建libraries来进行特定的处理。例如，我的应用程序有一个特定的第三方项目管理应用程序，它通过 API 访问。我有一个库，其中包含 getProject 或 createProject.
event - 事件是一种确保在事件发生时调用某些代码的方式，而不会造成大量混乱。听起来你对事件的看法是正确的。
command - 同样，听起来您对命令有基本的了解。
repositories - 这些是抽象资源（主要是数据库，但它也可以应用于其他资源）和代码之间的连接的方式使用资源。如果您（例如）决定将来更改数据库服务器，这提供了一种更轻松地切换底层资源的方法。它们是可选的。
你也没有提到任何关于 models 的事情。 L5 提供了一种通过 Eloquent 模型以可理解的块处理数据的绝佳方法 - 这将使您的生活 更 更轻松。
我的建议是：从小事做起。使用 L5 构建一个简单的 MVC 应用程序——一个模型（用于保存一些数据）、一个视图（用于显示数据）和一个控制器（通过处理客户端请求将模型和视图放在一起）。一旦你有了它，就开始扩展它。
那里有一些教程可以为您提供 Laravel 的基本结构 - 大多数是 Laravel 4，但看看您是否可以遵循基本思想并为 [=79] 构建类似的东西=].
我仍处于 PHP 和 Laravel 5 的学习阶段，自从我升级到 L5 后，我一直在为我的代码所属的位置而苦苦挣扎。有如此多的文件和文件夹似乎具有相同的用途，或者至少非常相似。有命令、控制器、事件、服务、请求等。我给出了我的工作流程示例以及代码放置位置，我希望你们和 correct/help 我可以对此发表评论。
情况
我想在我的应用程序中注册一个新用户，并在他注册成功后发送一封欢迎邮件。
工作流程
- 控制器（UserController）： Returns请求查看（注册）。
- 请求（RegisterRequest）： "RegisterRequest" 验证输入的数据。
- 控制器（UserController）：将经过验证的数据传递给'App/Services'中的"UserRegistrar"（服务）。
- Service (UserRegistrar):创建一个新用户并将其保存到数据库。
- 控制器 (UserController): 触发 "UserWasRegistered" 事件。
- 事件 (UserWasRegistered): 此事件调用 "SendWelcomeEmail" 命令。
- 命令 (SendWelcomeEmail): 此命令将 send/queue 欢迎电子邮件。
- Controller (UserController): 将用户重定向到一个视图，其中包含他已成功注册并已向他发送消息的信息。
逻辑
好吧，让我们讨论一些逻辑：
- 控制器：
- 代码不多。
- 主要是 return 次观看（包含请求的数据）。
- 处理工作流和 "connects" 模块（服务、请求、事件）。
请求：验证指定请求的数据
服务：一个服务"does"什么的。例如，它正在向数据库发出请求。
- 事件：事件是调用一个或多个任务的中心位置（如果它被触发（SendConfirmationMail、SendWelcomeMail））。
- 命令： 主要用于处理一项特定任务的逻辑。例如发送确认邮件。另一个命令将保存发送欢迎邮件的逻辑。在前面描述的事件中调用了这两个命令。
- 存储库： 那是什么？！
这就是我的理解。请帮助我并为我提供信息。
谢谢， 鲁马
您的问题有点含糊，可能会因为 "too broad" 而引起反对票。也就是说，这是我对此的看法...
我看到的最大问题是您的应用程序结构与推荐的 L5 结构 - 甚至是标准 MVC 结构 - 非常不同，难怪您会感到困惑。
让我们谈谈你的 "Logic" 部分：
controller - 你在正确的轨道上。控制器是模型和视图之间的粘合剂。它可以进行 一些 处理，但大多数应该卸载到处理特定任务的 classes。
请求 - 这是什么？ L5 包含一个
Requestclass，其中包含用于检查从客户端收到的 HTTP 请求的方法。您是在谈论 subclassing 吗？为什么？如果您对 "request" class 的想法主要与检查输入有关，您可以在您的模型中执行此操作（即在将其粘贴到数据库之前验证内容）或在您的控制器中执行此操作（请参阅 L5 docs on controller validation)service - 再说一次，这是什么？你说的是 "doing requests to the database"，但 L5 提供了一个 class (
DB)。在更高的层次上，数据库访问应该主要通过模型来完成，模型抽象掉了大部分低层次的数据库访问。至于其他服务，我通常做的是创建libraries来进行特定的处理。例如，我的应用程序有一个特定的第三方项目管理应用程序，它通过 API 访问。我有一个库，其中包含getProject或createProject. 等方法
event - 事件是一种确保在事件发生时调用某些代码的方式，而不会造成大量混乱。听起来你对事件的看法是正确的。
command - 同样，听起来您对命令有基本的了解。
repositories - 这些是抽象资源（主要是数据库，但它也可以应用于其他资源）和代码之间的连接的方式使用资源。如果您（例如）决定将来更改数据库服务器，这提供了一种更轻松地切换底层资源的方法。它们是可选的。
你也没有提到任何关于 models 的事情。 L5 提供了一种通过 Eloquent 模型以可理解的块处理数据的绝佳方法 - 这将使您的生活 更 更轻松。
我的建议是：从小事做起。使用 L5 构建一个简单的 MVC 应用程序——一个模型（用于保存一些数据）、一个视图（用于显示数据）和一个控制器（通过处理客户端请求将模型和视图放在一起）。一旦你有了它，就开始扩展它。
那里有一些教程可以为您提供 Laravel 的基本结构 - 大多数是 Laravel 4，但看看您是否可以遵循基本思想并为 [=79] 构建类似的东西=].