110,525
社区成员
发帖
与我相关
我的任务
分享有关分层设计：业务逻辑的何去何从
手头有个项目，先说一下设计,是一个传统的形式：
------------
数据库
------------
数据访问
业务层
------------
服务代理
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上了:( 这个服务端变成了一个持久层。
大家说，这该怎么办好呢？
希望给点建议和意见，谢谢:)
...全文
请发表友善的回复…
发表回复
加油馒头 2011-01-11
- 打赏
- 举报
业务逻辑 是什么？
接受UI传来的数据，你进行验证，判断，逻辑操作等
接受UI传来的数据，你进行验证，判断，逻辑操作等
加油馒头 2011-01-11
- 打赏
- 举报
先要分清楚 什么是UI，什么是业务逻辑，什么是数据访问
UI至关 接受数据与显示数据，你做那么多业务操作 做什么？
UI至关 接受数据与显示数据，你做那么多业务操作 做什么？
thestarmm 2011-01-11
- 打赏
- 举报
@ShinNakoruru
恩，是的，由IIS托管，纳闷为什么不单独做个服务端，与客户端通信.
@ki1381
有人专门搞这个的，不过不是很见效。
@sp1234
谢谢，你的回答总能给我们提供很多信息
在这个设计模式下，一帮人已经搞了许久，介入的时候发现大家已经习以为常了.
总的来说，如sp1234所说，这是个人祸。
所以我想我可以结贴了，对于人祸可能不是很好处理啦:)
谢谢各位。
恩，是的，由IIS托管，纳闷为什么不单独做个服务端，与客户端通信.
@ki1381
有人专门搞这个的，不过不是很见效。
@sp1234
谢谢，你的回答总能给我们提供很多信息
在这个设计模式下，一帮人已经搞了许久，介入的时候发现大家已经习以为常了.
总的来说，如sp1234所说，这是个人祸。
所以我想我可以结贴了，对于人祸可能不是很好处理啦:)
谢谢各位。
以专业开发人员为伍 2011-01-11
- 打赏
- 举报
你说你的“服务器超时 1 minutes.”，其实哪有那么多实干的业务主管能等待1分钟而任凭电脑屏幕上一点东西都不出现？
假设一个报告需要1小时才出来，那么我打入报告的条件，然后就去干别的事情了。然后等报告出来了，自然有机制通知我去看报告。于是，业务逻辑层的设计就根据这个UI层用户行为来设计，有设置报告任务功能和报告生成完毕通知功能（可能首先提供轮询功能，然后才提供通知功能）。
这也是从应用软件的需求出发来考虑问题，很自然而然就想到的业务层接口功能。谁会去纠结数据库表问题呢？
设计一整套业务层接口功能，只要考虑到UI层与业务逻辑层，只是涉及中间的实体数据模型，而不需要考虑数据库。
假设一个报告需要1小时才出来，那么我打入报告的条件，然后就去干别的事情了。然后等报告出来了，自然有机制通知我去看报告。于是，业务逻辑层的设计就根据这个UI层用户行为来设计，有设置报告任务功能和报告生成完毕通知功能（可能首先提供轮询功能，然后才提供通知功能）。
这也是从应用软件的需求出发来考虑问题，很自然而然就想到的业务层接口功能。谁会去纠结数据库表问题呢？
设计一整套业务层接口功能，只要考虑到UI层与业务逻辑层，只是涉及中间的实体数据模型，而不需要考虑数据库。
以专业开发人员为伍 2011-01-11
- 打赏
- 举报
比如我是UI层设计工程师，我要求的用户用例之一就是：提交一个具体的订单数据（生成数据内容的程序已经写好，比如包括送货方式信息），服务就给我一个可用来打印的正规发票（包括服务器返回的发票流水号、附件信息等等），服务器甚至也同时给用户发送了一个电子邮件。我要求这个操作在3秒钟内完成（实际上通常要求1秒钟内完成，但是测试程序写下的上限是3秒钟）。
这就是业务逻辑层要提供的一个接口功能描述。至于业务逻辑内部是去查询用户信息，审核用户信誉，审核商品价格和库存，计算运费并且联系快递公司，记账，发送邮件，等等操作，我UI层没有这个能耐，也不关心这些操作。
业务逻辑层当然要从界面需求出发去设计接口啦。怎能动不动就只是从数据库表进行的什么“增删改查”，那种什么业务知识都不去另外学习和社会实践的在校学生的思路去进行“设计”呢？
这就是业务逻辑层要提供的一个接口功能描述。至于业务逻辑内部是去查询用户信息，审核用户信誉，审核商品价格和库存，计算运费并且联系快递公司，记账，发送邮件，等等操作，我UI层没有这个能耐，也不关心这些操作。
业务逻辑层当然要从界面需求出发去设计接口啦。怎能动不动就只是从数据库表进行的什么“增删改查”，那种什么业务知识都不去另外学习和社会实践的在校学生的思路去进行“设计”呢？
以专业开发人员为伍 2011-01-11
- 打赏
- 举报
呵呵，看书“太多”反而把脑筋弄得浑浑噩噩了。
Ki1381 2011-01-11
- 打赏
- 举报
要求是比较高。
架构方面我给不出更多建议，不熟悉这块。但是数据库方面可以尝试深入的优化一下，认真做的话多数情况下应该还能压榨出额外的提升。如果业务允许，也考虑下是否可以单独建立归档库，历史查询数据与生产数据分开，甚至建设OLAP系统。
架构方面我给不出更多建议，不熟悉这块。但是数据库方面可以尝试深入的优化一下，认真做的话多数情况下应该还能压榨出额外的提升。如果业务允许，也考虑下是否可以单独建立归档库，历史查询数据与生产数据分开，甚至建设OLAP系统。
以专业开发人员为伍 2011-01-11
- 打赏
- 举报
整个思路满拧，那么我们花费大量力气讨论设计、性能之类的，只是为了技术而技术，抄袭别人的理论炫耀，而越来越脱离实际。所以遇到脱离了实际应该有的设计思路，去从数据库表出发来讨论正规的（稍微有一点规模的）网络系统设计，也就没有什么必要去深入了。
ShinNakoruru 2011-01-11
- 打赏
- 举报
按说你这应该是C/S模式，也即是S端是你自己实现的，既然操作可能超过1分钟，你为什么不让服务器超时时间变长一些呢？亦或者采用异步操作，客户端发起请求后服务端立即返回OK，然后处理，客户端再去查询是或否处理完毕，或服务端主动通知。
还是你用IIS做服务端？
还是你用IIS做服务端？
以专业开发人员为伍 2011-01-11
- 打赏
- 举报
[Quote=引用楼主 thestarmm 的回复:]
这样子，业务逻辑处理就全部搁在UI上了:( 这个服务端变成了一个持久层。
[/Quote]
UI上也不是凭空得到数据的呀，既然可以在UI层上去搞业务，为什么不动脑子在业务层上真正设计通信流程？
其实这是“人祸”，不是“天灾”。是人根本不想去从UI层侧需求开始考虑业务层接口设计，而是从数据库表去考虑业务层接口设计，结果思路狭隘到极端的地步。
能够在UI曾去搞业务，那么就可以分析出来业务层该如何设计出接口。设计软件不要从数据库表出发，应该从前端需求、用户操作行为出发。
这样子，业务逻辑处理就全部搁在UI上了:( 这个服务端变成了一个持久层。
[/Quote]
UI上也不是凭空得到数据的呀，既然可以在UI层上去搞业务，为什么不动脑子在业务层上真正设计通信流程？
其实这是“人祸”，不是“天灾”。是人根本不想去从UI层侧需求开始考虑业务层接口设计，而是从数据库表去考虑业务层接口设计，结果思路狭隘到极端的地步。
能够在UI曾去搞业务，那么就可以分析出来业务层该如何设计出接口。设计软件不要从数据库表出发，应该从前端需求、用户操作行为出发。
thestarmm 2011-01-11
- 打赏
- 举报
[Quote=引用 3 楼 wuyq11 的回复:]
数据操作的超时，就要在业务逻辑层进行优化处理
多次的数据库操作使用事务
DAL中声明一个属性来包装DbTransaction
[/Quote]
呵呵，可惜还存在一个服务器超时:(
业务层在取数据，分析数据，计算的时候，服务器就Time out了:(
所以我最想知道的是怎么来应对这种存在双超时的强制性要求下的编码，谢谢。
NOTE： 数据库超时 30 seconds， 服务器超时 1 minutes.
数据操作的超时，就要在业务逻辑层进行优化处理
多次的数据库操作使用事务
DAL中声明一个属性来包装DbTransaction
[/Quote]
呵呵，可惜还存在一个服务器超时:(
业务层在取数据，分析数据，计算的时候，服务器就Time out了:(
所以我最想知道的是怎么来应对这种存在双超时的强制性要求下的编码，谢谢。
NOTE： 数据库超时 30 seconds， 服务器超时 1 minutes.
wuyq11 2011-01-10
- 打赏
- 举报
数据操作的超时，就要在业务逻辑层进行优化处理
多次的数据库操作使用事务
DAL中声明一个属性来包装DbTransaction
多次的数据库操作使用事务
DAL中声明一个属性来包装DbTransaction
showjancn 2011-01-10
- 打赏
- 举报
再说“业务逻辑处理就全部搁在UI上了:( ”
UI就是UI,建议不要做任何业务罗辑的实现。只做简单的界面控制。
UI就是UI,建议不要做任何业务罗辑的实现。只做简单的界面控制。
showjancn 2011-01-10
- 打赏
- 举报
其实，业务层和数据访问层，只是各自的目的不一样。
严格的来说，数据访问层也可以用来处理一些数据，最常见的应用就是“数据仓库”技术，宏观的来说都是数据访问层，但数据访问层中可能还会细分出一些对数据进行策略处理（是不是不业务处理有可能并不能一刀切）。
其实设计是为业务逻辑服务的，有时候为为了特定的需求，你可能要把A、B、C在数据访问层进行重新安排，抽象成D和E或是其它。
最常见的应用，如“查询”，他即要满足分层、又可能要是“面向对象”、又要有效率，还要分页。如果没有申缩性，是不好处理的，就设计或架构来说，本来就是一种取舍。分层也一样。
严格的来说，数据访问层也可以用来处理一些数据，最常见的应用就是“数据仓库”技术，宏观的来说都是数据访问层，但数据访问层中可能还会细分出一些对数据进行策略处理（是不是不业务处理有可能并不能一刀切）。
其实设计是为业务逻辑服务的，有时候为为了特定的需求，你可能要把A、B、C在数据访问层进行重新安排，抽象成D和E或是其它。
最常见的应用，如“查询”，他即要满足分层、又可能要是“面向对象”、又要有效率，还要分页。如果没有申缩性，是不好处理的，就设计或架构来说，本来就是一种取舍。分层也一样。
