Kanas.Net Blog

http://www.microsoft.com/downloads/details.aspx?FamilyID=20686a1d-97a8-4f80-bc6a-ae010e085a6e&DisplayLang=en
这个地址可用

订阅你的文章，并期待你的书！

不错的说。挑点剌吧： 1.那个图不好，依赖关系并不是树型，有时候是网络型，交叉依赖的。 2.那个Operation的构造器不好，习惯上参数少的调用参数多的，您刚好相反，所以，当参数多的调用参数少的时候，冤枉多设置一次Dependencies属性。 3.如何防止循环依赖？ 4.强烈建议把operation._remainingDependencies--改掉： op.OperationCompleted += (sender, args) => { if ((System.Threading.Interlocked.Decrement(ref operation._remainingDependencies) == 0)) { operation.DoExecute(); } }; 线程情况比较复杂，虽然冲突的机会微乎其微，但毕竟是可以避免的。 5.依赖可以优化的。C依赖A、B，D依赖A、C，其实D只依赖C。

Automation的东东，太老套了。仅有DLL是不够的，肯定需要安装，或者至少需要Register一堆类库。不要在服务器上使用Automation。性能、可靠性、安全性都存在问题，即使是Word、Excel、PowerPoint也最好不要这样用，更别说visio了。对于文件格式转换这个话题，Visio要复杂一些，除了布局信息外，内部文件格式的解释是由插件完成的，所以很多结果是无法预料的。不过你可以用visio 2007 sdk试试。
顺便说一下：你的代码写得真是烂：
public static void Quit()
{
vso = GetInstance(); // 既然是退出，为什么还要创建一个？
if (vso != null) // 上面的方法已经确定不为空了，这个判断还有意义么？
{
vso.Quit(); // 仅仅退出，而不清空，下次GetInstance就会出现错误结果了
}
GC.Collect(); // 这什么这里不用lock了？
}

用ActiveX的方案确挺烂。除了ActiveX本身的问题外，主要是在控制环节为什么还要开一个浏览器？这样的控制系统，界面是界面、控制是控制，完全分开的。
不管以什么方式连接，如果把你的整个系统看成一个封闭的，那你的系统总有一个端点和LED相联吧？在相联的这台机器上开一个Windows服务，一方面调用服务器提供的Web服务，另一方面调用硬件开发接口驱动LED。哪有身份模拟问题啊，Windows服务的身份和IIS的身份是完全隔离的。
用ASP.NET是无可非议的，只要涉及到审核以及多人协作，ASP.NET就是一个可行的选择。

@书生多命贱
分页的问题我后面的文章会讲到，事实上这也是使用二次Model的一个原因之一。
SQL写代码的确不错。个人认为有两个问题无法回避，一个是重构，使用Linq可以在设计时发现所有的错误，而SQL不行。另一个是大量使用的聚合，ADO.NET EF一行代码几乎都帮你做好了，SQL你得写一堆。
@xiao_p(未登陆)
ADO.NET EF的问题我后面一篇就会讲到。其实EF的运行时是非常稳定可靠的，性能也非常好。虽然有些查询会返回“不支持”，相信后面的版本会有改进。问题是出在建模、映射等设计时。坦率讲，那个DSL相当的糟糕，我现在是凑合着使用而已，苦于没有时间，要不然我真的要自己写代码换掉它。
你在new一个EF上下文的时候的确不会建立数据库连接。但是你建立EF上下文的目的不正是使用数据库连接么。
ASP.NET MVC的View最好不要访问EF的上下文，这一点“书生多命贱”已经讲了，是出于解耦和单元测试的需要。尽量让View更单纯一些比较好。

