谁告诉我，究竟为什么老外总是想通过model产生一切？？？

由于业务太简单了...
所以才有你的这种想法

但凡需要用到数学模型的东西
用界面作需求就有点太单溥了....

再复杂的业务都要体现在介面上的。介面上有些细节，一些很简单的提示消息，往往代表非常复杂的业务逻辑。打印出来的报表也是介面，很多报表后面的业务逻辑都是非常复杂的。

而且，绝大多数情况，客户实际上不知道需求究竟是什么。介面作为需求的体现也是最好的交流媒介。

“用到数学模型”这个不是很明白，能不能举个例子？

界面是股市的曲线图时
你认为程序员能看的懂这个图表所带表的含义么?
.......
如果设计书连程序员都看不懂又能怎么做呢?
你作的业务多是增删改查
所以常常会有页面驱动这种冲动

我现在作的系统一个表2百个字段(原古代的东西)
每个业务只能表现出某几个字段的关系

模型死都猜不出是什么样子的...

外国人吃喝不愁，吃饱了撑了贝

除非是那种几乎无分工的作坊式开发团队，否则程序员能否看懂这个图表意义不大，因为客户不是程序员。
依照你的逻辑，我可以有如下表述：
当系统是用代码写的时候，你认为用户能够知道如何使用这个系统吗？:D


“设计书连程序员都看不懂”这个又是怎么冒出来的？


当然，不可否认的是，我做的系统中很大部分是CRUD的动作，难道你的不是？


200个字段，这个数据在这里并不能表述出业务的复杂性。以前做过HIS系统，超过200个字段的表并不罕见。也有可能你的业务非常复杂，但是对于客户而言，用那么多字段和他有关系吗？数据库中“表”这个东东和他有关系吗？这些只是我们技术人员为了实现客户需求自己使用的。
模型和数据库表一样，对客户而言，没有意义。

但是介面不一样，对于客户而言，页面上什么时候出现什么信息，与系统交互时，什么样的交互方式更合适，这个才是重要的。而这些却是对我们系统内部逻辑有决定性的影响。

最重要的还是脱离“以技术为本位”的思考方式。

内容重复提交了,删去

你想说的是以OO为本的设计思想。。。
以界面为驱动的这种方式很接近了
我也用过。。。

不是由于不喜欢
而是由于真的有很多
需求的问题 产生。。。

赫赫，我说的和OO没关系。说的是原型化开发。正是遇到很多需求问题，所以，我才会逐渐倾向于原型化的方式。原型化+RAD+迭代

Model产生一切，实际开发中可以认为是“Model--〉Database-->UI”这样的想法。但我认为“Database-->UI”这样做的局限性是非常大的，只能用在完全的CRUD情况。
在我的认识中是：

UI--> Model--〉(Database+UI)
       ^                 |
       |_________________|

(这个表达我不是很满意，有更合适的我再改)
所以我在做系统的时候是在中间加一个环节。

本站也已经有人在进行一些实践，见
http://www.iteye.com/topic/38774

他把Bean扔掉，使用了map，list等原始的data container.

我在具体项目中对系统进行了分解，从两个方面进行，一个是Data，一个是flow，
data是通过
UI Elements<--->Data container<--->Database
flow是在各自层次编码解决，
然后以data为主线，用code generator分别用
UI-->Data containerA
Database-->Data containerB的方向进行代码生成，
除非是纯粹的CRUD操作，Data containerA与Data containerB不可能达到直接连接的目的，中间总是有业务操作，所以交由相应的flow处理。
当然，在具体实现中，为了充分利用eclipse等IDE的工具的编码检查功能，在Data container中的部分，也用到了JavaBean。
UI Elements直接使用标准的HTML及简单的js等方式定义，只外加少数的特殊规则，用于控制页面展现。

在保留了OO的思想，抛弃了所谓的主流OO实现后，开发效率，系统执行效率也得到了很大的提升。
代码编写中，程序员只需要做UI以及业务编码，其他代码基本都用代码产生器搞定。

(在实际的项目中使用，每个项目功能点约1万)

to basicbest:
如果你觉得model就是data container，或者data container完全可以代替业务层，建议你看看《领域驱动设计》这本书，会对你有所触动。

我有一篇文章，描述了最基本的领域设计方式，希望对你有一点帮助：
http://www.cnblogs.com/lane_cn/archive/2007/01/25/629731.html