关于服务端渲染的一些思考

最近一直在看 vue 相关的东西,然后看到了为了优化于是有了服务端渲染(S.S.R.)的技术。

到了这我就想到了一些问题,如果把页面放到服务端渲染了,那么跟我们以前的模板技术有没有什么分别了。

只不过就是不用我们后端套用模板了,然后前端就都可以搞定了。

在刚刚写代码的时候我才想到,也许这就是前后端分离吧,只不过是在代码端进行的分离了。后端只提供接口,前端负责渲染页面。而且,我还想到,可能这也是微服务的一种体现,不知道对不对。就这样,继续写代码,后面会出一些好玩的东西

理解依赖注入

图片alt

原文地址:http://php-di.org/doc/understanding-di.html

题外话,原本是想直接翻译这篇文章的,但是后来想想还是算了,采用翻译 + 自己理解的方案来写东西,这样自己也很舒服

依赖注入和依赖注入容器的区别

  • 依赖注入是帮助你编写更好的代码的一种方法
  • 容器是帮助依赖注入的工具

个人理解,依赖注入其实就是一种编程的模式,是代码耦合性更低,方便我们替换某些代码部件, 而容器则是实现这个依赖注入模式的工具

对比 传统编写代码的方式 和 依赖注入的 区别

传统编写方式
  • 应用需要 Foo 类:
  • 应用创建 Foo:
  • 应用调用 Foo:
    • Foo 依赖 Bar
    • Foo 创建 Bar
    • Foo 调用 Bar
      • Bar 依赖 Bim
      • Bar 创建 Bim
      • Bar 做一些事情
使用依赖注入方式
  • 应用需要 Foo, Foo 需要 Bar, Bar 需要Bim:
  • 应用创建 Bim
  • 应用创建 Bar 并且把 Bim 传递给 Bar
  • 应用创建 Foo 并且把 Bar 传递给 Foo
  • 应用调用 Foo
    • Foo 调用 Bar
      • Bar 做一些事情

上面说的是一种叫做 控制反转 的模式。就是是调用者和被调用者的依赖反过来。

这样做的好处是,我们可以自主的控制依赖的关系,并且容易替换

说了这么多,不如上代码来的实在

图片alt

图片alt

乍一看这种方式,写代码反而会更多一些,毕竟以前我们只需要 new 一个 Foo 就可以了,现在反而多写了几行,但是请让我们思考一下,为什么这么做,好了,我继续说吧,我个人理解这么做的原因是,方便我们做一些替换,是我们能够减少代码的修改,比如以前 Bar 我们就当做一个发送邮件的服务,以前我们不想发送邮件了,想改用发送短信的方式,那么我们就得修改Foo的代码了,那么采用依赖注入有什么好处,我们在外面实例化Bar的时候就实例为短信服务就好了,Foo完全不用修改了,也减少我们修改多个代码的风险。这里又得多说几句了,一般在构造的时候参数大都是一个接口,然后各个服务实现接口的方法,完成各自的功能。

最后说一下使用容器的方法

  • 应用需要 Foo
  • 应用从容器中获取 Foo
    • 容器创建 Bim
    • 容器创建 Bar 并且把 Bim 传递给 Bar
    • 容器创建 Foo 并且把 Bar 传递给Foo
  • 应用调用 Foo
    • Foo 调用 Bar
      • Bar 做一些事情

其实使用容器的一个好处就是方便我们管理所有的依赖项,毕竟集中管理要比分散在代码各处要靠谱的多,但是上面说的容器,其实还有个自动分析依赖的功能,但是有一些容器并不具备这个功能,比如以前我们分析过的 Pimple 。 pimple这个东西真的就是一个容器,我们把需要的东西放置进去就好了。至于依赖什么的自己提前编排好,就ok了。不自动分析的好处是快,坏处嘛就是可能得多写一些代码。

好,今天就到这,感觉有些东西没有说清楚,不要急,不要急。以后还有

Let's Build A Forum with Laravel and TDD 笔记 004

图片alt

这一周纠结了一些其他的问题,所以依然停留在了第五集。不过有一些关于测试的想法,还是要梳理一下的。

以前我总是纠结测试,比如说测试一个模型返回的字段是否齐全什么的,后来想想其实我们可以一个一个的assert。

然后还有一个问题是,比如我们没有返回某些字段,那么我们在模型里面定义的一些衍生字段是否还有效,这个让我明天测试一下。

然后依然继续学习如何做测试,就说到这吧,得去调整一下dns有些慢

Let's Build A Forum with Laravel and TDD 笔记 003

图片alt

今天学习了第三集和第四集,下面依然是个人总结

  1. 没错,第三集用到了单元测试也就是 unit 的部分,跟我之前看其他文章了了解的差不多, feature 主要用来测试面向用户的功能 unit 是用来测试我们内部功能的,也就是一个个的最小单元,或者其他的合并单元,然后由这些单元组合成为 controller 里面的代码最终呈现给用户,然后 feature 再来测试 controller 里面的代码。
  2. 关于测试以前都是弄出一个数据然后我们自己调试页面然后观察数据,现在就可以用 unitfeature 来让机器帮我们判定了。我们期待什么值,就让他来断言一下就ok了,但是个人还是比较担心出问题,比如数据不全神马的,这个还得后期继续考虑一下
  3. factorymakecreate 的区别, make 仅仅是生成了数据,create 不仅仅是生成了数据,并且将数据保存到数据库中,所以 create 可以理解为首先 make 然后 save 了。
  4. 在测试文件中 be 方法的作用,就是把当前我们生成的用户,设置为登录状态
  5. 在测试的时候不仅要测试正常的情况,也要测试异常的情况
  6. 功能职责要分清楚,比如发布 Reply 的时候就应该把方法写入到 ReplyController
  7. 关联关系居然可以添加数据,详情参见这里吧 https://laravel.com/docs/5.6/eloquent-relationships#the-create-method

Let's Build A Forum with Laravel and TDD 笔记 002

图片alt

今天学习了第二节,原以为一节课只有不到10分钟,一天可以学习好几节,但是呢,自己就得去学习不足的知识,结果不到一个10分钟的课程,自己就扩展到了将近40分钟,好了,说说今天的心得

  1. 在写功能之前,先做好测试用例,这样可以方便我们去实现功能,也可以提供思路
  2. 在 laravel 的 test 文件夹中有两个字文件夹,分别是 featureunit 这两个一个是功能测试一个是单元测试,就在这里我去查了一下东西,但是理解的也不是很好下面说说自己的理解
    • 功能测试是面向用户的,也就是说我们需要测试代码中的 controller 部分,为什么这么说呢,因为只有 controller 部分才是面向用户的,不论这个功能有多大,这里面一个方法都是对用户的。
    • 单元测试就可以理解为其他的部分了,因为 controller 里面的代码都是由剩余部分的代码组成的,所以这些都是一个个的子单元
    • 其他部分的代码也有可能由其他的部分一起组成,所以我个人觉得也应该写单元测试
    • 不知道上面说的对不对
  3. 写代码的时候应该划分好各自的职责