Layer
层(Layer)的概念在IT世界中解决了很多复杂问题。随着基于Service的Web应用越来越多，Layer的概念离大众用户越来越近。希望我不善表达的文字能够把这个概念解释清楚。
分层的设计在程序设计中已经是最基本的设计模式（Design Pattern）之一。举几个例子让大家找点感觉。
作为一名非专业程序员，MVC的概念我都已经听说多年了，证明它有多么的古老。简单来说，MVC的设计模式将程序分解为Model，View，Control三层，分别负责数据，表现，业务逻辑。各层之间相互调用，但是又不是强耦合。
MVC的出现，使得软件设计分工成为可能，每一层可以将给不同的程序员维护。当然MVC还有其他好处，比如分布式部署等。我这个业余人事就不多发表评论了。
Hibernate是Java中进行ORM(Object Relational Mapping(对象关系映射))的框架，通过Hibernate，可以使用操作对象的方法操作数据库记录，而且更改底层数据库不需要调整前台的代码。
URL Dispatcher是Django中我很喜欢的设计之一。可以让设计者设计非常Sexy的URL而不用考虑后台的文件结构。因为是URL解析之后指向View中的一个方法，URL可以在不变动后台代码的情况下随意修改。
互联网本来就是多层架构，好像是六层还是多少。网络服务现在也有分层的趋势，照例还是看几个例子：
Paypal是互联网分层的一个经典案例。当Paypal没有流行之前，网上支付是一件痛苦的事情。因为那时在美国全是信用卡付帐，网上交易对于用户来说存在风险。Paypal的出现，在用户和商家之间增加了一层支付层，商家拿到了只有一个Paypal账号，降低了支付的风险。至于提高了支付的便捷程度，我们可以认为那是副作用。
Feedburner其实是一项很简单的服务，它将RSS Feed的订阅独立了出来，在网站和用户之间加入了一层。然后在中间层加入了数据统计，Feed优化等增值服务。
Openid是最近很热门的一项服务，似乎让人们看到了全球唯一ID的可能性。Openid解决了用户注册及身份验证的问题，让用户不需要每到一个网站都注册一次。
不知道看了上面的例子之后大家是不是都有一种跃跃欲试的感觉，但是在大家去搭建自己的服务之前，可能需要注意下面几点：
本文只涉及到层服务很小的一个部分，写的不完善请见谅。
- 中间层应当是前后兼容的。如果Paypal只支持部分银行的信用卡，或者需要商家花很大力气才能搭建Paypal支付平台，Paypal可能就不会有现在的成功了。
- 层服务应当是可轻松替换的。我现在使用Feedburner的服务的方法是将我的RSS Feed转发到Feedburner上，所以当大家在访问http://www.adieu.cn/blog/feed/时，就会把大家自动带到Feedburner的输出地址。如果将来有一天，我想使用Feedsky管理我的Feed了，我只需要改变一下设置，将Feed转发到Feedsky就可以了。Blog程序和订阅的读者们都不需要做任何设置变动。
- 层服务应当是开放的。Openid之所以能够成功，和它的开放有关。如果Openid最初的设计是提供一个每个人都可以去注册的服务，然后由它去完成所有的用户信息管理和身份认证，那么Openid有99%的可能是一个失败的项目。但是Openid采取了非常开放的态度来设计解决方案。任何人都可以架设自己的Openid Server，最终用户还可以使用自己的域名作为Openid的URL。可以说，开放成就了Openid。
- 就算是面向最终用户的网站，也应该提供开放的API。国外很多成功的网站都提供API供开发人员调用。这样可以衍生出很多新奇的应用，也能带来更多的流量。另外，垂直搜索引擎也能够很容易的获取数据，而不用写爬虫。
- 设计服务时应当从现状入手，而不是做很多不切实际的假设。是的，层服务确实很吸引人，大家都会幻想，如果我能够在现有的体系中加入自己的一层，可以带来什么价值，如果我能有多大比例的人来使用我的服务，我就将有多大的收入。可是事实上，推广这样的服务却是困难的，如果方案设计有问题的话，很容易颗粒无收。Google很早就提供了自己的身份认证API，也梦想着能让世界上所有人都有一个Google Acount，这样大家在任何网站都可以使用自己的Google Acount进行身份认证了。可事实上，注册Google账号的人越来越多，但是使用Google身份认证的网站却少之又少。
