Teddy's Knowledge Base

"使用反射修改ScirptManager控件中的私有变量_isInAsyncPostBack"--这个会提升整个网站的Trust Level等级，不是很爽。

还没细看，不过，在异步提交时将file post到iframe是不是意味着其实点一下按钮做了两个提交，是否要自己考虑事务同步的问题，比如我的一次提交既有控件传递的参数又有上传的二进制文件？现有的方案有考虑吗？

asp.net ajax有没有办法让异步提交本身就用iframe暂时代替xmlhttprequest来处理这次提交呢，如果可行，就不需要在两个request中分别处理提交的数据和binary文件了？以前的页面callback支持中，如果浏览器不支持xmlhttprequest，会用iframe处理异步提交，没有仔细研究过asp.net ajax这部分的代码，只是一个设想。

我遇到过，并且维修过。这是主板的电池接口坏了，如果在保修期内，尽快修吧，维修很简单，换主板。拖久了的话会越来越难开机，直到。。。完全开不了。

@Wendy Yu
的确应该是12，谢谢发现这个问题，已经改正了。

@双鱼座
同意你的思路确实尽可能“避免伤及无辜的记录”。对于权限管理中的Role或Resource，他们的Hierarchy不会有特别多记录，修改的性能差别我觉得不是太大的问题。从数据库维护的角度，个人觉得多一张表的味道还是比多两个字段似乎要难受一些。而且你的表里包含了很多的冗余信息，味道也不是特别好，我虽然多了两个字段，但是，从数据的概念上说，并不冗余，而且，根据我的这个思路，除了能实现方便的取得所有父节点或所有子节点外，还能有一些额外的作用，因为我是一棵有特殊规则权值树，使用较灵活，利用这些权值进行取父子节点的查询只是它的用途之一。

@ravezhang
当然不是，第一张图就说明了User和Role是多对多的。

@双鱼座
有多少个用户和添加、移动或者删除Role没有任何关系，权限是基于Role的。添加、移动或者删除Role只会导致更新所有Role的LeftIndex和RightIndex，除非你有几万个Role。使用我这个方案，基本不需要你说的“另加一张表，这张表仅仅记录所有的祖先类”。对性能不会造成太大的影响。

@cozo
实际的系统中当然会做缓存，不可能每次直接用这样的语句来查询。我这里给出语句的目的是为了和递归的情况比较。

实际上，本方案中特色的部分在于使用LeftIndex和RightIndex字段避免层级递归，给出一种性能较高的思路，并不是要提出一种万能的RBAC方案，实际的系统中肯定要根据实际情况进行扩展或简化的。这样的思路对任何包含多层级的数据的父子查询都是类似的，也不仅仅局限于权限控制中。

@Klesh Wong
图没错，新增，移动，删除任意节点后都需要重设所有节点的LeftIndex和RightIndex的。

@saucer
考虑有100000个用户，其中100个管理员可以修改节点。每个用户登录时至少都要读取计算一次他的权限，所以读取的频率是比较大的，而修改节点的比例很小，该方案对性能的好处才会有体现，对小项目和节点关系简单的项目来说，用什么方案都无所谓的。

@kiler
你说的方案一定程度上也可以，但如果权限很多很复杂，web服务器或app服务器有没必要的额外开销，Select in DataSet的开销挺大的。

@Hightree
基于该方案是很容易进行扩展支持你说的复杂情况的，我实现的是相对比较标准的Hierarchical RBAC标准。

@叶子绿了
遇到这样的情况请删掉website的所有reference，再手动重新添加一下，再重新编译。

@？？？
NBearLite是NBearV4构架的组成部分，单独使用的话就是一个轻量级的透明支持多数据库的数据访问和映射组件。NBearV3是一个以OO为中心的，包括ORM，IOC，WEB的开发框架。NBearV4是下一代的NBear开发框架解决方案。它还会包含如IOC、代码生成、Web等其他组件。

@Leeky
不好意思，漏了打包MySql.Data.dll进去了。现在加上了。请重新下载一下。

@Leeky
编译通不过的话可能需要你自己检查一下所有工程引用的dll的路径。请引用NBearLite_lib目录中的dll后再试试编译。

我们基本上弃用ControlToolkit，bug多，兼容性差，性能差，不弃用不行。只能用丑陋的js来缝缝补补。