@Q.Lee.lulu
维护这些对象是不可避免的。不过这些对象粒度非常小，维护起来非常简单，可以直接使用C#3.0的初始化构造器。请留意此文的后续文档，结合实例解释二次Model的意义和维护方法。
@书生多命贱
HttpContext 的Items 和 Cache有什么不同，请查阅MSDN相关文档：
System.Web.HttpContext.Items的定义：
(http://msdn.microsoft.com/en-us/library/system.web.httpcontext.items.aspx)
Gets a key/value collection that can be used to organize and share data between an IHttpModule interface and an IHttpHandler interface during an HTTP request.
System.Web.HttpContext.Cache的定义：
(http://msdn.microsoft.com/en-us/library/system.web.httpcontext.cache.aspx)
Gets the Cache object for the current application domain.
本文仅仅讨论ADO.NET EF，直接写SQL语句好在哪我不知道，不在本文讨论范围，那应该是另外一篇文章的事情。不过可以肯定的是：二次Model的功能不是一个平面式的DataTable可以替代的，除非你用一个带关系的DataSet。

没有上传文件？

明明M$的东西，非得从Java来。感觉你在打M$的脸啊！不过这脸打得好。
其实M$一开始就应该提供Inproc server而不是automation直接访问office文件。

http://cgbluesky.blog.163.com/blog/static/241235582008101793150537/
和上文是同一个人写的？
图5是错的，建议改一下，那条10应该是60比较合适。

呵呵，不必这么愤怒吧。怒气伤身啊！
同意你linq2sql没有死，也同意你linq更没有死。但是我也同意楼上关于肉球的形象说法，linq2sql/linq2ef都是缺乏支撑的东东，离实用还有相当的距离。
能够平淡地接受一些不同的说法，甚至能平淡地接受别人的错误，是楼主需要进一步修炼的。

@xiao_p
多谢褒奖，牛人实在是不敢当，汗...
@巫云
我也曾尝试过把数据库和业务层分开，但是没有成功。有什么经验可以分享？
@Anytao
俺一直在啊，只是平时瞎忙，显得有些手懒，惭愧...
@包建强
深感荣幸！

@碧落
ADOEF为什么不从模型开始，说实话我和你一样困惑。
@Dreaming
我不知道你认为最好的方式是按什么标准的，如果说最成熟稳定、最敏捷的方案我已经给你了，那就是ECO。但是事实上我自己都不用的。还有很多商业的方案也不错。我自己用的是拼凑的方案，内核是我自己写的。事实上我一直希望组建一个小组，完成这样一个既敏捷又完整的解决方案，提供给大家来使用。
@kiler
Hibernate的确不建议从database开始，事实上让用户写配置文件而又不提供相应的工具在我看来是一种很不负责任的态度。当然，java里充满了这样一些不负责任的态度，一点不奇怪。

@碧落
关于建模工具，我没有很好的方案给你。
1.如果采用Visio，我可以处理ER图，将Visio保存为ERX文件(一个文本文件)，然后解析。在我的kanas.net 1.3~2.1中都已经得到处理，你可以复制其中的200-300行代码拿过去用。你知道的，ER图没有继承，我只能按一个条件进行判断：如果一个属性既是主键又是外键，那就是一个继承。但有时候事实并不是这样的。所以你可以再改回去。
2.当然，PD就更简单了。不过我中意PD却不是因为能生成数据库脚本。事实上我的数据库脚本都是我用自己的代码来生成的。Visio其实非常难用，不稳定。你不知道哪一天你的vsd文件忽然打不开了，或者其中的某个元素无法进行编辑了。而这方面PD表现得非常稳定。千万别指望Visio所谓的XML文件结构(你甚至可以延展到所有office的xml文件格式)，这些格式其实与BIN没有什么区别，根本就不是什么标准的、可以信赖的东西，太多太多base64的段落你是无法解析的。
3.我觉得建模最方便的方式其实还是M$所推荐的DSL。我一直想做一个，只是苦于没有专门的时间。目前我还停留在手工编写xml的方式。当然，用vs2005/2008手工写xml也非常快，主要是维护方便。

@田景
没有人说ORM是万能的，也没有人说什么都使用ORM。
我看了你的“简单的ORM”，不过真的很像个玩具，难怪你欢迎我下载玩玩了。

什么时候.net支持“参数编组的泛型”？
一个典型的应用是二分法。
delegate int ParamsCompare<T, P>(T item, params P arg);
static bool Find<T, P>(ParamsCompare<T, P> comparer, IList<T> list, params P target, out int index)
{
......
}

这样使用：
Find<MyObject, Interface1, Interface2, Interface3>(new delegate(MyObject obj, Interface1 i1, Interface2 i2, Interface3 i3){....}), myObjList, x1, x2, x3, out index);

帮你把以上的意见归纳一下：
一、坚持，坚持就是胜利。
二、多从自己身上找问题。
作为一名合格的软件开发项目经理，以上是必不可少的。我补充几点：
三、养成一种习惯，经常性地抽身出来，归纳一下前一个时间段项目中出现的问题，这是让你和你和团队有机会学习。专业术语叫做“站高一线[罗纳德海菲兹语]”。只有抽身出来才能保证你的总结是中立的。
四、你自己必须明确你的目标和方向，例如代码质量，什么样的代码质量才是你想要的，然后让你的目标和方向成为团队的共识。如果只是你想要的而不是大家想要的，通常是不可能实现的。
五、欣赏和接纳你的团队成员。他们是你的伙伴，你们一荣俱荣一损俱损。在你在团队中发泄你的不满的时候，团队会和你保持距离，你将会很难和他们合作和沟通。
六、持续地提升你的EQ。工作中出现不顺，这是件很平常的事情，没什么大不了的。项目出现一些问题，唯一能做的就是立即解决它，而不是不加控制地激发你的情绪。有些时候还要学会适当让步，因有这个时候通常只有让步才能让你管理好你自己的情绪。专业术语叫做“自我降服”。
七、我相信你一定能成为一个专业的项目经理。当然，“我相信”没有“你相信”管用。相信自己能带给你力量，让你和你的团队立即行动。

此文有深度，有高度。这个世界上任何一种可能都存在，任何刻意破坏某种生态平衡的作法，也许眼前会有直接的回报，但是受到更严厉的惩罚只是时间问题。我经常看到楼下马路上有警察在抄牌，但他一定不是天天来，通常是一周一次。这不是因为这个警察平时没有时间，而是如果他真的天天来，就不会有人在这个路段泊车了。

哈哈，这帖火啊！
俺也说两句：
一、嘉许楼主和几位坦率的同学，你们的愿望是非常好的，但是却忘了一件事情：使用盗版是件丢脸的事情，如果你一定要用你就悄悄地用，别声张，哪有做小偷还给自己找理由的。如果软件从业人员都象你们这样容忍盗版的态度，中国的软件业哪有什么希望。不要等到盗的是你的公司开发的产品的时候你才觉得盗版是有罪的。当然我不是说我自己用的全是正版，但是我一定会要么什么也不宣扬(潜水无罪啊！)，要么就宣扬“盗版是件可耻的事情”这样的观念。
二、Microsoft的做法是无可非议的，甚至是应该受欢迎的。如果有人觉得买不起Windows，很简单啊，每个月多赚一点就可以买得起了，这不正是你赚钱的动力吗？有人给你动力，你还不欢迎，那你欢迎什么啊？别抱怨人家贵，Windows这种东西又不是缺了你就活不了，嫌贵那就别买好了。人家ocean说得对啊，电脑买得起是因为没得盗；Windows买得起是因为有得盗。决定“贵”还是“贱”的并不是价钱，而是有不有得盗。
三、ocean同学也不用以为Microsoft是小媳妇，一脸受害者的样子。在某种意义上讲，Microsoft也是“罪恶累累”啊，Windows盗版横行Microsoft自己也是有责任的。公平公正的市场环境每个机构都有责任，不关是政府一家的责任。最起码，我所接触到的政府用的软件绝大部分都是正版，政府已经做了一个好的表率。不能因为香港打击盗版力度大就说香港政府负责任。打击盗版更多的是靠社会而不是靠政府，是靠我们每一个人。

呵呵，动态也可以做到不落地的。落地会引起很多方面的麻烦，性能啊，安全性啊，等等。
为什么不把源码传给临时的AppDomain，由这个临时的AppDomain去编译并向主AppDomain输出接口包装？

虽然此文放在首页也许违反规则，也许很多人会反感，我倒觉得这篇文章有点意思，完全符合放到首页的标准。楼主的这种心态在程序员中我相信带有某种普遍性，包括我周围个别同事就存在类似的问题。
“可爱的书记”提到的“换位思考”和“尊重自己”这两点非常有意义。楼主的烦恼是楼主人际关系的一个投影，其实问题已经比较严重了，只是楼主还没有觉察到。
许宜铭先生说“我是一切的源头”，意思是“果”由“因”起，而不是“缘”起，“因”就是自己，“缘”就是外部环境。换句话说，你所遭遇的一切皆是咎由自取。你周围的人如何对待你、如何评价你，不是取决于他们，而是取决于你自己，所以说，你的人际环境都是你自己造成的，这一切都应该由你来埋单，这才是真正对自己负责任。
我有四点忠告，或者说给你揭示四个真相，是对“可爱的书记”的一个补充。第一，既然你那么讨厌老板，留意一下，为什么没有在当初第一次觉得老板讨厌的时候就离开这间公司？如果你真的认真想一下，也许会觉得老板其实也很可爱。第二，也许你的同事真的没有你优秀，但是，你能担保如果你周围有一群都比你优秀的人，你就一定没有烦恼吗？何况，尺有所短，寸有所长，你不会去欣赏他、接纳他，你怎么可能看到他的优点？还是借助许宜铭先生的话：同一个人，100个人看就有100个结论，你的结论只是其中一个而已，并不一定就是真相。第三，你的同学，给你的评价是：你这个人有野心，但太看的起自己了。第一句是在夸奖你，有野心表示你是一个有目标、有标准、有方向的人。后一句是给你的忠告，说你应该摆正你自己在你环境中的位置。两句加起来构成一个无私的“回应”，这是一份非常珍贵的礼物，值得你一辈子珍惜。你却在猜测“她为什么会这么讲？”我想告诉你的是，其实有100个人都这么想，只是她愿意告诉你而已。有没有想过，为什么其他人不愿意告诉你？第四，任何人对你的欣赏都可能来自你对他的欣赏，从你开始去欣赏和接纳你周围的每一个人，一定可以换来你周围的人对你的欣赏。人的生命只有一次，没有机会重新活一次。你的任何机会都是你自己创造的，而不是别人施舍的。
我相信你的文章是用心写的，所以你也要相信我的回复也是用心写的。我们同在一个城市工作和生活，又能同在一个论坛里相遇，这样的缘分是我愿意用心写这个回复的理由。至于你是否应该离职，我不能给你建议，我只能建议你先换一下心情，然后再给自己作一个重要的决断。

对于企业级开发，标准和规范的确非常重要，所以在很多时候，中间件(Midware)的概念、应用服务器(Application Server)的概念和三层架构(3-Tier)的概念这三者是不可分割的。可是，Microsoft技术中没有3-Tier的概念，尽管Microsoft技术包含了大部分3-Tier的功能，这些功能就包含在Windows Server(MTS/IIS/MSMQ)/SQL Server/BizTalk Server等产品中。既然是产品就不要奢望规范了，规范是个开放的东西，这和Microsoft一贯的作风是不符的。
但是，这不等于说在Microsoft技术架构下不能做企业级开发。你得知道，微软的MTS可是第一个分布式事务管理器，比任何一个应用服务器都老牌哩。至于可伸缩性、热部署、消息中间件，.net第一个版本都已经包含了。当然，这个.net还是Microsoft的.net，并不是工业标准的.net(尽管有一小部分技术已经成为工业标准，那只是更基础的东西，并不包括企业级的开发与运营)。连工业标准的.net都没有，奢谈什么规范呢？

这事儿放首页不合适。直接使用另外一个Assembly中的方法签名来调用，在被调用的Assembly被重新编译过后，调用程序一定要重新编译，这是常识。 如果被调用的Assembly加了强命名，可能调用者程序连启动都困难。
有一种情况可以不用重新编译，那就是动态调用。动态调用通常在调用者和被调用者间有一个“桥梁”，在“桥梁”Assembly中定义接口、基类或者其他协议；调用者按这些协议调用动态实现者，而被调用者只需要实现这些协议即可。

呵呵，或许是firefox对资源名称大小写敏感吧。

如果是这样：
static void Main(string[] args)
{
ITest it = new ITestImpl();
it.AddUser("henry","123");
}
而结果和你现在显示的结果一样的话，那才叫AOP。你这里没有Cross Cut Point。

@碧落
如果你需要包括VsExtension的话，你需要安装一下vs2005 sdk，否则会报告你说的这个错误。
另外，可能也缺_zxh.snk这个文件，你可以修改assembly properties，不要强名称或者换成你自己的强名称。

@搜索人生
数据是老了一点，我从收藏夹取出来的。这个是最新版：http://www.stats.gov.cn/tjbz/xzqhdm/t20080215_402462675.htm
不过也没有你说的苏州市高新区和工业园区，这两个应该不是行政区域。

@随风流月
你的方案当然可行。不过用HtmlReader会更爽。:D我所需要的数据远比你多，除了行政区域还包括行业、流域等标准数据......

@WilsonWu
我向你分享了我的方法，你不愿意收是你的事情，不必向我解释。其实你应该知道，邮编与行政区划是没有关系的。广州市天河区的区号是510600。如果你在用这个邮编的时候，仅仅详实到县一级是没有意义的。即使你想加上邮编，用我的方法也是很有效的，你可以写另外一个HtmlReader，解析一下这个网址，肯定比你的方法准确并高效：
http://www.183.com.cn/epost/yzfu/code/postcode.jsp

需要两晚上？夸张了一点。
1.写一个html解析器(aspunit中有现成的模块可以Copy);
2.用这个解析器打开这个网页：http://www.stats.gov.cn/tjbz/xzqhdm/t20070411_402397928.htm
3.剩下的就承受你怎么弄了，SQL也罢，XML也罢。

好处：标准数据，可靠来源，数据变化时跟随变化。

哈哈，虽然实用价值并不是很大，仍然是不错的想法。

@floodpeak
我看你连个学生也不如。你做事完全只是为了让别人知情么？
象你这样的态度，进度也高不到哪里去。虽然快快交差了，但是毛病一堆。算上你调试、优化的时间，比人家还多出一截来。
讲究细节的目的不仅仅是为了手头的某个程序，而是为了养成一些良好的习惯，有了这些习惯，提升系统质量无需任何成本。

这位还这么自信。本来就是XPath没写对。回去好好复习一下，别动不动上首页。

呵呵，又见动态Web Service客户端。
你的方案是仿照手工过程，用类似WSDL.EXE工具的方式，并通过CodeDom动态编译。这种方式最简单(System.Web.Service只提供了CodeDom方式)，但也最让人不爽。
前段时间我写过一个改良的版本，只用System.Web.Service的WSDL解析部分，然后用Emit生成代码。这样有一个好处，在获得WSDL的URL后，在调用前(生成动态代码前)可以列出所有的方法，并自动显示这些方法的参数类型。
其实，最简单的方法还是用MSOSOAP30.DLL。.net clr很好地解决了IDispatch接口及晚绑定的问题，所以用这个进程内服务器效果非常好。只需要四行代码：
Type objType = Type.GetTypeFromProgID("MSOSOAP.SoapClient30");
object obj = Activator.CreateInstance(objType);
obj.InvokeMember("MSSoapInit", 0, nil, new object[] { WsdlUrl });
return obj.InvokeMember("方法名", 0, nil, new object[] { "参数" });

这代码质量真不敢恭维啊!
// if (desCode.Length != 11 || orgin < 0)
ulong orgin永远都不会 < 0。

既然确定是进制转换，当然是用取余了：

private static string ToString(ulong arg)
{
ulong mod = 62L;
StringBuilder line = new StringBuilder();
while (arg > 0)
{
line.Insert(0, charactor[arg % mod]);
arg /= mod;
}
return line.ToString();
}

@Teddy's Knowledge Base
看来说服你放弃你的方案有点困难。加一张表来记录所有的祖先节点ID肯定是冗余，但是你加两个字段也是冗余。我们可以假定所有可以推导出来的数据都是冗余的，你所加的字段都是可以推导出来的，所以仍然是冗余。
其实设计数据库表或者字段是否“要难受一些”，不是靠感官，而是逻辑。通常基数不等的元素应该设计成分开的实体，也就是多表，节点和它的祖先集合、子孙集合显然基数是不同，幻想在一张表里解决一对多一定会带来某种不便，我说的添加、移动、删除对你的方案就已经出现了不便。如果有100个角色节点，刚好我动了根节点的第一个子节点，我要锁定其余的99行记录。虽然动的可能性很小，但不是没有。同时锁定这么多记录的后果就不用我说了。
也许你还有其他的用途，虽然我不知道你的用途是什么，但我可以确定的是：要实现你的这些用途，加表的方案一定比加字段的方案更灵活，副作用更小。

@Teddy's Knowledge Base
你可能误解我的意思了，其实性能问题无非是是否需要递归。同样不需要递归，对于查询的性能来说，加两个字段与加一张表没有什么差别。但是对于添加、移动和删除的性能来说，差别可就大了去了。
“你的思路是尽可能使用update更新数据库，我的思路是尽可能使用insert/delete以避免伤及无辜的记录。 ”

如果真的有100000个用户，添加、移动或者删除一个role(特别是level高的role)那可麻烦大了。
其实你讲的这个主题与rbac没有关系，其实只是个hierarchical的问题。既然要加两个字段还不如另加一张表，这张表仅仅记录所有的祖先类。
你的思路是尽可能使用update更新数据库，我的思路是尽可能使用insert/delete以避免伤及无辜的记录。
关于hierarchical我有篇文章写了五年，还没有脱稿。

System.Threading.Timer是Windows系统对象WaitableTimer的托管包装；
System.Timers.Timer是对System.Threading.Timer的进一步包装；
System.Windows.Forms.Timer是Windows窗口对象的托管包装，该窗口仅处理一个消息，就是WM_Timer。

N年前用过，没有你描述的这么好，用用你就知道了，很多的Win32函数或者其结构没有提供，不到一星期我就卸了。

包装一下接口方法也叫AOP?

汗...这是最简单的包装类(Wrapper)，与帮助类(Helper)并行，与聚合无干，更谈不上另类。

万能的主啊!怎么打着MVC的旗号又回到了ASP的时代?

/*
下面的代码,
Product p1=Product.LoadRow(1);
Product p2=Product.LoadRow(1);
p1.ProductName="NewName";
p1.Save();
在执行p1.Save()之后, p2.ProductName也会跟着变成"NewName".

很神奇吧! 目前其他的ORM并无法做到这一点!
*/
呵呵，一点儿都不神奇。如果能称之为ORM，必须能够做到这一点。
在我的Kanas.net Framework中，应该比你的更先进、更灵活。如果你不需要隔离，可以立即同步；如果需要隔离，也可以选择不同步。和你的同步不同的是：虽然是保持同一份引用，但是如果有一个线程准备修改，则立即生成一个新的“影子对象”，另外建一份实例是很浪费的，我的原则是需要时才重建实例。

哈哈，个人同意Kurax Kuang，不同意Cat Chen，依赖编译器从而放弃良好的编码习惯,这是现代程序员的通病。N年前的笑话：
http://www.delphibbs.com/keylife/iblog_show.asp?xid=387

@水如烟(LzmTW)
没明白“代码集”是什么概念?是“程序集(Assembly)”么？
你说的案例和.net有关么？安全性是一个相对的话题。只要有机会接触到你的程序实例，一定有机会修改的，特别是现如今的调试技术越来越先进。这个与.net没有关系。

文章非常好！
对了，N年前炒过的G#呢？那个不是用来对抗AspectJ的么？

1.楼主所谓的有意义和无意义，是存在的，只不过楼主没有说完整，完整的说法是“领域意义”(Martin fowler语)。
2.主键的设计和使用没有统一的模式。对于无领域意义的主键通常采用自增字段、GUID，但无法防止领域冲突；对于有领域意义的主键通常定义方便、访问不方便。
3.复合键一样可以做外键，所有主流的关系数据库都支持，只不过通常不推荐罢了。当然不推荐的原因并不是为了扩展，而是会给访问数据添加了一些麻烦(比方你不得不写一堆join)，这些麻烦有时候超过复合外键带来的好处(比方说确保数据库的完整性)。
4.大家讨论的都是关系模式问题，一切关系数据库设计都是基于关系模式。这方面的理论历史比较长(大约有40年)，非常成熟。

@Zealic
不是口误，根本是概念错误。
你的问题说到底是给了空值来反射调用的缘故，与Nullable的反射特征毫无关系。

@Zealic
“Nullable 无法反射调用实例成员”，有这个说法么？赋值的Nullable可以反射调用任何成员啊！
System.Reflection.PropertyInfo info = typeof(int?).GetProperty"HasValue");
int? x = new int?(1);
Assert.IsTrue((bool)info.GetValue(x, null));

你的问题说到底是给了空值来反射调用的缘故，与Nullable和反射特征毫无关系。