手头有个项目，先说一下设计,是一个传统的形式：
------------
数据库
------------
数据访问
业务层
------------
服务代理
UI（WinForm）
------------问题来了：
例如：
1.业务层取数据A，B，C，
2.进行处理，
3.返回结果到UI。由于业务上的计算较为复杂，处理中涉及的数据较多，所以比较耗时。
而项目中又设定数据库超时和服务器超时，也就是在执行第一步的时候，由于A的数据量很大，数据库超时了。即便数据库没有超时，在A，B，C三项的累积时间就使服务器超时了。所以项目中出现了一种畸形：（注：实际上，如果数据很多，可能还会分批获取。）
1.业务层取数据A
2.返回A到UI。
3.业务层取数据B
4.返回B到UI。
5.业务层取数据C
6.返回C到UI。
7.在UI进行处理数据A, B, C
这样子，业务逻辑处理就全部搁在UI上了:( 这个服务端变成了一个持久层。大家说，这该怎么办好呢？
希望给点建议和意见，谢谢:)
------------
数据库
------------
数据访问
业务层
------------
服务代理
UI（WinForm）
------------问题来了：
例如：
1.业务层取数据A，B，C，
2.进行处理，
3.返回结果到UI。由于业务上的计算较为复杂，处理中涉及的数据较多，所以比较耗时。
而项目中又设定数据库超时和服务器超时，也就是在执行第一步的时候，由于A的数据量很大，数据库超时了。即便数据库没有超时，在A，B，C三项的累积时间就使服务器超时了。所以项目中出现了一种畸形：（注：实际上，如果数据很多，可能还会分批获取。）
1.业务层取数据A
2.返回A到UI。
3.业务层取数据B
4.返回B到UI。
5.业务层取数据C
6.返回C到UI。
7.在UI进行处理数据A, B, C
这样子，业务逻辑处理就全部搁在UI上了:( 这个服务端变成了一个持久层。大家说，这该怎么办好呢？
希望给点建议和意见，谢谢:)
严格的来说，数据访问层也可以用来处理一些数据，最常见的应用就是“数据仓库”技术，宏观的来说都是数据访问层，但数据访问层中可能还会细分出一些对数据进行策略处理（是不是不业务处理有可能并不能一刀切）。其实设计是为业务逻辑服务的，有时候为为了特定的需求，你可能要把A、B、C在数据访问层进行重新安排，抽象成D和E或是其它。最常见的应用，如“查询”，他即要满足分层、又可能要是“面向对象”、又要有效率，还要分页。如果没有申缩性，是不好处理的，就设计或架构来说，本来就是一种取舍。分层也一样。
UI就是UI,建议不要做任何业务罗辑的实现。只做简单的界面控制。
多次的数据库操作使用事务
DAL中声明一个属性来包装DbTransaction
业务层在取数据，分析数据，计算的时候，服务器就Time out了:(所以我最想知道的是怎么来应对这种存在双超时的强制性要求下的编码，谢谢。
NOTE： 数据库超时 30 seconds， 服务器超时 1 minutes.
UI上也不是凭空得到数据的呀，既然可以在UI层上去搞业务，为什么不动脑子在业务层上真正设计通信流程？其实这是“人祸”，不是“天灾”。是人根本不想去从UI层侧需求开始考虑业务层接口设计，而是从数据库表去考虑业务层接口设计，结果思路狭隘到极端的地步。能够在UI曾去搞业务，那么就可以分析出来业务层该如何设计出接口。设计软件不要从数据库表出发，应该从前端需求、用户操作行为出发。
恩，是的，由IIS托管，纳闷为什么不单独做个服务端，与客户端通信.@ki1381
有人专门搞这个的，不过不是很见效。@sp1234
谢谢，你的回答总能给我们提供很多信息
在这个设计模式下，一帮人已经搞了许久，介入的时候发现大家已经习以为常了.总的来说，如sp1234所说，这是个人祸。
所以我想我可以结贴了，对于人祸可能不是很好处理啦:)
谢谢各位。