后台建设的一点感想

好多人张嘴就来，php是做社交和对长驻留要求不高的网站的（也就是我们所称的小型建站），Java是做大型网站的；这就有疑问了，到底“大”和“小”的界限在哪里？

其实是业务逻辑的表述问题了，对于需要长期查询内存的服务，比如大家最近浏览的名人微博，一些在请求时经常需要的cookie或者偏好设置什么的，这些不必要经常请求数据库的东西，编程语言有”字面上“直接接触内存的办法是再好不过，异构设计在这种情况下是个不错的想法，比如php作为静态的前端服务器集群，将待处理的表单队列发给Java数据库集群；

当然，在一个偏重业务处理流程的设计来看，前端是什么语言写的，是否和后台紧密结合不是很要紧，在严格的MVC范围之外，一些比较松散的c-s架构更适合使用不同语言编写以达到各展所长的目的；比如[1]浏览器->[2]前端服务器->[3]数据库的查询页面或JavaBean->[4]数据库驱动，抛开[1]不谈，[2]->[3]可以视作前端部分的客户端到服务器，[3]->[4]也算是后台里面的客户端到服务器；按MVC的观点看来，[2]->[3]->[4]也算是视图->控制器->模块的思路，如果把前端和后台两批人分开写，后台相当于把控制器->模块的部分隐藏起来了；如果两部分都用同一套规范（接口或者类）来编写，前端依旧可以根据自身业务需要进行完整的MVC编程，增删页面，改变连接到的页面而不必担心扰乱后台的业务逻辑，解耦合也是部分的以整洁换效率的做法；

上面讲的例子，个人理解是，前端到后台，每个部分都遵循了同一个规律，类似递归的嵌套一样，虽然每个数据库或者服务器（集群）做的事情各不相同，但是从整体上显得较为整齐和易于理解；现在写项目已经有一部分不是性能的问题，而是开发的过程是否有可读性和合作的便利性；很多（立志）做全栈程序员的，经历过和人合作的，多半感慨为啥别人的代码老是和自己的“规范”不合，要么是一个人负责一个功能，要么是搞一套编写规范出来，出错了也方便快速批量地纠错；

讲到这里发现自己严重跑题了...哭，之前做一个纯php的网站，缺一个内存驻留daemon的功能，后来一个朋友用轮询的办法，在一定时间内间隔地查询某个内存段，在客户端看来内存是驻留的；再后来，发现Java有查询内存的办法，以及更强大的Socket编程类库，（这个目前真不是php的强项~直到php 5.3）就萌生了php负责前端的动态生成，Java负责业务逻辑的想法；关于这个（伪）MVC的第一个实现（大半是我那位朋友做的，就是一个index页面只负责作为路由器，根据不同的请求转至不同的页面）戳这里-> http://www.supsing.org/  后来就有了这篇文章所说的思路；思路都是写代码写出来的，或者和别人写代码时受到启发的；恳请各位大侠转载保留出处 :)这年头技术革新挺快的，对于玩代码或是靠代码吃饭的人都是个机遇，从码字本身解放出来就是个很大的进步了；这篇东西就是我的一点吐槽，代码和生活还是两回事；