很有趣。很长一段时间以来,我在模型中执行所有验证,就在我认为的DAL(数据访问层)上方。我的模型通常是按表数据网关模式来设计的,其中DAL提供抽象和低级API。
在TDG内部,我会实现业务逻辑和验证,例如:
1. 用户名是否为空
2. 用户名是否超过30个字符
3. 如果记录不存在,则返回错误
随着应用程序复杂性的增加,我开始意识到很多验证可以在客户端使用JavaScript完成。因此,我将大部分验证逻辑重构为JS,并清理了我的模型。
然后我意识到服务器端验证(不是过滤/转义-我认为这是不同的)也应该在服务器端完成,只在客户端作为锦上添花。
所以验证逻辑又回来了,当我再次意识到,输入验证/断言和业务规则/逻辑之间可能存在明显的区别。
基本上,如果可以在应用程序的客户端(使用JS)完成,则认为这是输入验证...如果必须由模型完成(例如,该记录已经存在等),则认为是业务逻辑。令人困惑的是,它们都保护数据模型的完整性。
如果您不验证用户名的长度,那么有什么阻止别人创建一个单字符用户名呢?
我仍然没有完全决定在哪里放置这种逻辑,我认为这取决于您更倾向于什么:轻量级控制器、重型模型还是反之亦然...
在我的情况下,控制器往往更加应用程序中心化,而如果精心制作,则可以将模型在“其他”项目中重复使用,而不仅仅是在内部使用,因此我喜欢保持模型的轻量级和控制器的重型。
推动您朝某个方向发展的力量实际上是个人意见、要求、经验等...有趣的话题 :)