对三层架构不是很了解，欢迎进来讨论！
我仿照petshop做了一个网站，用到了存储过程，所以我很多的业务逻辑写到数据库里面去了，请问这是否是严格意义上的三层架构？大家对存储过程是什么看法？平时写三层的时候会用它吗？
[解决办法]
个人 感觉也是
实际的操作中
为了性能 和 一些其他原因
更多的业务 处理被 放到了 存储过程中
当然对于 存储过程 个人认为是 提倡使用 :)为了效率
[解决办法]
我不喜欢使用存储过程，不利于移植
[解决办法]
比如如果数据库改成access,就不能用存储过程了
[解决办法]
说句 实在话..
实际上 真正 要做 移植的 时候
并不是说 用不用 存储过程的问题了
本身 就应该 重写 数据访问层
除非你一开始就直接 用工厂模式 反射加载...
还不是要多写access的访问模块
[解决办法]
从历史上说，三层或者N层是出自分布式系统的需要，多个客户对一个数据库服务访问是2层；多个客户对1个应用服务，然后1个应用服务再对1个数据库服务是3层。3层相对于2层，对客户的界面是业务对象，所以比较直观，同时很多操作也可以“粗粒度”一些。不过现在大家把它随便加在同一个进程中，也就顺水推舟了。
业务逻辑使用存储过程来写，本来就是数据库系统编程风格，完全可以。SQL这种4GL语言相比于3GL语言也有很多优势，它可以使用一两条语句就可以做3GL语言上百条代码也不一定能描述清楚地程序。
不过数据库对象的结构比较低级，对于复杂的系统或者那些比较精通（或者假装精通）面向对象设计的人肯定觉得低级，这是其缺点。
另外，存储过程至今没有统一标准。不像国内前一段吹捧“web标准”那样可以搞运动，由于很多数据库厂商已经非常成熟，写SQL基本上只能遵守10几年前的标准（而且基本是入门版），近10年的标准无厂商真正实现。所以如果你有一套成熟的应用层可以跨异种数据库系统至上，应该尽量发挥其优势。
[解决办法]
在普通的B/S结构中，加入一个新项目，专门负责数据库的管理的类和函数。
就是最简单的三层了。
[解决办法]
死搬一个几层的定义没有意义
[解决办法]
你是开发网站而不是开发三层架构
只要你的类之间逻辑清晰随便你几层有什么关系，不分层都没关系
至于存储过程那还真是个好东西，写前台就算是刚来的新手也能胜任
[解决办法]
业务逻辑不应写到数据库里面
这说明你的数据库设计不合理，耦合度过高~
[解决办法]
学习
[解决办法]
看到了好多星星～
[解决办法]
一个拓展性强的网站,应该严格遵守三层架构.这样在以后的维护,升级,组件复用方面会好一些.
[解决办法]
正在学习所谓三层开发，路过学习，谢谢楼上几位前辈！
[解决办法]
需要在耦合程度和性能之间找一个平衡点
[解决办法]
关注，顶一下
[解决办法]
用存储过程 != 把业务逻辑写在里面
[解决办法]
无论黑猫白猫,能抓住耗子就是好猫
[解决办法]
用存储过程 != 把业务逻辑写在里面
这个看项目 需求
没法 定论
需要在耦合程度和性能之间找一个平衡点
[解决办法]
学习
[解决办法]
学习啊,,,,,,
