这是一个曾被热烈的讨论过的问题。之所以忽然谈起这个，还得从我们今天的一个项目验收中我们与客户的程序员之间的争议说起。我们的项目采用的是常见的三层架构：DataBase - ApplicationServer - Client，在ApplicationServer中放置了鉴权、运算、指令路由、通信服务、Callback等方面的业务逻辑代码，并对客户端公布相应的调用契约（接口）。在客户验收的过程中因为一个失败的数据库操作服务引申到客户方的程序员对于N层架构的质疑。该程序员令人咋舌的观点是：“N层架构惟一的忧势是可以省去一些数据库调用上的License"。——这番话不由得让我想起来我当年写的一套很肤浅的DELPHI N层操作框架（其实那套框架用于快速开发还是不错的），1999-2000年时，DELPHI中N层架构设计的思想刚刚起步，而在当时根本不知业务逻辑为何物的我抱着一种无知者无畏的心境快速的推出了我的DELPHI“三层框架”，其实这个所谓的框架中，中间层什么也没做，只是充当了一个SQL相关数据操作的一个通道转接的作用，而相关的业务计算过程全都在客户端进行……
还记得1999-2002年，多层设计要不要采用在大富翁论坛上屡屡被提起，但总是没有什么下文。那是一个软件架构设计思想刚刚开始升华的年代。随着COM/DCOM/MTS/CORBA等多项分布式技术的不断发展成熟，传统C/S架构的生存还是毁灭，各自都有一派忠实的拥趸者。而什么是分布式架构？分布式架构中商业智能与数据持久的代码如何切割？各层之间关系的维护及代码精细粒度的控制都是软件架构师们在很长一段时间的疑惑。软件设计的思想总是不断向前发展，而我们的疑惑也在慢慢的解开。不得不提提那句开发界的名言：“开发环境及开发语言决定了开发模式”（大意是这样吧），说到这里不能不说对Borland Delphi及C++Builder的失望，曾经RAD开发的王者，却没能借此优势形成相应的开发模式及社区氛围，而过份对RAD的倚重只是为他培养了一堆只会拉拉控件连数据库的肤浅的程序员。其引以为傲的VCL中一切以控件为中心，完全忽略基础设施的建设——像单双链表，List，队列，集合之类的一些最基本的数据结构的元素都没有提供给使用者。从这些元素上去考虑，DELPHI之类的一些RAD工具走向没落不是没有原因的。
说了一大堆的废话，我们再来具体谈谈N层设计应该是怎样的一回事。当然，这个只是我同圈里一些朋友的观点，我们欢迎有不同的声音。先来说说业务逻辑，什么是业务逻辑？以数据库的系统来说，在我们看来，软件架构中所有与数据运算、数据判断、数据持久等方面相关的操作都属于业务逻辑的范畴。举例来说，如果我们客户端需要登陆到系统，那么登陆的过程便是一个业务逻辑，可以在应用服务层开放一个帐号管理的接口，如：IAccount，登陆只是该接口中的一个方法，如：Login(UserInfo userInfo)，对于客户端而言。我们只需要传递相应的一些登陆信息到应用服务端，而应用服务端如何验证登陆，这个则不是客户端需要关心的内容。应用服务端向数据库发出怎样的查询指令，写入怎样的信息这个都是应用服务端的事情。客户端需要知道的仅仅是，应用服务端有这样的一个调用契约，成功与否，都会有相应的一些约定信息返回。就如同我们通过COM调用Excel一样，我们并不需要关心相应的读写操作是如何进行的，我们只需要知道有相应的调用接口即可。
分层设计的意义是什么？为什么要面向接口开发？先来讲讲面向接口开发。我觉得这除了维护软件本身更好的架构外，也可以将一个开发小组中开发人员的职能分离：在项目开始的时候，项目小组的成员先依据用户需求定义出具体的接口规范。然后安排相应的人员对相应的接口作出实现，并作UnitTest，在最后的环节再完成代码的拼合，甚至设计出开发小组的daily builds（每日构建）服务。从这个角度上来讲，面向接口开发可以很好的调配开发小组成员，让项目经理可以依据不同成员的能力、任务来控制项目开发的日程。那么分层的意义是什么呢？前面也大约提到是分离业务逻辑，就上面的例子来说，如果我们将登陆的过程放在客户端，一旦登陆的规则发生改动，那么我们所有的客户端程序就都需要更新，再者，您放心直接给客户端的机器访问数据库吗？安全隐患不言而喻，而如何我们将这个逻辑放置在应用服务端，则无论是在后期的应用规则修改还是数据安全的系数上，都会有一个较大的提升。
写得比较凌乱，大家凑合着看吧。