@编写人生 期望大师能把每次的资料分享一点点，我的GMail：kingge168@gmail.com

感谢关注，我先在公司内部先开展，积累好经验后就会对外开放。 谢谢。

啥时候上线？

那我就来推荐一个小站，www.yiguanshou.com

你好，请问一下 我觉得他在规划段时，U9使用了十进制的概念，应该使用十六进制更好，有利于充分利用资源； 十进制的概念是什么意思

顶一下！

应该不简单测试list sort, sort和多线程，优化有关系 可以测试一下API调用，图形性能等

&符号在xml文件中需要解释的，而_则不需要

未来将包含更多的教程在哪？

好东西！！~~~

况且这么基本的功能，难道微软不会测试出来吗？？？ 如你标题所说，那是匿名函数，是一个函数！！！你要将改变后的p给匿名函数使用，那必须要将p作为匿名函数的参数，不然你没法传！！！ 函数参数是默认是按值传递的，例如上文的p，只是p指向的是一个对象，但是p所存储的是一个内存地址，是值类型，每次将p作为函数参数传递的时候，函数里面使用的p是p的内存地址的一个拷贝，不是引用，然后函数内的p可以使用这个拷贝过来的值找到内存中引用的对象。所以每次将p作为参数传给匿名函数就等于每次都保存下了当次改变的p的对象的内存地址。 而你原来认为有bug的写法，是直接将p内嵌到匿名函数里面了（说法可能有点不准确），所以这是匿名函数里面的p就相当于外面的p，只要外面的p的值（内存地址）改变了，里面的p也会改变，反过来同样适用，这是因为这是两个p其实同一个p。 你有兴趣的话，可以调试一下，看看 两种匿名函数的 p的内存地址。这样你就会明白了！！！！

我没说这不是闭包！！！！这是你自己对闭包的使用不正确 看我在2楼的回复！！！好好理解

加油

[quote]acolyte： 你必须要将p也当作参数传进去，才能每次都能获得你想要的p引用，否则只能获得最新的p引用。 这个改法就相当于你单独提取出来的函数GetFunc，而你的这个函数就是把p传进去了。[/quote] 在java和python开发中，这种功能叫 闭包，建议您参考一下，我案例中的写法是允许的。

你必须要将p也当作参数传进去，才能每次都能获得你想要的p引用，否则只能获得最新的p引用。 这个改法就相当于你单独提取出来的函数GetFunc，而你的这个函数就是把p传进去了。

这不是bug，你将func赋值那句改成下面这样： func = (v, prop) => prop.Converter.ConvertTo(v, typeof(Int64)); 看一下结果吧！！！

Kingdee

这博文发的........诶,小心被和谐,小心被盯上啊.这些内容还是不要发在博客园的好

虽然不懂技术，但是感觉说得很有道理。这种方法值得我们营销人员借鉴。谢谢楼主！ ---Sonne

@编写人生 呵呵，我是反编译的。说实话，最近一直在看，也学到了很多东西。如果有不懂的，还希望你多多指教啊。对了，祝你新的一年工作顺利~

@浅蓝铯dē爱 我想你可能看见了反编译的代码吧，反编译工具总是这样显示。当然自己人工当然不会

其实，我不是十分明白，如下的接口申明方式： public interface IValueConverterCollection : ICollection, IEnumerable{....} 难道ICollection不是继承自IEnumerable吗？既然是这样又何须再次显示申明其实现了IEnumerable接口？是为了程序的可读性还是有其他原因？ 据我理解，这里你只要让IValueConverterCollection实现ICollection接口就够了。

作为值类型的基类，这也是难免的。我想这也是CLR Via C#建议我们为自定义的值类型，重写Equals方法的原因吧。

其实，我认为两种分工法都有利弊。你说的是很有道理，但是在涉及到web开发的时候。各有所长就体现出来了，有些人真的就是服务端编码人员，他可能能应付代码编写和数据访问逻辑，但我想他在页面布局、js等客户端技术还是偏弱的。这个时候还是横向分割的比较好，界面层由前台程序员和美工搭配。 当然纵向切割也很有道理，感觉，纵向来有点像《大象》中讲的“用例驱动开发”，本人愚见，其实模块和用例是不能划等号的，关键就是，他很好地降低了耦合性。

