忙着满足客户的需求...
2004-03-11 00:42
288 查看
这几天忙着满足客户对一个.Net WinForms(调用服务器上的WebService的)程序的需求,提高了WebService数据传输速度(数据传送前先压缩,传到后再解压),解决了WinForms程序占用内存过大的问题(好家伙,载入硬盘上的文件处理的时候,物理内存占用根据文件大小以线性增长,在我自己内存充足的电脑上根本感觉不出来,倒是把客户吓着了...途中还向JGTM2004发了封Email求助),解决了处理某些过程时界面停止响应的问题(多线程解决了)...以前一直在做WebForms相关的东西,对WinForms接触不多,这几天倒是熟悉不少。
On the road to Indigo是Indigo开发组的一个程序经理的Blog,内容不多但是很精彩。其中一篇讲SOA的文章很不错,列出了Service Orientation的几个核心原则:
1、Service Boundaries are Explicit and Costly to traverse
2、Services are Autonomous
3、Services expose Schema and Contract, not Class and Type
4、Services negotiate using Policy
说到第3点,他的观点是Service之间要传递架构和约定,而不要传递具体的类型。嗯,在我以前一篇讲SOA的文章里,说到在系统各个层间流动的是Entity对象,而Service对外公开的Facade接收和传递的也应该是Entity吗?嗯,值得考虑,考虑因素包括到承载各个Service的平台各异(.NET or Java),即使都是.NET也可能不能直接部署包含了Entity的Assembly...
还有一篇文章说明了现有的分布式架构技术中哪些能够在将来和Indigo直接配合通讯(talk Indigo on the wire ):
纯粹的.asmx的WebService是没点问题的;
将来的几乎随Indigo一起发布的WSE也没有问题(不是现在的WSE和WSE2哦);
Enterprise Services(ES/COM+)也是没有问题的;
MSMQ,嗯,没问题;
.Net Remoting,嘿嘿,是不行的...我真怀疑Microsoft发布.Net Remoting技术是不是有必要,刚推出时我曾乐观的觉得它将逐渐替代(至少是在某些场合部分替代)COM+,但...现在看来Microsoft将来会继续扩展ES/COM+使其能直接和Indigo交互,而.Net Remoting,虽然以后的.Net FX中不会将它踢出去,但是前景...
MSBuild Team发布了一个MSBuilde的预览QuickStart教程的下载,提供了示例代码和文档。
ShadowFax可能将成为微软最“有价值”的SOA架构参考示范,三月份ShadowFax开发组又发布了一个最新的版本,并表示四月份可能会发布其最终版本,并继续开发针对Whidbey的下一个版本。嗯,如果现在要下载ShadowFax,必须加入到ShadowFax WorkPlace中(只要你申请,一般都能通过)。
User Interface Process Application Block可能是微软发布的所有Application Block里面最复杂的一个,提供了一个比较完整的MVC框架,可以用于WinForms和WebForms,看了好久的文档才稍微理解了其架构和用意。UIP2也发布了一个测试版本,更加完善了。
因为前阵子接触了不少WebService + WinForms的东东,加上自己手头的项目中也是这样的应用,所以对WSE2也开始感兴趣起来,特别是在看了MVM的那个用WSE2实现CallBack以后。毕竟直接的.asmx WebService在安全性和扩展性上还是比较欠缺。对了,在这个接近400M的ASP.NET Starter Kit 入门指南资源包里面,就包含了一个WebService + WinForms的示范系统,银行助学贷款管理系统,哈哈,应该是蝈蝈写的吧。
On the road to Indigo是Indigo开发组的一个程序经理的Blog,内容不多但是很精彩。其中一篇讲SOA的文章很不错,列出了Service Orientation的几个核心原则:
1、Service Boundaries are Explicit and Costly to traverse
2、Services are Autonomous
3、Services expose Schema and Contract, not Class and Type
4、Services negotiate using Policy
说到第3点,他的观点是Service之间要传递架构和约定,而不要传递具体的类型。嗯,在我以前一篇讲SOA的文章里,说到在系统各个层间流动的是Entity对象,而Service对外公开的Facade接收和传递的也应该是Entity吗?嗯,值得考虑,考虑因素包括到承载各个Service的平台各异(.NET or Java),即使都是.NET也可能不能直接部署包含了Entity的Assembly...
还有一篇文章说明了现有的分布式架构技术中哪些能够在将来和Indigo直接配合通讯(talk Indigo on the wire ):
纯粹的.asmx的WebService是没点问题的;
将来的几乎随Indigo一起发布的WSE也没有问题(不是现在的WSE和WSE2哦);
Enterprise Services(ES/COM+)也是没有问题的;
MSMQ,嗯,没问题;
.Net Remoting,嘿嘿,是不行的...我真怀疑Microsoft发布.Net Remoting技术是不是有必要,刚推出时我曾乐观的觉得它将逐渐替代(至少是在某些场合部分替代)COM+,但...现在看来Microsoft将来会继续扩展ES/COM+使其能直接和Indigo交互,而.Net Remoting,虽然以后的.Net FX中不会将它踢出去,但是前景...
MSBuild Team发布了一个MSBuilde的预览QuickStart教程的下载,提供了示例代码和文档。
ShadowFax可能将成为微软最“有价值”的SOA架构参考示范,三月份ShadowFax开发组又发布了一个最新的版本,并表示四月份可能会发布其最终版本,并继续开发针对Whidbey的下一个版本。嗯,如果现在要下载ShadowFax,必须加入到ShadowFax WorkPlace中(只要你申请,一般都能通过)。
User Interface Process Application Block可能是微软发布的所有Application Block里面最复杂的一个,提供了一个比较完整的MVC框架,可以用于WinForms和WebForms,看了好久的文档才稍微理解了其架构和用意。UIP2也发布了一个测试版本,更加完善了。
因为前阵子接触了不少WebService + WinForms的东东,加上自己手头的项目中也是这样的应用,所以对WSE2也开始感兴趣起来,特别是在看了MVM的那个用WSE2实现CallBack以后。毕竟直接的.asmx WebService在安全性和扩展性上还是比较欠缺。对了,在这个接近400M的ASP.NET Starter Kit 入门指南资源包里面,就包含了一个WebService + WinForms的示范系统,银行助学贷款管理系统,哈哈,应该是蝈蝈写的吧。
相关文章推荐
- OA办公系统应以满足客户需求为目标
- 专访保旺达钟丹晔:满足客户需求 自主开发与系统集成两手一起抓
- 追求技术的完美还是满足客户需求即可
- CRM如何才能满足客户需求
- 惠普推新AMD芯片刀片PC 满足企业客户需求
- 工作就是满足客户需求
- 以过桥算法来谈如何满足客户的需求和程序设计步骤
- 满足客户的需求是要有前提的!
- 《人月神话》代序篇感想-客户需求满足
- 线上进行调整,不至于像以前一样经历退货和返工的麻烦。对于标准产品满足不同客户的多样需求,是营销理念上的进步
- 《人月神话》代序篇感想-客户需求满足
- 与快速满足用户要求相比,需求分析根本没有必要
- 团购创新,做满足人类基本需求的应用
- 电流检测放大器的发展满足多种应用需求
- 客户需求分析
- 微修改前端框架,以满足项目需求
- SEBank银行项目客户需求
- ★如何引导客户需求?几个经…