思路很好，不过，你这个post中的示例代码中行号和具体的代码现在没在一个水平线上。能否看看如何修正？我是IE7浏览器。

@idior
本文的目的不是设计一种新的Assert构架，而是对引文的DbC实现进行扩展，从而可以无缝升级原来使用它的代码，从而减少今后使用和维护的工作量。

另一方面，对于unittest，使用基类扩展这样的语法自然是比较容易，但是，对于DbC，不太可能基类扩展的，除了这种嵌入代码的pre post检查，其他可行方案还包括Attribute和AOP。

@RicCC
其实很多地方的确是都会用到Assert这样的功能，不过使用的目的不同，DbC和UnitTest就是两种完全不同的目的，虽然语法上有相似，但是，目的差别就较大了。

工具是死的，人是活的。真理是永恒的，但是，使用真理的任何过程都是有局限的。

楼主对“持久化”和“ORM”的定义我觉得完全正确。ORM按照广义的理解，就是对象持久化的方式之一，即将对象持久化到关系型数据库。

从这个角度说，无论你如何实现的你的系统，只要使用了数据库来保存了对应了内存中的对象信息，你就已经，也不可避免的使用了这个广义的ORM思想了。

另一方面，ORM我们通常还有另一种狭义的理解，也就是指类似Hibernate这种通过一定的配置方式定义对象和数据库表的映射细节，然后运行时，通过通用的组件（组件自动读取配置信息），以相对一致的数据库无关的方式save/load对象的持久化方式。

JoeLee兄的不同意见其实是因为基于了一个不同的前提，JoeLee提到的ORM，按我看应该都是以上第二个狭义的理解。狭义和广义的理解本身没有好坏之分，但是前提不一致，对问题的看法有差别那是很自然的。依我看两位说的其实基本上都没错~~

再回到谈理想和现实、真理和使用真理的问题。自顶向下或自底向上，作为两个方法论，本身都没有错，离开具体的应用场景和使用者的经验限制，争论谁好谁坏真的一点意义都没有。应用他们的好坏或者说成本，应该取决于具体的应用场景、使用者对不同的开发方法的熟悉程度和掌控能力、另外还有是否有好的开发工具、框架的支持。

再回到最现实的现实中来，如果前提是系统包含需要持久化的OO的对象，OO对象和关系相对来说可以比较容易理解的对应到数据库表和字段，并且前提是应用狭义的ORM工具来实现对象持久化，那么，自顶向下的TDD的开发方法实践证明开发和维护成本相对较低，使用效果会较好一些。

最后再呼吁一下，请大家下判断，给意见的时候加上前提和约束，否则，没有前提所下的定义，导致的口水仗，不解决问题，对读者也许更多的还是误导。

你可以试试生成EntityConfig.xml配置文件，并在web.config中指定实体配置定义的方式。可能可以避免你遇到的问题。我估计是你的实体定义分散在几个dll里，使用嵌入的实体配置的方式可能会有类似的问题。

有点深奥：）
希望东风兄在下次会议时好好向大家介绍一下。

确实是好东西，看一眼就爱上她！

请问瑞克，所谓HVM是什么意思？相比较于原来的混淆，HVM有何不同？

@Mac
可以手动修改wiki\public\Plugins\Config目录下的文件，用文本编辑器编辑，修改里面的连接字符串。

@老夫子系
这个没有内置支持，不过你可以自己修改生成的代码，比如，对所有的QueryColumn类的属性名，删掉你不要的前缀。

@老夫子系
NBearLite.QueryColumnsGenerator.exe工具生成的代码一般会用两个以上的下划线作前缀，你定义的表或字段名称不会也有两个以上下划线前缀吧？

@孤帆
LINQ还没有正式发布，而且，LINQ太for SQL Server了，支持的数据库很有限，就算支持也有太多功能是SQL Server专用的。而且，至少近几年，大多数公司不会那么快应用LINQ，而且还有很多已存在的项目，不可能应用LINQ。。。。太多即使LINQ存在，甚至比NBearLite优秀（该命题值得怀疑~）NBearLite也绝对有存在的意义了。

@Garfield
当然不会。

@JerryChou
NH的HQL不是强类型的，是一个嵌入式的脚本引擎，性能肯定较好。NBearLite的强类型查询语法则是多了一层由操作符、函数重载构成等组成的强类型查询层，这一层的性能损失是必然的。

