一个大量使用存储过程的系统，还叫三层吗？ (5分)

不明白你在说什么,用不用存储过程与三层有什么关系?
是不是一个真"三层",与存储过程根本扯不上关系.

到底什么叫三层？我觉得中间层简单的业务封装也不叫三层。

反正我不能真正吃透三层，只好使用二层了。

多层的最主要目的就是将业务逻辑封装在中间层,
业务对象:业务逻辑封装在中间层业务对象中,其好处是很多的,比如统一控制业务逻辑,方便修改,安全性好(除非你能接触到中间层服务器或者系统的设计有bug,你不可能能通过修改客户端程序来达到非法目的.而你是没有办法保证运行在客户机器上的客户程序不被人为修改的)
业务对象容器:比如象com+中的mts(com+包括mts的升级版本和适合这种升级版本mts的dcom组件模型的升级版本),weblogic中的ejb,servlet容器等.除了业务对象容器,中间层也为业务对象提供其它运行环境,一般也还提供安全性管理,事务管理,对象/客户线程/数据库连接等资源pooling等,在安全性和性能方面提供支持,并建立中间层接受和回应客户端调用请求的通道.
一定要说有"真假三层",那么看是不是"真"三层,主要标志应该就是看业务逻辑是否封装在中间层业务对象上而不是客户端.但是用不用存储过程,我认为与是不是真三层是没有关系的,虽然存储过程是数据库层的东东,但将部分业务逻辑在存储过程中实现,也不会对这种架构的初衷(业务逻辑统一控制,方便修改)有何影响.
oracle现在有初步对象数据库影子(而且还有java存储过程),而ejb中的实体bean往往直接影射操作一个数据表,中间层业务对象以后会与物理数据库结合得更紧密,或许oracle以后就是一个中间层应用服务器(oracle9i As可就是一个J2EE服务器),同时又是一个dbms.他们的明确界限会很难区分
个人粗浅看法

具体该怎么样在中间层上实现企业逻辑，有没有个例子啊？

如果使用delphi实现中间层服务器,目前delphi的几种解决方案,归根到底,服务器业务组件模型都是com(/dcom/com+).
webConnection/SocketConnection是通过代理程序,WebServices也是通过web层上的ISAPI/CGI/DSO等程序代理调用,他们都是由服务器机器本地调用Com对象,配置方面就简单一些.DComConnection则是直接用RPC远程调用,不用DComConnection也可以直接用CreateComObject来创建远程对象,不过后二种配置就麻烦一点
这种架构的话,就是写com组件,输出接口方法供客户端调用,在com接口方法中实现业务逻辑,即便是在实现方法中是调用存储过程实现业务逻辑,对于客户端来说,业务逻辑仍然是在中间层业务对象中实现的,可以说仍是"真"三层(假设有真假三层之说的话).
delphi为了简化开发,提供了一个IAppServer接口,这个接口中包括了一些方便的数据获取和更新方法,大大简化了开发过程,但它的不好处,也就是delphi程序员常说的的"真假三层",通常就是针对这种使用了IAppServer接口方法来获取数据和更新数据的情况来说的.
我们通常用Delphi方法所写的三层结构程序,用的远程数据模板或MTS数据模板,,本质上就是Com对象(Dom/com+),它就是实现了IAppServer接口的对象.远程数据模板或MTS数据模板以及直接com+/dcom对象,从结构上就是三层中常说的"业务组件".
其实我们既可以方便地使用Delphi为三层结构设计的一些解决方案(核心是DataSnap的数据接头技术[TDataSetProvider],另外还有Datasnap的数据封装技术[方便地封装数据集和delta包到oleVariant和XML],DBExpress数据库驱动技术,这些技术现在都已经移值到dotNet下面,可见其功用),又可以实现"真"三层,其要点是不要直接使使用IAppserver接口方法(实质上,因为业务组件实现了这个接口,他的方法也就是业务组件的方法,只是这些接口方法比较象C/S中的数据处理流程而已),而另外创建接口和接口方法供客户端调用,在这些方法中,同样可以方便地使用Borland的数据接头技术来获取数据和更新数据,我们可以动态生成数据接头和数据集,来实现业务逻辑,有关这方面的实现,看一下TDataSetProvider文档就很清楚.
com+有非常好的安全性管理,可以精确地控制到一个接口方法的权限,而对于DCom无状态的业务对象,我们也是有办法的,在接口方法中,我们可以检查一些会话状态,这些会话状态的实现,当然要我们自己想办法,其原理和思路可以参考于为http这种非长连接的协议设计的Cookie/Session机制,如果不用讲究效率,你直接访问数据库检查权限都是可以的.但是归根到底,一定要注意到业务逻辑要放在中间层实现,安全性的最终保证也是要在中间层,而不是客户端,要知道运行在客户机器上的客户端程序,操作者可以任意修改的,甚至写一个模仿程序[].

我觉得,需求决定一切,用不用三层要看客户的需求情况.如果一个十几个客户端的软件运行在局域网中,没有什么特别的要求(比如直接访问服务器文件,极高的安全性要求),实在没有必要用三层.

我认为真三层和假三层的争论是没有必要的。
无论c/s还是三层，初衷也是为了 分布计算 移植方便，容易扩展，业务与ui分离，为客户服务。本来客户就是一个局域网甚至一两台机器。搞的那么复杂算什么样子。
但是如果企业是个全国的。甚至是跨国。你的软件如何去支持这么大范围，你的软件如何跟着市场变化增加功能。
环境不一样，为什么还要按原来的记号办事情呢。那不是刻舟求剑了吗

我觉得应该减少存储过程的使用，产生三层的目的就是要将业务逻辑封装在中间件上，这样可以减少系统的维护成本。因为在修改的时候，只要修改中间件上的业务逻辑就可以了。
而如果，又同时使用了大量的存储过程以后，就不得不维护一部分逻辑在数据库上。而且，使用了sp系统的数据库独立性就降低了。

我在用这种方式做 c/s + b/s
小型intarnet lan 用 c/s
外网 用 b/s (.net ,或者asp)
这些都要求有个好的 一个或多个数据服务器

权衡标准是在于对于业务逻辑处理时对参考数据的采集的，系统的处理资源消耗，
系统资源的有效利用
业务逻辑处理的完整和健壮
由应用层进行事务控制，有效的提高数据库的并发处理能力！