我正面临着如何在我的laravel项目中实现验证的困境，让我来解释一下情况。
store()方法中使用update()通过rules()方法验证数据并使用authorize()方法确定授权，这确保了我的数据正确，并且只有具有正确权限级别的用户才能添加/编辑数据。只要数据是通过对api发出的表单/ ajax请求来实现的，那么此时一切都运行良好。现在，这是问题所在。有时插入/编辑操作需要以编程方式完成，例如，每当在表A中创建一行时，需要在表B中创建一行，但在执行此操作之前，它还应运行相同的验证规则并检查如果使用表单请求创建表B将执行的授权，但是如果我只是打电话说TableA::Create([])这行就会在没有任何验证的情况下创建。
当然，我也可以在模型中使用Validator::make()然后，a）它使模型混乱b）是重复的代码
因此，我的目标是确保无论表A的记录如何进入数据库，如果从应用程序完成，将在保存数据之前执行检查，同时保持验证和授权规则的中心。在我看来，要走的路是将模型的“保存”事件挂钩并以某种方式触发formrequest验证器？但我不确定。
我看过Jeffrey Way的automatic model validator，但那是Laravel 4.在Laravel 5.x中有没有优雅的方法呢？
另外，作为一个附加问题，当我在其他地方提出这个问题时，有些人说他们“不是基于模型验证的粉丝”，没有解释为什么对他们来说这不是一个好主意，所以我也想要知道基于模型的验证有哪些缺点？
我建议退一步。试图抽象所有内容是一种诱惑，所以不会重复一行逻辑，但你需要理解为什么/你在这里验证什么。
在开发应用程序的早期阶段，您可能会感觉到您在任何地方都在重复验证逻辑，如果您将验证放在控制器中，可能会担心您会遗漏某些内容 - 例如，“如果我添加控制器方法会发生什么并且在更新模型之前无法验证数据？“因此，此后的自然步骤是将验证推送到模型中。
但！你应该回过头来思考你在验证什么。您在控制器中验证的内容并不总是与您在模型中验证的内容相同。
有关MVC验证的更多信息，请参阅Stacks姐妹站点上的以下链接：https://softwareengineering.stackexchange.com/questions/97880/in-mvc-should-a-model-handle-validation
在我看来，陷阱是在开发的早期阶段，控制器和模型验证是如此相似，你可能认为它们是同一个。之所以会发生这种情您刚刚（在控制器中）验证了用户的名字不是“_-_ kablamo！-_-”，然后在模型中您正在做同样的事情。
当您超越简单的用户模型时，您会发现您的模型和控制器更复杂，验证可能不仅仅依赖于当前的请求数据 - 例如它可能依赖于系统中的其他数据，时间今年，季节，如果卫星是一致的。
我听到你尖叫得很好，这对第一段并没有真正的帮助，你说“如果我错过了一些新的控制器方法验证会怎么样？”。我对此的回答很简单，测试。您的单元测试应立即进行测试。
没有。
这是一个严重的问题，过多的谈话和解决方案都不够。
Laravel假设您可以在前端，路径，控制器或模型上进行验证，但代码的体系结构假定大多数用户将更接近用户验证 - 无论是在路由还是在控制器 - 而不是在模型中。对于简单的解决方案，这是好的当模型可以由具有不同职责的多个控制器使用时，这是不行的。
模型需要作为规则和验证的单一权威点。 控制器和路由可以应用适合目的的附加验证。
从这40年开始，您拥有的功能越多，您拥有的开发人员越多，您的数据可能会让一个人可能起诉您的财务影响越大，您需要对后端执行的验证越接近。您的应用程序越小，开发人员越少，信息越不重要，您在前端附近验证的信息就越多。
但是，通常您会在路径，模型，控制器和数据库中验证不同的用途。 （上面有人说过。）
“测试将抓住它”是对这个问题的一种千禧一代（在贬义中）。您的业务规则是声明性的和可观察的，或者它们不是声明性的和“神奇的”。 Jared有时与声明性和可观察性有着奇怪的关系。
有许多套件曾经运作良好，但我不确定是最新的。
1. laravel-ardent / ardent
诅咒/凄美
3. jaspaul / eloquent-model-validation
“最简单”的答案是创建一个基类来覆盖保存功能，执行验证并捕获任何错误，将它们添加到存储桶中。
就个人而言，我不知道为什么'Ardent'不仅仅是'它的方式'。不幸的是，作者似乎并没有坚持下去。