Laravel框架实战:增加表单专用Model

随着进一步使用Laravel框架,感觉也需要对MVC模式进行重新的梳理。在原有的代码中,网页上的表单提交后,在控制器中是通过: [crayon-59c2fcce87c25557825870/] 来提取,取得的内容为表单的name => value键值对,随后我们再在控制器中编写相应的校验规则来对这些参数的合法性进行检验,并根据检验结果来控制页面的跳转。然后随着这样的代码越写越多,我们也就发现了这样写法可能会带来的问题: 当表单发生变化的时候,必须要找到表单action所对应的控制器的对应代码来进行修改; 需要通过使用Input::All()数组来获取内容,这使得代码中势必要出现大量的Magic string,不利于系统未来可能发生的重构; 针对表单->实体模型的转换,每种转换都需要在Controller中编写,在修改转换逻辑的时候会造成不便(例如,用户注册的表单并不是直接和数据库中的用户表对应的,用户注册表单的数据需要一定处理后才能被存入数据表) …… 这些主要就是...

Laravel框架初识:扩展Auth功能

Laravel框架初识:扩展Auth功能
最近在尝试使用Laravel框架进行一些实际开发,框架本身提供了很多常用的Web应用的机制和库,虽然很好用,但是却不能包容我预期的设计,比如Auth模块,该模块提供了两种很基本的验证驱动,一个是Database,使用QueryBuilder来与数据库进行交互,另一个是Eloquent ORM,是采用其内置的ORM库来进行数据库交互(感觉类似于.Net中的EF),但是不论采取哪种驱动,都存在同样的局限性: 必须采用内置的Hash方案对入库的密码进行保护 这一局限使得原本系统设计中的MD5 + Salt方案受到了阻挠,尽管实现会稍显麻烦,但我仍然认为这种方案更适合于我的项目,因此我参考了Laravel文档中扩展章节所述的Auth模块扩展以及网上查阅的一些资料,来对原框架进行修改,使其能够支持有我自己定义的验证驱动。 首先介绍我所考虑使用的MD5 + Salt方案的具体设计: 数据库中不应该存储密码明码应该是一个基本安全常识,通常的方案是采用MD5算法对密码进行Hash,再存入数据库,从而避免数据库泄