Kanas.Net Blog

这事儿放首页不合适。直接使用另外一个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和反射特征毫无关系。

这个问题也颇有意思，不过与Equals方法没有任何关系。
Lostinet说，Nullable<T>类型box成object的时候,就会变成null.
此话不严密，应该是：从未赋值的Nullable<T>类型box成object的时候,就会变成null。其实这个非常合理，不存在bug嫌疑。
int? x = new int?();
int? y = null;
int? z = new int?(1);
object o1 = x;
object o2 = y;
object o3 = z;
Assert.IsNull(o1);
Assert.IsNull(o2);
Assert.IsNotNull(o3);

Q.yuhen的结论完全是无厘头，怎么也不会压null到栈，除非你手工“优化”。

连链表都可以理直气壮地“还给老师”，真不知道还有什么东西没有还给老师？
为啥是理直气壮？这样让看的人都害羞的事情都敢于放到首页，还能说不是理直气壮？我比较佩服的是这位面试官。连链表都回答不出来的应聘者还有兴趣继续问下去。

@彭成刚
或许你又把OO赶到了“适用场景”的死胡同？
@双鱼座
多谢谬赞！

@怪怪
可能是我的表达不够准确。不过你所谓的“耐着性子钻研”是有歧义的，有一种“耐着性子钻研”其实只是表面上的，实质是动机不纯、出发点不对。OO与否并不是教条，但一定会经历一些教条的过程，然后才能抛开教条。所以，我极其赞赏你提出的两个问题，很多人都在自己不恰当的程序下参与一些不恰当的讨论。这只是我说的“浮燥”的表征之一。
我想提醒大家的是：够不够OO，用了什么设计模式并不重要。OO说到底仅仅只是一种境界，靠悟而不是靠钻研。既然是靠悟，偶尔有几个一辈子未能得悟也是正常啊。我MSN上的签名是“恰恰用心时，恰恰无心用，无心恰恰用，常用恰恰无”(引自唐代一位禅师的偈语)。其实那些一辈子潜心于修禅之人，目标决不是为了悟，悟只是副产品而已。为悟而悟，终无所悟。此为真耐心也。
OO的精髓是一种思想，然后在此基础上一代代大师在挖掘、传播的过程中建立了一套理论，一套原则。要驭之，必先知之，后悟之。任何原则必须先掌握，认同，然后才有可能发现这些原则的局限。但是很多人却不是这样。一种情况是有人总是在掌握这些理论之前就被这些理论所困住，以教条来约束自己，引导大众。另一种情况是有人总是高估自己对这些理论掌握的程度，摇摇晃晃，成效不彰，只能无端生出些许抱怨来。
其实什么人什么时候适合尝试OO并没有一个统一的标准。我是5岁学会游泳，14岁才学会骑单车，至今还不会驾车。OO和游泳、骑单车、驾车一样，其研修的过程并没有统一的准则。所不同的是：如果有一点传播作为基础，悟的过程会快许多；而游泳、骑单车和驾车则纯粹靠悟。
以上浅见，与君共讨。

@蛙蛙池塘
没有，其实MSDN就不错。
@辰
@小宇哥哥
很难苟同。个人觉得没有面向过程就面向对象或者面向对象就面向过程的说法。只有没有吃透面向对象的说法。面向对象不需要额外的成本。当然，学习的成本不能算。
@大傻
可能不是你想象的这样。“大程序”采用什么架构与“小程序”采用什么架构没有必须联系。如果你看了代码你可能会抱怨，为什么要引入那个名叫Global的贫血对象。其实这个对象仅仅只是一个参数传递器而已，用来适配不知道什么架构的“大程序”。
对于你来说一个Word文件也许一天时间足够，但对于我肯定不够(看出来了我要比你笨)，即便是完成了我也不能保证代码质量。我文章里讲了，我的方案的确可能比你花时间，但是我能保证代码质量，并且可以重用和扩展。这还不够本么？
@东风31
心急吃不得热豆腐，耐住性子比OO本身更重要。据我所知，抱怨OO的人绝大部分都有点心浮气燥。“抱怨”就是他们最典型的特征，所以别被他们的抱怨所影响。相信很快有一天你终会水到渠成、瓜熟蒂落，然后你再来评判我今天的结论，相信你会同意我。

@蛙蛙池塘
当然有，不过现在还不到正式发布的时候。如果你需要，请提供一个email地址，我把其中已完成部分的下载地址发给你。
Kanas.net Framework 2.0包含以下内容：
Kanas.net Data：持久层框架
Kanas.net Security：认证与授权框架
Kanas.net ObjectScape：数据集化框架
Kanas.net Web：Web支持框架
Kanas.net Addin：VS2005插件集合
目前还待开发：
VS2005 DSL支持
DLinq 提供器
待全部完成以后，我会专门写文章介绍，并提供源码下载。

