我的 Symfony 和 Doctrine 的最佳实践经验

我的 Symfony 和 Doctrine 的最佳实践经验

Chris Yue No Comment
Posts

虽然symfony和doctrine的强大功能可以让我们的开发变得快捷,但不合理运用也容易导致恼人的问题出现。我就我的经验以及对程序设计的认识,来说说我总结的最佳实践。

首先从mvc的角度来说,symfony提供了完整的controller和view层的解决方案,而doctrine则是提供了m层的解决方案。作为mvc里面的最底层,model是不需要知道controller和view的存在的。具体体现在运用上,举个例子,当使用doctrine的model代码直接移植到zend framework或者其他框架环境下,应该是无缝移植而不用修改model任何代码。如果你的model层里面使用了类似sfConfig::get这样的symfony框架提供的方法,那么你model代码里面就出现了“坏味道”,将直接导致你的model层不能被复用。

事实上,就算是symfony这一个框架,也是包含了两个环境的:web应用环境和命令行环境。所以如果你不小心在model层里面写上了类似sfContext::getInstance()->getRequest()这样的代码,那么在使用会运行model的命令比如symfony doctrine:data-load的时候,就很有可能因为找不到某个组件而发生错误。比如上面的代码,命令行环境的上下文(context)是没有request组件的。

为了防止这样的“坏味道”出现,model层应尽量避免代码里面直接获取某一个变量(比如使用sfConfig),而多提供丰富的参数或者setter接口。从设计的角度来说,跟controller或者view关系比较紧密的变量(比如列表页最多显示多少条啦等等),也的确不应该让model层来关心。

接下来说说载入测试数据的方法。在实际的使用过程中,很多人会发现,如果使用了DoctrineRecord的save方法做了一些初始化工作,而且这些初始化工作是新增了另外的DoctrineRecord对象的时候,如果测试数据同时又对初始化工作提到的对象有描述,往往会发生关联冲突的情况发生。为了避免这种错误,有两种方法可以选择,一是不要用save方法来做初始化工作,而是制造新的创建对象的方法,比如用户注册可以用User::register;二是不要使用doctrine:data-load命令来载入数据。我这里更倾向于使用第二种方法,并推荐使用单元测试来完成数据载入的工作。这么做的好处有两个,一是用测试代码载入数据的同时也是做单元测试,保证每次更新代码以后的代码正确性和完整性,二是不会发生data-load命令那种冲突问题。不过坏处也是显而易见的:因为还带有测试的目的,所以数据的载入时间会变长

我的 Symfony 和 Doctrine 的最佳实践经验 by Chris Yue is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.

微信赞赏码

写作累,服务器还越来越贵
求分担,祝愿好人一生平安
天使打赏人

发表评论

− 1 = 3