- 博客(2)
- 资源 (7)
- 收藏
- 关注
RSS订阅原创 我开发的基本观点
1.作为架构,抽像是重要的,但是技术实现更重要,必竟有些性能问题不是光加机器可以解决的.比如松耦合,用队列最好,但队列需要数据库监听,分布式大量的数据传输,大量的序列化和反序列化都是性能瓶颈,异步需要大量的日志读写,多线程自身的损耗,负载匀衡自身的损耗,以消息机制还会导致数据库读写成倍的增长,而这以前很多数据可以存在页面上,或内存里.2.同样,必须考虑到程序员的感受,window服务肯定没有e
2011-11-01 23:50:37
456
原创 一种事件主导流程的设计模式的思考
三个角色一是事件触发者二是事件广播者三是事件处理者 事件触发者 触发事件 广播者接收事件 通知所有的事件处理者 事件处理者挑选自己需要处理的事件处理 这样做的好处是可以把相同的业物逻辑放在一起来处理 比如我们的业务逻辑需要一些相同的工作,比如发短信,减库存,支付扣款等 你看,我们新建一张订单 我们一般会写个生单接口,在这个方法里面,你要插入订单表,减库存
2011-11-01 21:07:21
760
1
AsyncTaskDispatcher - 简化多个异步操作之间的协作调用
Resource Page Description
在以前的文章中，我曾多次强调应用程序中异步化的重要性。尤其对于IO密集型操作，异步执行对于应用程序的响应能力和伸缩性有非常关键的影响。正确使用异步编程能够使用尽可能少的线程来执行大量的IO密集型操作。可惜的是，即时异步编程有避免线程阻塞等诸多好处，但是这种编程方式至今没有被大量采用。其原因有很多，其中最主要的一点可能就是异步模型在编程较为困难，导致许多开发人员不愿意去做。
异步，则意味着一个任务至少要被拆分为“二段式”的调用方式：一个方法用于发起异步请求，另一个方法用于异步任务完成后的回调。与传统方法调用方式相比，异步调用时的中间数据不能存放在线程栈上，方法之间的也不能简单地通过参数传递的方式来共享数据。此外，传统方法调用中的try…catch…finally，using等关键字都无法跨越方法边界，因此异步编程在处理异常，保护资源等方面也需要花更大的精力才行。如果一不小心，轻则造成资源泄露，重则使整个应用程序崩溃。
因此，无论是微软官方还是社区中都出现了一些简化异步编程方式的组件，例如微软并行与协调运行时和Wintellect's .NET Power Threading Library中的AsyncEnumerator。同时，我基于AsyncEnumerator构建了一个AsyncTaskDispatcher组件，使多个有依赖关系的异步操作之间的协作调用得以大大简化。
以上是引用,自己做了个更简单的demo
2012-02-05
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人