关于验证属于Laravel应用程序的位置,有很多争论。尤其是当事情变得复杂的时候。就我个人而言,我认为模型的职责应该是只接受有效数据,并在收到无效数据时抛出异常。
考虑到这一点,我想为用户模型提出以下场景(我目前正在做类似的事情):
有很多可供选择的选项,有些感觉更容易实现,但感觉错了:
选项1:控制器验证。将验证粘贴到处理此对象的控制器中很容易。另一方面,规则在各地重复,这感觉是一个不好的方式去做它。
选项2:表单验证器。为不同的窗体创建分隔符验证器。本质上,这与选项1大致相同,但我们刚刚将验证提取为不同的类。规则仍然在不同的地方重复,仍然感到肮脏。
选项3:整个模型验证。将验证规则添加到模型并在保存之前进行验证(通过显式从控制器调用验证方法或在保存时验证)。感觉好多了,但由于场景的复杂性,仍然存在缺陷。我们需要处理在现有记录的唯一规则中排除ID的问题。在保存到数据库之前,我们需要处理密码哈希(如果我们从数据库加载了一条记录,模型将包含一个真正不应该验证的散列密码)。我们仍然需要处理上传图像的裁剪/调整大小/移动,并以某种方式生成唯一的文件名。
选项4:模型验证/处理功能。在设置属性之前编写一个接受数据并对其进行验证的函数(如果无效则抛出异常)。只验证它所提供的数据(例如,我们只能传递一个新的概要文件映像)。根据对象是否存在或是新对象动态调整规则。调用相关的处理函数,例如,处理大小/裁剪/移动上传图像和删除旧配置文件图像的函数。
选项5:模型变异器。编写负责验证和处理它们所代表的字段的变异器。这确保只有有效数据才能进入模型并完成所有处理。可以通过立即抛出异常或使用错误字段跟踪问题来处理错误,然后可以检索错误字段。缺点可能是,如果没有设置一个字段,那么该字段的验证就永远不会被调用,因此一些必需的空字段可能滑过网络--我想这可以通过在控制器中确保所有输入都通过。
选项6:模型变异器+整个模型验证。正如前面在选项5中描述的那样,在保存数据(如选项3 )之前,添加了验证整个模型的内容,这将确保网络中不会出现空的所需字段。
有什么建议吗?
请注意,我不需要任何密码帮助。我只是在寻找关于如何以最好的方式处理复杂场景的建议和建议。
干杯
发布于 2015-02-27 02:36:45
Laravel 5提供了表单请求验证 --这是现在处理验证的一个很好的方法。所有的规则都保存在一个位置,并且遵循DRY和SRP原则。
它们使您能够包含复杂的验证,但也可以非常快速地执行简单的请求。
最重要的是,它将验证从控制器中抽象出来,因此可以在多个地方使用。如果验证失败了--那么控制器甚至永远不会被调用--那么控制器就会开始快速清理。
https://stackoverflow.com/questions/28762958
复制相似问题