- 论坛徽章:
- 0
|
[转贴]已经过了两年了,不知道结论还正确吗?
我看了你的给的
http://www.yesky.com/20021112/1639500_2.shtml
配合使用数据访问逻辑组件与存储过程
可以使用存储过程执行数据访问逻辑组件支持的许多数据访问任务。
优点
1.存储过程通常可以改善性能,因为数据库能够优化存储过程使用的数据访问计划并为以后的重新使用缓存该计划。
2,可以在数据库内分别设置各个存储过程的安全保护。管理员可以授予客户端执行某个存储过程的权限,而不授予任何基础表访问权限。
3,存储过程可以简化维护,因为修改存储过程通常比修改所部署的组件中的硬编码 SQL 语句要容易。然而,随着在存储过程中实现的业务逻辑的增多,上述优势会逐渐减弱。
4,存储过程增大了从基础数据库架构进行抽象的程度。存储过程的客户端与存储过程的实现细节和基础架构是彼此分离的。
存储过程会降低网络流量。应用程序可以按批执行 SQL 语句而不必发出多个 SQL 请求。
5,尽管存储过程具有上述优点,但仍有某些情况不适合使用存储过程。
缺点
1,如果逻辑全部在存储过程中实现,那么涉及广泛业务逻辑和处理的应用程序可能会给服务器带来过重负荷。这类处理包括数据传输、数据遍历、
数据转换和大计算量操作。应把这类处理移到业务过程或数据访问逻辑组件中,与数据库服务器相比,它们具有更好的可缩放性。
2,不要把所有业务逻辑都放在存储过程中。如果必须在 T - SQL 中修改业务逻辑,应用程序的维护和灵活性将成为问题。例如,支持多个 RDBMS 的 ISV 应用程序不应当分别为每个系统维护存储过程。
3,通常,存储过程的编写与维护是一项专门技能,并非所有开发人员都能够掌握。这会造成项目开发计划的瓶颈。
它是用ADO.net举例了。。。我没用过不好评论。
JavaBean EJB到是懂一些。
只要合里使用,应该没问题。太依赖程序也不好,如果是C/S结构,要改一动一下程序,就得编译。然后全公司都要装一遍。(只是个例子,现实中可能很少遇到)
如果用EJB技术 。数据访问逻辑组件部署在Application Server 上,这样做好些。如果数据访问逻辑组件全放在client端 处理我不支持。。。 |
|