来这里看这个贴子N久了，真是郁闷。越看越郁闷。
//-----------------------------------------------------------------------
看了很多关于三层的文章 都是提倡什么业务封装之类的 也就是在显示层上实现无SQL
语句 我研究了段时间 发现这样根本很难实现 而且很大程度的增加了开发成本
各位的三层到底是怎么做的？？？？？？？？？？？？？？？
//-----------------------------------------------------------------------
真是搞不清楚你们怎么理解的？ 什么叫表示层无SQL语句。不能怪李维，是不是觉得看了看李维的三层架构的书就真正掌握三层技术了。不要吵，不要怪别人，三层，还是先了解了解，三层究竟有哪些好处？ 我为什么要用三层吧？
如果你不能回答这个问题。就学习一下。就不要把哪种MIDAS固有的这种做法搬到现有的开发上来。事物都是两方面的，不要以为MIDAS就不好，也不要认识MIDAS就能解决你的所有问题。
估计有人会觉得我在这里废话连篇。 其实我是真讨厌别人讲废话的。我实在是不吐不快。废话打住。讨论点实际问题。
客户端不用SQL语句，对，基本上对，为什么基本上对，因为我不能百分百确认用就一定会好，事物都是两面性的。那就说说不用情况吧。
分成三层的原因，我就不详细说了。举例子说吧：
一个客户端，有一个复杂的业务逻辑。可能这种业务逻辑是变化的。比如说银行利息可能会调整。也可能是要因为超市购物而临时决定的打折方案。
对于客户端来说，我不想关心这些。我为什么要关心这些，关心这些，只能让我陷入修改代码的泥潭。烦躁。对客户端来讲，要求很简单嘛。 我只需要把 商品，会员（金卡，银卡，一般）信息，等等提交给中间层。然后我得出一张付款清单。我的要求很低嘛。
这个时候中间层的优势就体现出来了嘛。这里的中间层请大家把它当成一个逻辑的中间层，到底是不是需要布署到另外的机器上，先不要关心。中间层干嘛，接收数据，处理，返回数据给客户端嘛。有什么优点，不言自明。中间层有什么方案，变化。客户不需要知道嘛。SQL语句，更是一点关系都没有。试想想吧，客户端在处理业务逻辑的时候还要关心SQL，真是十分不合理。实在不合理。客户端不想，也不愿意关心这些。它甚至连业务逻辑怎么处理都不愿关心，更别谈什么SQL语句了嘛。
对中间层来说，这个接口应该是稳定的。不变的。客户端什么时候都需要支付嘛。这个业务在商品相关的MIS中，是不可缺少的嘛。谈到接口，我不得不再谈一下。接口的发布是很有讲究的，如果你经常把接口改来改去。你会说，拜托，我需要多传一个参数到中间层去。因为我要改这个接口。郁闷。确实郁闷。但只能说明一点，你对三层不了解。也许你会写几个接口方面的死程序，但你永远没有领会到接口的神蕴。
更好的一点的方法是，传递一个对象到中间层， 注意我说更好，是不是最好，我没说，实际上有更好的解决办法。假设传一个对象到中间层吧，这样很方便了，你需要什么数据，我生成一个对象，再搞一个对象容器，把所有的对象，一次提交上去。接口参数是对象，所以接口稳定呀，对象可以增加内容嘛，但接口又不会变。当然，确实是这样，但这样一来，问题又有了，什么问题？ 大家知道DELPHI不象JAVA这种语言，它不可能动态为对象增加一个属性，方法。在编译的时候已经确实了，这样，在中间层和客户端是不是都要维护这个对象？当然，所以客户端如果要改，中间层肯定跟着要改。
就这个问题， 我和很多人讨论过。最终讨论的结果是，如果接口必须要改。不可避免的中间层和客户端都必须要改。但对于怎么改。学问就大了。有一种方法，叫做插件法的最好，插件，大家估计都知道。即插即用嘛。一旦业务逻辑接口发生变化，只需要做一个插件挂到中间层就行了。业务逻辑自动发生变化。听起来不可思议。其实也没有不得了的高深技术在里面。简单的工作流机制嘛。
经常给兄弟讨论这个问题。每每谈到接口变化，我们总要急论一番，说说经验吧。接口一定要做成抽象的。比如你要提交一批数据。OK，这些数据会变。没关系，做成一个固定的数据，但要接受可解释的数据。 明白了吧，提交的数据要能解释的，就会由不同的消息分发机制调用不同的业务对象， 象插件一样，多做一个插件到系统中（DLL，BPL）等。然后用注册的方式到消息分发中进行注册。数据解释类进行解释。这一切工作就不完成了嘛。
当然你要说，糟，数据解释不同，我还要改代码呆，当然，你可以派生一个新的解释器，或者用（简单的）重覆去搞定它了。 毕竟接口是不变的嘛。
客户端为什么要变呢？为什么要用SQL语句呢。
我的BLOG：
http://www.delphibbs.com/keylife/iblog.asp?author=wu_yanan2003
