入口点->判断URL类型->数据库拉取URL操作列表->根据操作列表进行读取判断及数据处理->根据URL的操作末端判断出口res.render或res.send文件。 大型应用流程的快速部署。其中URL表可采用缓存提速处理高并发。
跟有没有express没有关系，你应该先明白express是什么角色。Java，你用了Spring就意味着你可以随意code了？ 我们写代码是给人看的，这个人包括你自己。
拿来一段代码是:
parse();
print();
logger();
而不是
if(lalala){
... 省略几百字
}
console.log(lalala);
lalalalalalalalala
lallalalalalalalala
fs.writeFile(lalala, lalalala
lalalala
lalalalalal);
...省略几百字
我们不要看你满张纸都是一大堆废话，一大堆lalalalalalalalalala… 我们要看的是你在做什么，你在parse() print() logger()，而不是lalalalalalalal… 如果是纯函数式风格的语言，压根就不存在变量这种东西，除了用函数你休想表达你的任何思想。
要搞懂这些，你需要先具备设计模式的基本原则: 组合、抽象、接口的思想。
你纠结于view，就说明你对设计模式并没有接触，也没有做过接口设计和编写之类的。
view在这里只不过是名字，你可以把他写成任何名字，哪怕是abc，叫他view，也不过是当时的想法而已。 view代表着提供HTML字符视图接口库。
如果你的项目工作量大了，你自己是难以完成的。你需要和人合作，而这个view接口库就可以委托别人来写，或者委托第三方开发公司来付费编写。你们之间只需要遵守定义的接口约定。将来代码合并到一起就支撑起整个系统。
比如writeJoin(res)这个接口是这样定义的，其怎么实现根本不需要你操心，你可以在你的代码里使用，而这个功能则是其他人帮你实现。你可以集中精力写你的内容，比如数据操作，比如安全验证。
正如我所说，connect和express只是一个小接口，给你提供路由处理的库。
但是你还有很多其他库需要工作，比如js自带的Math库、RegExp库、…
而这里是告诉你怎么写你的自定义库，以支撑团队工作，和模块化软件系统。
这3种是设计模式中的原则中的三个，设计模式的详细原则可以看文言文《设计模式——可复用面向对象软件的基础》，或者白话版本《Head First 设计模式》。
其中的原则比如:
- 封装变化: 将未来变动可能性大的代码封装起来，以减少改动多股诺
- 多用组合，少用继承: 多个小类组合|聚合，形成一个复合系统，这使得子类更具有原子级别功能
- 针对接口编程，不针对实现编程: 接口使得目标可以抽象，我们可以先想到要做什么，而不必考虑怎么做 …
基于需求来看的话，接口使得一个问题分化成多个小问题。 比如电视机和插座和发电机，电视机使用3个插口来寻找电力、插座对电视机提供3插口转换电力、发电机提供电力。
组合，更像是使用接口的具体表现。
抽象是要功能所达到的级别。 比如什么是鸭子? 你认为有扁嘴、两只脚、两只翅膀，这就是你的抽象。 我认为会“呱呱”叫、有扁嘴，这是我的抽象。 但是鸭子真的只是这样吗？ 并不是，我们的抽象以我们的需求为主导，只要满足需求就抽象到“刚刚好”。 “鸭子辩型”的抽象认为会呱呱叫的都是鸭子。
组合、抽象、接口确实如你所说的那个意思。
1.楼主请别把设计模式奉为圣经……虽然说设计模式应该和语言无关，但实际上是：最早的设计模式普遍由当时流行的CPP、Java等等这样语言为蓝本所著，且楼主所列两书目均是出自于此。
2.对于动态类型的语言，多态在语言级的体现已经不太明显，也就是说面向对象的一大特性就此抹杀。GoF写的那些设计模式有一半不能作为语言级的实现。
3.楼主显然读过不少书，但是做没做过大型项目就不得而知了。因为很多情况下为了兼顾开发效率，RD会进行适当的轻量化设计。而设计模式只是作为参考范本，很少有项目会完整照搬。（而新的设计模式就是在这个过程中诞生的，也就是说书上写的不一定就最适合这个项目。世上没有普世价值和方法。）
4.设计模式是要活学活用，如果只按照书本上的内容去照本宣科，最后就变成了如王明博古一般的教条主义。
1.楼主请别把设计模式奉为圣经……虽然说设计模式应该和语言无关，但实际上是：最早的设计模式普遍由当时流行的CPP、Java等等这样语言为蓝本所著，且楼主所列两书目均是出自于此。
你错了，仔细看看<<C程序设计语言>> Dennis Ritchie，你就会知道，设计模式跟面向对象没有起源的关系。在<<C程序设计语言>> Dennis Ritchie，会给你C语言对于函数是如何原子级别的编写的指导。
设计模式不是圣经，而是必须要经过的过程。不建模，就如同打仗不盘算，盖房子拿起砖就叠一个道理。你的“大厦“会倒塌！！！如果”兵败“，你连条跑的路都没有！！！
另外，如果要追究设计模式的正式定型，应该来自一位建筑师Alexander的《建筑的永恒之道》。
- <<设计模式 可复用面向对象软件的基础>> Gang of Four
- <<面向对象分析与设计>> Grady Booch
- <<Head First 设计模式>> Eric Freeman
- <<设计模式解析>> Alan Shalloway
- <<UML和模式应用>> Craig Larman
我手头至少拥有这5部设计模式的著作，并且翻阅使用了不下5年的时间，至于javascript的设计模式的书我就不说了。我对设计模式的理解和应用的次数超过你的想象。如果你不相信，我可以上传照片，每张书页上都可以画上标记。
2.对于动态类型的语言，多态在语言级的体现已经不太明显，也就是说面向对象的一大特性就此抹杀。GoF写的那些设计模式有一半不能作为语言级的实现。
正如上面所说，如果你看过<<C程序设计语言>>，你应该能明白C语言是完全建立在设计模式的基础之上。而纯函数Haskell和非纯函数Lisp也有自己的模式规则。
另外，我建议你看看Douglas Crockford的json_parse源代码，里边的设计模式非常丰富。
而且，Nodejs源代码本身就是建立在OO设计模式基础之上。
3.楼主显然读过不少书，但是做没做过大型项目就不得而知了。因为很多情况下为了兼顾开发效率，RD会进行适当的轻量化设计。而设计模式只是作为参考范本，很少有项目会完整照搬。（而新的设计模式就是在这个过程中诞生的，也就是说书上写的不一定就最适合这个项目。世上没有普世价值和方法。）
我不只是读，我还在应用和在函数式中提炼设计模式。 你觉得我这篇VIEW视图接口库照搬了哪一条模式？ 如果你要找，你会发现，命令、组合、桥接、装饰、享元，都有他们的影子，但是你可以指出哪条是照搬的吗？
4.设计模式是要活学活用，如果只按照书本上的内容去照本宣科，最后就变成了如王明博古一般的教条主义。
如上。
说起王明博古，我前几天看毛泽东的电视剧，毛泽东这样说某些人：“不谋万世者，不足谋一时；不谋全局者，不足谋一域。都说我毛泽东就是拿本《三国演义》在打仗。可是这些话在《三国演义》里有吗？没有！在《孙子兵法》里有吗？没有！这句话是出自一篇《寤言二迁都建藩议》。我毛泽东看的书可不止《三国演义》！”
最后，如果你的项目，没有建模的基础，你的项目在修改和升级上面临着崩溃的风险。想想当你1万行代码搭建完系统，半年后变成了2万行，又半年变成3万行的时候。
还有，就是，我想知道，没有建模的你，是如何测试驱动、行为驱动的？
真正“大型”的应用不会是属于某个人，所以这个没法“秀”。不过其中的很多单元可以秀一秀，“大型”也只是个容量而已，如我上边所说，是由一件一件部件组合起来的。
我正在为一个项目做mongdoDB mySql的通用接口，node_dbm，你想看也无防。
支持楼主的观点。虽然一个项目最开始的时候，或者说本身注定就是个小项目，则不必要太拘泥于好的模式设计。但楼主也说了，是写“大型”项目的，其实一个企业级的项目，我觉得完全应该做好前期的设计了，嗯，我确实没啥经验，但也经常为一个系统的纷乱头疼。
建议楼主，如果有时间又方便且愿意为朋友们指点的话，能否
开发一个小项目，功能不在于多好，把您说的设计框架搭进去就可以？这样大家也可以更理解您说的啊。。
就我自己觉得，好像做Java的因为框架使用，反而更注重项目的模式设计，而node可能还比较新，也可能是应用级别还不是太高，大家的经验积累还不够，以至于很少人去真的研究怎么用它做出大型项目。
鉴于此，非常感谢楼主的努力~!