@阿不
是我没看清楚：）
ExecuteBatchInsert一般不需要使用，只有在超大数据量插入时才需要。
二维数组应该像这样定义：
int ret = database.ExecuteBatchInsert(
"Categories",
new string[] { "CategoryName", "Picture" },
new DbType[] { DbType.String, DbType.Binary },
new object[][] {
new object[] { "testtest", new byte[5] { 1, 50, 100, 150, 200 } },
new object[] { "testtest", new byte[5] },
new object[] { "testtest", new byte[5] }
},
2);

关于ExecuteBatchInsert的介绍有一些错误：
首先，这个方法无需搭配BeginBatchConnection一起使用，而可以直接使用。
其次，这个方法的意义在于能够将超大数据量的Insert（插入的记录数几万甚至几十万）操作，性能提高N个数量级，但是只能用于SQL Server数据库。

更多介绍，请参考：http://www.cnblogs.com/teddyma/archive/2007/07/29/835412.html

@@源
其实这样的测试是有很大局限性的，程序的整体性能瓶颈往往并不会在查询性能本身，随意不用太过在意哪个更好，只要相差不大就好。在更多情况下，框架提供的功能对开发效率的改善要比一点性能损失更值得。

v4会基于v3中最稳定的部分进行加强和创新，且会比v3有更大的测试强度，保证v4正式版比v3更稳定。

oracle不支持BatchUpdate。

@阿不
折起的代码有js脚本错误，4 b)那里，展不开来。我是ie7。建议不要默认折起代码。

已修复NBearV3中的性能问题：http://www.cnblogs.com/teddyma/archive/2007/07/26/831646.html，请使用NBearV3的朋友下载最新的NBearV3.7.2.6版。

已修复NBearV3中的性能问题：http://www.cnblogs.com/teddyma/archive/2007/07/26/831646.html，请使用NBearV3的朋友下载最新的NBearV3.7.2.6版。

@Michael Wang
Ibatis既然直接用sql查询，性能则应该和ADO.NET比较，和NH和NBear比不公平。

@Nick.Lee
单纯的DataRow转换Entity没什么大不了的。NBearMapping的优势在于任意对象Mapping，DataRow转Entity这里只是一种特例，重要的是任意的Object转Object。

@try
请问你是如何测试？“不是很好”又怎么具体解释呢？

我没有看你的具体的代码，不过，无论是什么测试，都会有局限性，只能作一个大概参考。建议大家根据自己的应用场景进行原型测试。

另外，建议使用全新发布的NBearLite进行一下测试，看看是不是性能上有不小的提升呢？
http://www.cnblogs.com/teddyma/archive/2007/07/20/825384.html

@东风31
重要的是一定的技术能力、热情和长久的坚持。

@JerryChou
之所以叫NBearLite而不是NBearData是因为不希望大家认为这是一个必须和nbear的其它组件一起使用的组件，而是一个可独立使用的组件。nbear v4系列的所有组件，都将是互相松散耦合，可灵活搭配第三方产品使用的组件。

@PG
放在首页是觉得对不少朋友会有用，另外也包含了重要的使用演示。如果dudu觉得不妥，或有三人以上非匿名留言认为放在首页不妥，我就撤下来。

@try
nbear v4应该会是延续nbear v3和NBearLite内核的.net 3.X以上版本的集成。

@try
算是nbear中去除实体部分后的简化增强版。保留了nbear中最稳定的查询部分。

根据你的源码，如果我没看错的话，需要引入的js脚本就达到了400K以上~~汗一个~~

很美观~~ 不过既用了jquery，又用了asp.net ajax库，是不是为了用这个控件需要引入的js代码会比较大呢？

@gao
要编译wiki，除了要add existing website wiki目录之外，还要add existing project wiki\src目录中的所有工程。另外可能还要add reference bin目录下的WebValidator.dll。

@finesite
目前的版本应该还没有实名制吧？只是基于UrlRewrite的SEO优化而已。不知道哪里不符合国情呢？

@gao
根据错误提示，应该你没有在iis中将wiki目录设为asp.net web应用程序。进入iis中wiki目录的属性页，点击一下“创建应用程序”那个按钮就可以了。

@AA
可以到这里下载：
http://msdn2.microsoft.com/asp.net/Aa336618