@蛙蛙池塘
已修改，的确是路径有问题。我估计你修改的绝对路径可能不对，现在我采用相当路径了。
@henry
哈哈，一直瞎忙。
@阿多斯
谢谢关注。

@deerchao
@怪怪
一家之言而已，欢迎批评指正。
@蛙蛙池塘
感谢你的关注。非常抱歉你说的问题，回办公室立即查对。

@mydotnet1999
想必是你没有下载我的源码。在.net环境下。Mixin还是一个遥远的梦想，所以动态代理是非常困难的。
我的解决方案的前提是：所有的属性获取方法必须调用基类的方法，这样当然就简单了。

从本文可以看出楼主对线程有比较多的思考，不过错误太多。
1.面积是直径乘PI么？直径乘PI是周长，这是小学知识，楼主当然知道，只是不够认真而已。
2.例子没有经过检验。因为几个需要用ParameterizedThreadStart委托的地方却用ThreadStart来构造。
3.需要线程返回结果是标准的异步模式，楼主应该介绍标准方案。可以参考Stream的异步读写。除了回调外还有另外的两种方式。
4.所有基于窗口的多线程用法.Net也提供了标准方案，不仅仅针对WinForm。有Win32基础的人都很明白这一点。这个标准方案可以看net66的文章。另外一个方案就是直接以消息方式访问。

此文才是真正的空谈。

徐少侠是谁？好象需要复习一下耦合的概念？
Book.Save()
{
BookHelper bm=new BookHelper();
bh.Saev(this);
}
Book的Save方法已经依赖BookHelper了，难道还不叫耦合？在你可以new出来一个外部对象的时候，就已经耦合了。如果是一个接口或者一个抽象类或者任何你不可以new出来的对象就是解耦了。

楼主的文章很好，思想非常清晰。不过我需要说明的是：你所谓的两种方式其实都是极端。我采用二者的中和和平衡。不偏废数据库设计，但也不偏废业务设计。OO只是设计的手段之一，不是目的，更不是评判标准。解耦有时候是OO的目的，但相比于设计，仍然是手段。

@deerchao
没想到真有这么自以为是的人，这么多人帮助你，你还没有认识，还抛出一顶一顶的大帽子。这世界上只有你一个人懂得“软件是什么”？或者谁是否懂得“软件是什么”全凭你一句话？能不能在网上发布你的观点之前先明白你自己想表达什么，而不是一味指责别人没弄懂你的意思？你以为你拉大旗做虎皮“引经据典”就能让人赞同你的没有任何意义的观点么？
>>做软件设计时只要满足客户需求就可以了
什么叫“满足客户需求就够了”？谁难道说不应该满足客户需求么？你还不认为这是废话么？你自己都说了，同事也是客户、自己也是客户(尽管这里肯定弄混了“用户”与“客户”的区别，我这里暂时用你的错误概念)，在满足客户的需求到底是什么标准？为了满足客户需求(包括同事和自己)，在探求大量客户需求的规律之后，前辈们才提出的OO的一些原则，任何时候也没有说要背叛需求。这些已经被证实有效的理论是对软件技术的贡献。
我只想忠告你的是，通篇看下来，你的所谓的观点其实并没有什么吸引人之处。你自以为大彻大悟，其实什么也没有发生。

@deerchao
呵呵，忽然发现你斗嘴的功夫一流。我原话是有语病的，所以被你这样的高人一下抓住了，以后我一定注意。我更正一下：其中就包括OO的原则。既然是OO的原则，如果你不OO可以不用遵守。

db4o没有用过(我不看好这个东西，因为明显在干一些本不该由它干的一些事情)。不过我想Object.Set()与commit无异。与我们讨论的话题没什么关系。
你说的ORM中包括ActiveRecord里用Object.Save()在我看来当然存在问题，Context当然也是可以由Book获取的，这个前提我前面已经提到了(Book中已经隐含了上下文嘛)，但是这样会导致一些额外的依赖。你只能以两种方式来获取上下文：一种是公共的(例如单件模式导致的边界冲突)，一种是通过构造器或者其它方式来传入的(需要额外开销)。导致这个问题的实质是这种设计存在逻辑问题，无端排除了Object可以存在于多个上下文中或者在最后时刻才能获取上下文的可能性。很多人(当然包括我)是非常反感这种设计的。但是你就凭此来推断我不懂软件，逻辑上没有问题么？