我想，离开一个你一手架构出来的系统，还有自己开发的框架，一定会难以割舍。说实话，你对刚踏出校园，准备走开发这条路的我，有很深的影响，给了我很大的鼓舞。 祝你在新的公司，工作顺利，开心~

•获取某个TypeKey的特定接口的实现；——对这一项不是太了解，主要是对Factory.GetService<ISaveService>(“Employee”); 方法的内部实现不是太了解。一般，你取得一个服务，然后就可以通过这个服务接口的实例来使用服务接口提供的服务(也就是定义在服务接口里的方法)。而，我想这些服务方法一般是要提供实体的，这里我理解“方法+实体(在方法参数中提供)”为“操作+对象”，这样才会完整地表达一个业务逻辑，比如“修改员工信息”。我想“•获取指定接口的服务实现；”就是这种实现方式。但是获取某个TypeKey的特定接口应该如何实现？“一个实现可能实现多个TypeKey，一个实现也会支持这个TypeKey的多个接口的实现。”不太能想明白。通过“Employee”取得它特定实现的那个ISaveService接口吗？

[quote]brightheroes：楼主的意思好像是要证明“真正的领域模型是不能通过继承性描述的”的这个观点。但是接口的继承也是继承，楼主的这个例子恰恰的成了一个相反的论证。 <br>根据楼主这个例子，我们可以了解到，领域模型是可以通过继承性来描述的。 <br>[/quote] 你太死了，这确实是接口继承，从语法上来讲是这样。但很明显从语义上来讲，这是一种组合。其实，GOF是鼓励使用组合来代替继承的。你可以去了解一些设计模式。当业务逻辑相当复杂的时候，采用类的继承，会使类的数目呈现指数型增长。而采用类的组合很明显可以灵活地控制变化。而这边，你所认为的接口的“继承”，难道不是一种组合吗？

其实我不太明白你为什么没有想到使用“角色”这个概念，这样来表达岂不是更好吗。 以下两点不明之处：（1）俩种客户，在这里理解为俱乐部承认的俩种证书。 （2）客户购买VIP卡，是一个具体用户的证书颁发过程，他拥有了这个证书。 购买了VIP卡的难道不是VIP客户吗，我认为所有的系统使用者（包括总经理、客户等），都应该划归到“角色”来管理。将权限和角色捆绑，他们所处的角色不同，使得他们拥有不同的权限，而且他把用户和权限很好地分离开来，我认为这也是解耦的一个体现，而且具有一定的通用性。 您可以试着百度一下“RBAC”，本人不才，只是想法不同而已，不知道你怎么看呢

@编写人生 这是为什么？ 调试对此有这么大的影响？

