mirror of
https://github.com/LeuisKen/leuisken.github.io.git
synced 2026-02-01 15:23:50 +00:00
29 lines
4.3 KiB
HTML
29 lines
4.3 KiB
HTML
---
|
||
layout: post
|
||
category: "design-pattern"
|
||
tag: [thinkPHP, Node, Express, PHP]
|
||
title: 学了一点thinkPHP和express，谈谈MVC
|
||
---
|
||
<p>过完年了，还有一大堆坑着的项目等着我去填。作为一个开发人员，无止境的调试肯定是很烦的，但根源还是，团队成员不在一起。其实，不是需求改的多，是交流没到位啊！</p>
|
||
<p>作为一篇开坑帖，我就不多废话了，简单说一下，然后还有bug等着我fix。</p>
|
||
<p>接触tp，其实还是因为在项目开发中遇到了对数据库的处理。轮到我头上了，开发就一定要做的。自己也知道不是后台开发出身，写出的代码肯定充满注入点。。。所以就选择直接学习tp吧，直接正面刚一波后端需求，也是我的风格咯。</p>
|
||
<p>后来tp用的有一点自己的感觉了，然后接触node的express，发现了很多共同之处，以至于对MVC模式有了一些浅薄的理解。我自己的体会难免有偏颇之处，也真心希望和大家邮件交流。</p>
|
||
|
||
<p>正文开始：</p>
|
||
<p>说到MVC，一般来时是指Model \ View \ Controller这三部分（那个说backbone.js的放学别走）。Model说白了就是你可以直接操作的对象，比如你把数据库操作封装成了一个db类，规定了set、get等方法，这就是一个Model，个人理解为数据或操作的模型。Model会因数据库而异，但相对来说有很大的重用性。View是纯纯的前端模板，或者说模板渲染层，顾名思义，就是视图，展示出去的东西，所以肯定这里的大部分工作是传统的前端领域。出于View层重用性的考虑，一般会在模板里引入变量，公有头文件等等等等。而这些变量是怎么引入的呢，我们接下来在tp和express中理解一下Controller（控制器）。</p>
|
||
<p>以我目前的理解来看，Controller就是路由控制。我们知道，用户在浏览器输入一个url，请求的是服务器上的一个具体文件。由于我们采用了目前这种模式，我们的V都是服务器渲染出来的，并不是静态的文件。所以说，单纯指向文件的URL不能作为我们网站页面的链接地址的，所以我们需要对路由规则进行设置，比如我访问根目录下的reg（'/reg'），就要给我显示注册页面等等。如何根据传来的URL去选择渲染哪个模板，这就是控制器（C）要做的。当然，为了模板的重用性，C还负责向模板传入变量，以及简单的逻辑，等等。</p>
|
||
<p>现在就来说说C在tp的实现吧。tp只有一个单入口——index.php，而tp的URL，常常会是这个样子。</p>
|
||
<pre>localhost/index.php/Index/Index/index.html</pre>
|
||
<p>我来翻译一下，这个的意思是请求Index项目下的Index控制器下的index方法。有点绕对不对，不急，慢慢来，如果我用这样的形式来写你看看。</p>
|
||
<pre>localhost/index.php?g=Index&m=Index&a=index</pre>
|
||
<p>是不是发现了什么？对的，在tp里面，index.php后面的路径本质上是GET传参，然后对URL进行重写，感觉上就好像是有那个文件一样。这种重写习惯上被称为伪静态，主要目的是为了SEO。（PS:话说g \ m \ a这三个参数还是我一点点试出来的呢，也是惨。）</p>
|
||
<p>再看express，倒是很直接的出现了这样的代码，举个最简单的例子。</p>
|
||
<pre>
|
||
app.get('/reg', fucntion(req, res){
|
||
res.send('Hello World!');
|
||
})
|
||
</pre>
|
||
<p>我来解释一下，这行代码的意思是，当以GET方式访问'/reg'时，执行某函数。示例中的函数会返回一段'Hello World'作为应答。虽然简单，却也体现了express的C大概是怎么一个东西。</p>
|
||
<p>MVC这种模式很早就有了，但是在WEB开发中起到了很大的影响。随着前后端分离的需求越来越明显，前后端的分工情况也在发生着改变，加上node的出现，前端从只负责V，到参与C，再到现在主流的V+C。工作是越来越多了，但是技术体系也在不断的完善。前后端分离的优势是很明显的，我感触最深的这两点：1.工作上不再有必然的时序联系，API文档做的好就行了；2.前后端（甚至中间件）均可作为独立的产品发布。后者，个人认为对提高前端的待遇有挺大好处的。</p>
|
||
<p>简单结个尾，这就是我目前的一些想法。欢迎大家电邮我一起讨论。</p>
|