显然看得出LZ在这里无意谈论技术点，一些技术词汇，只是希望将自己对于程序人生的一些见解更贴近的表达。
技能技能，乃技与能的综合。
而技乃何物？如OO中的继承、多态等实用的形而下的知识。
能又为何物？本是自身对世事的理解、见解，回归至编程中的一种感悟，非实用主意的形而上学。
两学相辅相成，缺一不可，光有技者，乃工匠，乃专家；光有能者，乃幻想之人；两者皆有之人，方可为理想者，为大师者。
re: 印尼度假照片系列 坏人 2008-10-16 23:19
8错啊，呵呵
哦，HeyCacher2.0是另外个单独项目，我为了开发方便，就直接应用了，呵呵，不好意思，你可以在
http://heycacher2.googlecode.com/svn/trunk获取它的代码
哪个项目出错？分页功能？用的WEBDIYER的ASPNETPAGER哈
代码乱了，我不太清楚哦，上面写了，我也是从别人那移过来的，呵呵，感觉很实用，就介绍给大家用。
你是？没有中断，最近正在开发2.0版本，有兴趣可以去SVN上看看啊，呵呵
http://code.google.com/u/terry8750/
@NeverLand
因为走的是过期通知，而非远程存取，所以不存在把缓存数据整个进行序列化的问题。
IE的内核不是第三方的么？怎么会是MSHTML？
虽然我对MS很有好感，但是chrome的壳还是不错的，挺漂亮，值得IE学习。
re: F#版本更新说明 坏人 2008-09-07 19:07
函数编程的好处是什么呢？
re: 欢迎加入成都.NET俱乐部 坏人 2008-09-05 11:58
来了成都，申请加入:D
re: 验证能有多优雅 坏人 2008-09-02 17:23
难得发次疯:D多理解，恩，空了聊，都先忙吧，8.
re: 验证能有多优雅 坏人 2008-09-02 17:17
而如果使用自动化的事务，很多“已知错误”的时候屏蔽异常的话，会挺麻烦，我没有想到更好的解决办法，于是我妥协了
re: 验证能有多优雅 坏人 2008-09-02 17:16
数据连接则是另外个话题了，不讨论，那个话题已经是老生常谈的事了。
re: 验证能有多优雅 坏人 2008-09-02 17:14
更低的人力成本建造更大规模的代码，在这时候，适当的使用AOP等方法，自动化的事务，确实可以有效的降低人力提高代码规模
re: 验证能有多优雅 坏人 2008-09-02 17:14
@Activenetwork，这些是明白的，不过我觉得当下的观念应该有些改变，我现在比较注重代码的伸缩性以及
re: 验证能有多优雅 坏人 2008-09-02 17:12
其实之前我还倒腾了一个ExcuteState<T>，好象里面有Succeed，Message，ReturnValue，哈哈，现在也还在用
re: 验证能有多优雅 坏人 2008-09-02 17:11
Activenetwork，我说看你名字有点眼熟，没细看，不好意思，还在，公司网络限制，上不了，都晚上在，呵呵
re: 验证能有多优雅 坏人 2008-09-02 17:09
Activenetwork，有的时候异常也没那么臃肿，至少他可以让你自动的回滚事务，否则如何将事务之类的东西甩到AOP中去？
re: 验证能有多优雅 坏人 2008-09-02 17:08
通常的做法是JS先检查，提供良好体验以及节约POST动作，逻辑中再次检验，把好安全关。
re: 验证能有多优雅 坏人 2008-09-02 17:06
另外，关于WCF中的异常处理，网上好象文章很多，没有你想象中那么复杂。
re: 验证能有多优雅 坏人 2008-09-02 17:06
实在忍不住，你说的是UI是指的IE端？那样更加不可，WEB开发的基本原则，不可相信request过来的任何数据
re: 验证能有多优雅 坏人 2008-09-02 16:58
Gray Zhang，不要把参数校验放到UI去，很麻烦很头疼很不爽。。。我以前那样干，现在几乎不敢那样干了
re: 验证能有多优雅 坏人 2008-09-02 16:57
不能多说了，还有事，很期待LZ可以做一个能够集合JS的东西出来，VAB我先看看之后再来发言
re: 验证能有多优雅 坏人 2008-09-02 16:56
恩，不过你如果要说异构平台，我就不说什么了，以便内部的分布，我都是同构平台，呵呵
re: 验证能有多优雅 坏人 2008-09-02 16:55
不不不，远程场景下，使用异常并不复杂，而且将会保证你整个业务的连贯性
re: 验证能有多优雅 坏人 2008-09-02 16:54
PIAB看起来很熟，不记得是什么了，AOP的话，貌似现在的织入方式性能损失并不大，不用太计较，伸缩性以及规模才是考虑的重点
re: 验证能有多优雅 坏人 2008-09-02 16:53
下午有个会，现在思路不太灵活，回头空了聊下，只是如果用PROVIDER的哈，这个场景随便搞个容器恐怕更简单。
re: 验证能有多优雅 坏人 2008-09-02 16:51
否则的话，完全可以做个泛型类把返回参数和相关的确定性信息包装一下就O了的事。
re: 验证能有多优雅 坏人 2008-09-02 16:50
Gray Zhang，明确说明问题其实好解决，关键是异常无论在事务、远程等场景下简化编程模型的作用。
re: 验证能有多优雅 坏人 2008-09-02 16:49
LZ的方法还是不错，VAB还没看，既然你如此看好VAB，何必再做一个？仅仅不喜欢配置文件？
re: 验证能有多优雅 坏人 2008-09-02 16:47
谁的异常终结者的提法我很赞同，通过C#产生出JS校验框架是很棒的主意，我一直想这样做，只是一直没去实现
re: 验证能有多优雅 坏人 2008-09-02 16:46
引发异常有助于编程模型的统一，我也一直徘徊在异常使用的度上，但现在更倾向于不去关注异常的性能损失了。
不要继续抱怨了，就这样的心态，去了哪里都是一样，并且这样的代码生成，CS可以做得很好。
你可以认为拆开更优美，也可以认为继承更完整，各有好处，看实际情况发挥吧，或者自由发挥问题也不大，嘿嘿
所以，解决问题的方法总是很多，并不一定某种更好，或者最好：P
假如不用拆分的模式，那么建立一个DataProviderBase，就搞定了，我并不是排斥你的方法
解决问题的方法总不只有一种：D
将问题按逻辑拆分，很基本的一种思维方式，也很实用。
中间部分用虚方法，出现差异的时候进行重写，就可以解决所谓的不灵活问题
re: c#单一继承 坏人 2008-08-21 09:59
发提问区吧，是因为Contr也是从object继承过来的，你的Mamy自然就是object的孙孙了，明白否。
实际点的情况是，成都基本是北京工资水平的5-7折，看公司而定。
re: 小型分布式缓存方案探索（1） 坏人 2008-08-20 17:30
亚历山大，noti的灾难转移，是noti的事，但并不影响我们需要NOTI的初衷，对吧，至于灾难转移，有太多成熟方案，实现方式也简单，主要是会增加部署成本