JDON中有没有封装存储过程的调用方法？

我是反对通过传统方式使用存储过程的。如果不会以DDD方式使用，不如不用，所以2002年开站以来就一直反对存储过程，当然当时被很多人痛骂。

原因：存储过程不易于拓展和维护，虽然性能不错，现在我们有两全其美的更好的方法。

那请问一些复杂的业务在JD中如何解决,涉及多表操作时.

微软的培训中希望大部分的操作要要封装在存储过程中，因为本身存储过程也是一个接口，不过反驳的人通常说其不具备移植性。

java阵营好像一般比较相反，强调不使用跟数据库相关的东西，select要选择符合SQL-92标准的sql语句。

我个人认为这两种都在走极端，把一个简单的select语句封装在存储过程中对本身效率的提升是很有限的，但是如果把负责业务逻辑不通过存储过程封装，而直接通过代码实现对效率是一个考验，缓存只能解决存储以及显示问题，但是不能解决业务逻辑运算的问题。

微软的培训中时常重复的一个词是性能，可是在java的培训中通常是架构。呵呵，很有趣的现象。

>那请问一些复杂的业务在JD中如何解决,涉及多表操作时
学习Eric Evans DDD，在OO分析设计中概念中，几乎不涉及多表的概念，要转变你的思维到OO上来，不要谈到业务，第一个反应就是“表”！！！！

>微软的培训中希望大部分的操作要要封装在存储过程中
不管微软或Java技术，都遵循分析设计思想，现在我主导的java培训中已经紧跟先进技术水平，加入Evans DDD思想，在DDD中已经说明如何对待存储过程，你说的那些微软培训还没有跟上时代，不要老是将现实中落后的现状和我们倡导新思想做比较，需要与时俱进改变你的思维方式。
[该贴被banq于2007年04月17日 11:48修改过]

呵呵，谁先进，谁落后现在很难说清楚的。关键在于你怎么看待这个个问题。

关系型数据库是落后了，可是不管oracle还是ibm。ms都还在努力发展这个东西。
从开发工具而言，工业化大生产进步的标志应该是生产力的提高，现在用vs2005几乎不用写一行代码就能完成很多软件需求，而依照DDD的方式进行可能还要工作很长时间。所以先进的标准是最大的问题。

ms的授课也是去年的事情，petshop1.0可以说是oo的方面教材，可是现在微软的petshop4.0已经可以作为oo设计的教科书了。

>谁落后现在很难说清楚的。关键在于你怎么看待这个个问题。
不是如何看待问题的问题，而是看问题这个人的思维意识是否与时俱进的问题。

所以，不要对自己的思维或经验过分自信，我也是这样，经常反省自己，这样看问题是否合适？

>现在用vs2005几乎不用写一行代码就能完成很多软件需求，而依照DDD的方式进行可能还要工作很长时间。所以先进的标准是最大的问题。

现在RoR等很多依据DDD思想的工具也都是几乎“不用写一行代码就能完成很多软件需求”。

但是，这里还是我以前在帖子一再强调，：
你现在可能不用写一行代码，将来需求变化，你可能要写10倍的代码，如果抛开软件质量问题，单纯谈论代码快速与否是无用的。

呵呵，不知道听IBM跟ms的讲座算不算与时俱进吧。

java的培训、ms的培训，以及一些供应商的培训基本上一年也参加过不少。呵呵，总不能不听DDD就不算进步吧。ibm跟ms都落后了？？

RoR只是生成相应的类，对于界面的解决方案还不是很完善。vs2005是从界面到service，到dao的整体的整体解决。

不知道banq大哥的软件质量是如何定义的。速度算么？？强壮度算么？？呵呵，给出定义我们才能确定出来的。不能你说强就强吧。
[该贴被Coolyu0916于2007年04月17日 14:48修改过]

>知道banq大哥的软件质量是如何定义的。速度算么？？强壮度算么？？呵呵
希望你多多看看论坛中的精华帖子，包括我的发言，这些问题已经跟本帖无关了。

97年的时候我用Oracle，觉得存储过程真是个好东西，方便、高效，那时甚至追求将所有需要的结果都封装到一条条SQL语句的返回结果中。

很快就体会出来了，那种系统维护性基本=0。面对一堆堆的脚本，修改困难，调试更困难。后来我一听这个词就反感，能不用就不用。

本身DDD就不是所有软件项目执行的最佳方案，去看看DDD关于SMART UI那一段就知道了，要分清楚你解决领域问题的规模有多大，再考虑是不是用ddd