TO 一叶浮萍: 执行测试程序时，首先选择Release，然后选择项目的属性=》Build(编译）=》高级=》调试信息 设置为none。 然后选择：调试=》不调试运行。或找到exe直接双击运行。

B 花费时间：607 A MarshalByRefObject 花费时间：678 A MarshalByRefObject 花费时间：712 B 花费时间：651 为什么我在vs2010 framwork3.5下测试是这样的结果？

http://files.cnblogs.com/tansm/wenjiabao.zip 大照片

我们应该在门槛上，等于没全在里面，也没全在外面。 总理这句话，是“下一盘很大的棋”，好深奥

b!=0 and a/b or 0 you can write like this 0 if b==0 else a/b

wow cool!

。。。这个是用VS 和sql 2005 以上的版本结合赵与做权限设计吗？

你的小儿子好可爱，呵呵！以后一定是一个小帅哥。偶还是比较低调的，所以照片里没我，哈哈！又到一年一度的春节了，今天已经有同事陆陆续续回家了……，不过还有我和另外几个同事坚守阵地。新年总有新希望，祝愿你事业进步，全家幸福哦！

在我的库中是通过对可能用到多语言部分表用lan字段做分类标识，在字典表中定义默认语言，不知道这样会有什么弊端

比较喜欢子表和xml字段的方式。

.net自带的国际化可以解决UI的问题，对于一些内容要多语言可以建立语言2

不错，学习

如果仅仅是界面显示信息,用UI的多语言技术 如果是用户输入并存储的数据,我觉得第一种最理想,无非是多了点join 用XML,查询似乎不麻烦,不过更新和删除就比较不自然,需要使用特殊的DML语句.并且等于在做dom操作了 觉得就是等于把资源文件存储到数据库中

志同道合者，加QQ 648537683

现在以压缩空气为动力的车子主要有两种方式产生动能。 第一种就是用空气吹转子。 第二种就是你想到的这种了，并且这种已经达到了实用化，可以看这里的链接，里面视频里的车子就是空气动力车：http://www.mdi.lu/fra/affiche_fra.php?page=accueil 下面有一些介绍： 全球各个大城市无不面对汽车污染问题，汽车废气对空气造成严重污染，行人长期吸入废气，也容易引起呼吸道疾病。读者有没有想像过，有朝一日汽车排出的不再是废气，而是比周围环境还要干净的清新空气？这并不是“空想”，由法国环保汽车公司MDI(Motor Development International)设计的“空气车”就具有以上优点。 　　顾名思义，空气车以空气推动，无需加油，每加一次空气可行驶10小时，适合城市的短途客运和货运，预定在今年底正式投入生产。MDI希望这款革命性空气车能让人们继续享受汽车带来的方便，却不用再担心污染环境。法国环保汽车公司MDI宣称，他们已找到环保人士和经济学家一直在寻找的理想汽车，一种在商业上可行、100%零污染的环保车。该公司创办人兼发明家内格里，以其设计飞机和一级方程式赛车发动机的经验，发明出完全以压缩空气发动机推动的空气车。 空气车最高时速达110公里，平均每加一次空气可行驶200公里或10小时。车上有4个总容量90升的压缩空气缸，可储90立方米的空气。由于空气车使用的是压缩空气，为避免损害发动机，所有空气都要先经过滤器过滤沙尘杂质，变做干净空气后才能注入发动机。所以驾驶人士在驾驶空气车的同时，还能帮助清新城市内的废气。 　　空气车加气过程非常简单，驾驶者可在家中自行加气，只需把空气车上的空气压缩机接到家中电源上，4小时后便能自动加满气。将来驾驶者也可以去指定的加气站快速加气，MDI已开发出一种快速充气技术，使气缸可在3分钟内完成充气，服务费约1.5欧元。 　　为减轻车身重量和使车辆速度更快，空气车的车身和车架分别以强化玻璃纤维和铝管制造。为减少汽车的电线重量，内格里特地为空气车设计了一套无线电控制的电力装置系统，只需一条电线便能供电给包括车灯在内的所有电力装置，使电线重量大大减少了22公斤，车身的总重量为700公斤，同时使电力装置的装嵌过程和修理变得更加简单。 　　空气车的压缩空气发动机在构造原理上类似传统的汽油发动机，最大的区别在于传统发动机是通过汽油和空气混合燃烧释放的能量提供动力，空气车则是通过气体的压缩和膨胀来驱动发动机。 　　传统的四冲程发动机把进气、压缩、爆炸和排气冲程集中在一个气缸完成，压缩空气发动机则把循环阶段分开在压缩缸、燃烧室和爆炸缸。具体工作原理是：压缩缸吸入外面空气，活塞上升，把空气加压至20帕(Bar)(地球表面的大气压力约1帕)，温度上升至400℃；空气喷射器将储存在压缩空气缸的压缩空气注入燃烧室，令气压急升；压缩空气膨胀推动爆炸缸活塞下口扑，使曲轴转动，驱动发动机。 　　压缩空气缸的气压很高，有人担心万一发生车祸，会否导致空气车的压缩空气缸发生爆炸。空气车工程师内格里表示，驾驶人士对此大可放心。空气车采用的是储存天然气体的玻璃纤维气缸，一旦发生意外气缸只会沿直纹裂开，里面的压缩空气会噗地一声排放掉，不会有爆炸的危险。 　　空气车的顾客对象包括出租车司机、小巴司机及轻型货车司机，以及平时用来接载孩子上学放学或到超市购物的短途家庭车用户，每辆售价约8000-10000美元。目前，南非、新西兰、澳大利亚、马来西亚、瑞士、西班牙和荷兰等多国均对空气车表示了兴趣。

B 花费时间：985 A MarshalByRefObject 花费时间：1095 A MarshalByRefObject 花费时间：1089 B 花费时间：956 这是我测的结果！

我们也遇到类似需求, 做到一半客户说要提供预览功能. 确认后才提交, 最后我们的做法与"辰"类似, 我们先写到Session,从session中读取并预览. 真正提交时才写数据库. 我觉得"用户想先去吃饭,回来再继续"这类需求完全没必要理会. 应该弹出对话框说:"对不起, 录不完就没饭吃!", 当然这是开玩笑, 该死的需求管理! 不论如何逻辑与数据最好分开, 我觉得错误信息,属于商业验证逻辑生成的临时数据, 包括一些逻辑状态信息, 凡是对于系统"规范流程"来说没有用处的, 应该止步于数据层之外. 所以我觉得打上"过账标志=true|false"的设计不太好. 举一个极端的例子, 我们有一种单据开始只有3种状态,1=没打印,2=已打印,3=已结算. 用户需求不断提出, 到后来搞出十几种状态了, 比如说,21=重新打印过, 31=结算时作废, 后来还碰到并发问题, 根本没法测试单据目前什么状态了, 还搞得其他数据跟着不准确, 简直要了命. 翻开marting先生的书,人家早就明明白白的写着: 要把一切都做成无状态的. 可我们已经不能回头了. 现在我觉得, 单据就是单据, 看得见摸得着的东西要存入数据库, 看不见的, 我指的是那些状态辅助的信息, 就最好不要存(这太完美), 至少应隔离, 比如, 一张表存单据, 另开一张表存状态信息, 用键关联起来.

致 辰: 感谢您的问答，我理解您的想法，事实上，按照您的想法可以将“错误的数据”放在另外一个服务端数据库，这样可以解决您后来提到的本地数据同步的问题。 从理论上来说，只有正确的数据放在“数据库”中，可以认为是正确的，但是，有两点因素决定我们还是这样做： 1、在统计报表时，单据必须是过账标志为ture的才统计，也就是说，我们已经存在“草稿”的概念，单据没过账的就是“草稿”，只不过这个东西我们之前没有做彻底，是个“半随意”的草稿； 2、草稿的数据和正式发布的数据都涉及到浏览和展现的界面，如果拆分开，势必影响代码的复杂度，首先底层要分支开读取不同的来源，其次在诸如浏览的程序里，要调整你的SQL做不同的关联也是很麻烦的，如果操作员希望看见最近几天处理的单据还要“合并”正式表和草稿表的数据，我觉得牺牲太大。 当然，你提到保存数据可以不使用ORM,而使用序列化和反序列化，这种思路我承认的确简化了保存和还原，但是复杂了其他，因为数据不再是存放在数据库中的字段，而是一个XML数据，那么浏览画面要关联其他表怎么办？订单没有客户的名称（假设没有冗余），怎么显示客户名称呢？即使您能够实现，仍然和正式的单据实现不同，造成程序写两套。 感谢您的留言。

没看评论就知道lz没经验 我不懂也知道 油燃烧产生的压力和空气压缩产生的压力 根本不是一回事。

就算。我的含有错误的信息保存在本地的时候。 数据库的数据变动了。 但是这个变动一定是正确的！ 在这个情况下，由于版本不同了（分布式的数据同步），我可以设置一些合并机制，比如状态比对之类的。让我的版本重新融合进去，成为一个新的版本。 或者最简单，干脆提示用户，数据已经变动，让用户先查看变动结果，然后判断是否修改自己的表单。

我有个小问题。就是为什么一定要保存在数据库。 首先我假设的前提是：数据库所有单据信息是正确的。 那么错误信息一定是发生在读取单据和保存单据之间。而且只要这个错误存在，这个单据是无法被其他流程更改的，否则就出现问题了。 既然这样，我何不把这个错误保存在本地，持久化，而不是数据库。 只要当管理员（系统）保证了单据是正确之后，才插入数据库，否则只要存在错误，就通过持久化保存在本地，可以是磁盘系统之类。 感觉这样的易用性设计更加合理。