讨论Midas三层结构中的业务逻辑实现的问题

Question

三层结构的中间层在资源，事务的控制方面确实有很大的作用，但另一方面中间层的业务集中是怎么体现的，也就是要实现瘦客户端，我好象还没见过很好的例子，很多三层结构的中间层仅仅实现了数据库的连接的公用和控制，事务的管理，负载的调度，但是业务的集中做的不行，客户端还是很大，有大量的代码实现数据的显示和交互的功能，甚至是数据的过滤和校验？？？？
   希望有高手指点迷津！！

Answer 1

密切gz..........
強烈gz................

Answer 2

from mota骆la 
1。你必须明确一下，什么是“瘦”。它的意思何在。它绝对不是要把所有的逻辑都放在服务器端。我们写软件的最终目的不是要客户端最小，而是系统性能最优。比方你说的过滤，如果每过滤一次都要到服务器端进行，那么网络拥挤程度可想而知了。所有的情况要有一个整体的权衡。
2。瘦的概念主要是在业务层面上的，客户端不用负责业务处理，比如数据库的直接操作，复杂的运算等等。表现层当然还要在客户端。最重要的一点是，性能和可扩展性

Answer 3

呵呵，其实，不一定都要给中间层，的确，我们知道，MIDAS提供了上下文的中介，提功了很好的安全性验证，但是我认为完全没有必要将一个系统的所有安全性检查放到中间层去实现，比如数据规则就可以让客户端来完成，这样，在多客户的系统中不但可以降低服务器的压力，而且好处显而易见，也就是不需要数据进行回传；当然，中间的业务逻辑所包括的东西实在太多，一下根本无法说清，传递参数，可以尽量用静态的传递方式或是称静态的调用接口进行传递，这样，速度快而且出错相对较少；数据流量大与否，说白了，是程序员对程序的理解程序，什么样的数据量算大呢？什么样的数据量又算是小呢？这是一个很大的概念，就如你用变量有Long Integer 要比Integer要节省资源一样的小问题都需要考虑进去，然而，降底数据流的方法我们可以用间接的方法去完成同样的功能，可以减少网络的回访，接口的少认证等方式；可以将一个许多的小的业务逻辑对像封 装到一个大的业务逻辑对像里边，当然，关于效率的问题，还需要作者自己去尝试；问楼主：客户端做的很大？那么都大都了那些方面？你如何理解？你希望是什么样的？那样的效率会更好些（当然，包括分发和升级）？
从我而言，我认为业务的集中完全没有必要当做一条定律来看；集中是什么？呵呵，我倒是觉的集中就像接口对像一样，是各个小模块的集合，那么小模块又是什么？又在那里呢？还是一起讨论吧

Answer 4

呵呵，楼上的大哥，有兴趣看一看下边这个贴子吗？
并不是每个人都同有做过多层；也并不是都在空谈http://expert.csdn.net/Expert/topic/1090/1090950.xml?temp=.9456446

Answer 5

楼上的弟，看过了。以后多多联系。
我的地址 [email protected]

Answer 6

过滤也放中间层?
请问一句?
它属于业务逻辑吗?
答案"不是",有了这样的思想你就找到答案了.
有空瞧我的文单.
http://expert.csdn.net/Expert/topic/1227/1227094.xml?temp=.734585

Answer 7

我觉得不要太局限于客户端还是服务器端！
重要的我们要用面向对象的方法来对企业对象进行抽象。
比如企业的 物资入库操作
客户端进行入库单录入->调用服务器端的入库单协调对象.新增入库单服务>
然后由协调对象调用入库单头企业对象的update和入库单体企业对象的update方法->客户端审核->调用服务器端的入库单对象.审核入库单服务->
然后由协调对象调用入库单头企业对象的update和入库单体企业对象的update方法和库存企业对象的增+or-库存服务or其余的服务总之该在客户端的操作只是与用户的交互(要尽量减少与服务器端的频繁交互)
至于数据的校验要看是什么校验了，是设计业务的校验还是不设计业务的呢？
当然上边的流程可以+一个check服务（负责验证头和体数据的合法性）等等，还是要自己多试才行啊
而在服务器端则进行全部的业务处理

Answer 8

一般的查询用的SQL语句是放在客户端上好还是话中间层上好?

Answer 9

一般的查询放在客户端，用commandtext。如果在查询中包含有业务逻辑，则可以在Tdatasetprovider的ongetdata事件中进行业务逻辑的处理，再将数据集返回给客户端。