@deerchao
惭愧啊。原来你的意思是初学者都能明白的，但是我居然没有明白。

那我就以初学者的态度来回答你。没有人说要离开需求讨论设计，也没有人说客户不重要，你何苦这么极端。不同的客户要采用不同的设计，这里没有任何象你所说的这么简单而没有任何实际意义的原则，而是一组复杂精妙而意义深远的原则。当然，其中就包括OO。

顺便说一下，无论你是什么需求，Book.Save()都可以被怀疑存在逻辑问题的。无非是你要告诉我，Book中已经隐含了上下文嘛。任何事情都有一定规律，所谓规律就是能应付不同的场景(正是你说的需求)。Book.Save(Context)其实是Context.Save(Book)的衍变。你能举出一种需求可以脱离这样的背景么？

1,没有银弹.
此乃软件工程述语。与软件设计何干？

2,客户需求是一切设计的根本.
也太泛客户化了，通常有人改善设计的目的只是把一些可积累的东西积累下来以供后续的项目和产品使用。

3,使用你的程序的人就是你的客户.别拿同事不当客户,也别拿自己不当客户.
同上。如果什么人都是客户，那分客户这个概念还有意义么？

4,判断设计优劣的唯一标准是客户用起来爽不爽.
可能界面上是这样。系统内部却不一定。

5,抽象得好与不好全看你的需求会怎么变化.
就这句话有点靠谱，不过还是有问题。可以写成：“是否需要进行抽象以及抽象到什么程度全看你的需求会怎么变化”。

6,看不惯Book.Save()只说明你没有理解软件是什么.
我也看不惯，但并不能证明我是否理解了“软件是什么”。如果写成Book.Save(Context)我就看得惯了。从逻辑上，Book.Save()似乎缺少某些条件，可能在Book这个对象中隐藏了某些公共的东西，所以有可能存在边界问题。

其实年轻人的偏激是可以理解的，真正的厉害家伙都存在某种偏执。所以我这里不是想纠正你，而是向你传达另外一种你没有关注的一种可能性。

@0337
对了，忘了说WF了。偶的确用WF做过一个方案，但是这个有额外的依赖。

不知所云。我好奇的是：你自己明白你文章写的什么东西吗？

N年前，我刚转.net的时候有一个Lostinet非常让人崇拜，虽然此Lostinet仍是彼Lostinet，但是我却认为决非为同一人，因为此Lostinet太令人失望了！
认真读完了本文，我确信，AbstractRecord是个逆潮流的东西。为什么这样说？
1.和SQL语句say goodbye是合理的，要不然大家为什么对dlinq趋之若鹜？所以，这不仅是软件的发展方向，同时也是程序员所期待的。总不见得在一些业务代码中夹插一些SQL语句更让人容易理解吧？
2.“可以断定的是,AbstractRecord比DataSet要快!”这句话没有根据。DataTable从托管堆中分配内存的次数仅仅与Columns.Count有关，而与Rows.Count无关。当然，我相信你在后台Emit那些abstract类的具体类的时候也可以如法炮制。但是即便如此，也不至于比DataSet更快吧？
3.一些查询条件已经是BusinessModel的一部分，有必要封装成一个可传递的对象，而不是一堆堆SQL语句。聪明的业务开发人员总是通过篡改这些业务对象来实现公共的控制，这一切通过篡改SQL语句是无法实现的。很高兴dlinq保持了这一点，让我们有机会通过AOP来实现权限控制、实现公共的筛选器以及可配置的查询器。
4.Lostinet在讨论这些POCO类实现的时候总是强调“透明”的好处；而转回头来在讨论访问数据库细节的时候总是强调“透明”的麻烦。“透明”在这里成了一片可以任意支使的招牌，让人莫衷一是啊。

有点搞笑:D下次我开发一个系统,名字就叫





























































Software!

的确是多此一举。Cookie就是Http提供的解决方案。

楼主没看过我的文章？http://www.cnblogs.com/Barton131420/archive/2005/11/09/272647.html
该文是针对Kanas.net 1.3.2的，适用于.Net Framework 1.1，所以采用的是Emit，而不是DynamicMethod。当然，我的框架的2.0的实现有所变化，性能有了更进一步的提高。不过我正在开发的是3.0，已经解决了我[http://www.cnblogs.com/Barton131420/archive/2007/01/07/613955.html]一文中提到的new业务对象时的性能问题，完全打乱了通常意义上的类的布局模式。Kanas.net从2.0开始，业务类的布局方式已经抽象为接口，可以采用各种灵活的方式来实现。