楼主 你能不能把你的代码发个一份啊

自问自答吧，这个还是由于IIS中没有配置好tcp相关。 听同事讲部署的时候可以设置TCP的绑定，会自动和HTTP共享一个80端口。 不知是否是这样。

gommcn@163.com ,谢谢共享

找不到具有绑定 NetTcpBinding 的终结点的与方案 net.tcp 匹配的基址。注册的基址方案是 [http]。 博主可曾遇到这个错误？ IIS配置完毕，服务配置完毕，在浏览器中查看svc文件时候出现。

@imfunny no, 你看到你的是LEN这个函数,我用不到,所以不动了. 我的是全兼容Oracle的,这你放心 . 都是ExpressionParser, 没看出哪里重了,很轻量级的东西. 你可能看到是codeproject的sqlExpressionParser , 我完全没用这个. 自己写了几十行,叫WhereClauseExpressionParser.

这个稍微有点重呵呵。 写个ExpressionParser. 大概两百行就差不多实现了。 并且这些语法也只是mssql的。mssql太慢了。无法忍受。宁可不用mssql。也不能够少mysql.

zhubo006@163.com,谢谢共享

@imfunny @JerryChou 比较了下petapoco, 从项目角度来说,只有petapoco才能满足Dao的要求, Dapper只是内核,很多情况不胜任:事务,分页,参数前缀替换 但对与自定义封装,对于应用到已有框架/平台, Dapper要容易适应,且简单得多. 这也是我封装的原因:在已有框架下,可以透明迁移到不同的dao实现,迁移到不同的数据库平台. 下一步我要兼容mongodb.

@啊长 我返回IDictionary, 没用DataSet 确实有情况,我根本不返回,或者不确定 T 比如我的对象有20个属性, 但是当前查询我只返回Code,Name 这是我并不希望由对象来返回. 弱类型在输入参数时尤为有用. 界面提供10个查询条件输入, 如我上述例子中: param.Add(... 条件到参数我是用辅助类转IDictionary,如同MVC里的dataBinder进行自动转换.

[quote]craboYang： @imfunny 呵呵, 强弱类型都有适用的场景. 用强类型做"自定义组合查询", 那可以先杀了我[/quote] 你的意思是不是返回一个DataSet或DataTable? 有时候 ，我很想返回强类型IEnumable<T>。 但是在定义这个T时，遇到了麻烦：如何定义这个T？ 它可能联合到3、4、5或者更多表的字段，难道要写一个新的Model 来对应这个T？ 或者我的思路错了，仅从表出发来定义model 远不够用啊。

[quote]craboYang： @啊长 你有心学习, Dapper已经是你应该学习的最好代码 扩展什么都是浮云, 不同的人,不同的应用场景适合不同的扩展[/quote] 嗯的，感谢！

@啊长 你有心学习, Dapper已经是你应该学习的最好代码 扩展什么都是浮云, 不同的人,不同的应用场景适合不同的扩展

@imfunny 呵呵, 强弱类型都有适用的场景. 用强类型做"自定义组合查询", 那可以先杀了我

强烈建议LZ把扩展后的代码分享，让我等小菜学习

[quote]imfunny： 呵呵 楼主。就不要使用 IDictionary<string, object> param了 直接一个 Func<object> 来产生sqlquery。 比如Query<User>(r = > r.UserName== "name" 然后产生一个select ... from user where username = 'name'的。 IDictionary太笨重了。 不过还是和编码习惯有关。 其实这几个例子倒体现不出Dapper的用处。期待扩展来丰富更多的选择了。[/quote] 的确，使用表达式更好。 自从使用linq and lambda以来，就不能离开了 ，没有linq写代码很不顺手！ 另外我很想学习如何扩展，比如扩展Dapper， 可以Query<User>(r = > r.UserName== "name") 只是水平太低了，您能否指点一下...

[quote]imfunny： @JerryChou 呵呵，有一天就知道其实petapoco一点都不好,数据切换以及配置都不好实现。 而Dapper是一个IDbConnection。更容易整合。你可以直接在初始化的时候实例化IDbConnection然后取得更高的效率。但是petapoco却行。 主要也看用的思路了。喜欢简单就petapoco喜欢扩展以及效率就Dapper。最近没时间来写一个系列的。 晚上看看有时间的话发个包装后的Dapper。[/quote] 各有所好吧，我最开始接触的是dapper，一个项目中用了，也做了些扩展，后面无意看了petapoco，另外一个项目中就采用petapoco了。两相比较，还是倾向petapoco一些，不过对dapper也还一直在关注。

呵呵 楼主。就不要使用 IDictionary<string, object> param了 直接一个 Func<object> 来产生sqlquery。 比如Query<User>(r = > r.UserName== "name" 然后产生一个select ... from user where username = 'name'的。 IDictionary太笨重了。 不过还是和编码习惯有关。 其实这几个例子倒体现不出Dapper的用处。期待扩展来丰富更多的选择了。

@JerryChou 呵呵，有一天就知道其实petapoco一点都不好,数据切换以及配置都不好实现。 而Dapper是一个IDbConnection。更容易整合。你可以直接在初始化的时候实例化IDbConnection然后取得更高的效率。但是petapoco却行。 主要也看用的思路了。喜欢简单就petapoco喜欢扩展以及效率就Dapper。最近没时间来写一个系列的。 晚上看看有时间的话发个包装后的Dapper。

@imfunny @Treenew Lyn @JerryChou @temptation 已更新, 加入示例. Dapper 官方扩展很一般. Dapper保持目前的API,保持精确的定位是非常正确, 非常必须的.否则又是一个大而全的重型机器,失去它的优势. 如Connection, Transaction不由Dapper内部管理, 这个定位真是太绝了,让我立即就觉得用它.

呵呵。 Dapper有很多衍生版本吧。都有很好的封装。 官方版本衍生了许多的版本。比如 Massive的List<T>的序列，还有lit..什么的。这个名字记不起来了。晚上发给您啊。在家里电脑上。 SQL语句部分官方包有扩展方法。但是作者却不建议使用。事实上这块很简单。并且生成的SQL过于单一。作者的演示代码中就有这个部分。作者在博客中也说过这个，建议是测试使用。（其实这个部分和POCO有冲突，但是的确不知道如何的方法进行统一） 之前有人问过为什么不继续封装。其实主要的道理也在与保持代码的简单。 对于代码倾入，这个我觉得估计可能是使用不当。Dapper扩展在IDbConnection上。一个接口，很难产生倾入性吧。不过我用了IOC.这块也不大清楚。 哈哈，现在终于有人不再迷恋那些重型的东西。 最近忙没办法写完这个系列的。实际上这个上面还包含了好多。。

同意。是需要一些 Demo 来演示，证明其优点。

dapper确实是好东西，另外推荐一个tiny-orm tool： petapoco，其实现包括了一些你做得这些对dapper的扩展。另外，能分享下你扩展后的代码不？

博主能结合Dapper做一些综合的Demo，展现其优点就好了

具体情况难说, 不过我行了, 才发了出来. 参考网上内容, 我自己手写的,亲自验证的. 不是copy

楼主 你这还真的不行

您好,myvehicle@126.com 给我一个吧,谢谢

很俊美的界面。

这跟iPad一毛钱关系啊 晕

@craboYang 谢谢，我已经实现了，虽然不太一样

@alxc 1. 制定计划时，仅本车间配件可查： A.对每一个配件进行授权， 可指定到部门、人员、角色 B.页面绑定配件列表， info = new QueryInfo("配件s"); info.AclProperty="Id"; drp配件.datasource=Dao.FindList(info); C. 由此，配件下来项目自动过滤。对于没有进行授权的，任何人均可见。 2. 仅查看本车间计划： A. 计划本身提供“CreatedBy”属性， info=new QueryInfo("计划p"); info.AddParam("CreatedBy",CurrentUser.Office); B. 逐一对计划授权部门， 查询方法同 1配件列表 实现。

数据权限？看了半天好像只有页面控制和控件控制，不知道是否包含了数据控制？ 比如： 1.3个车间（卷烟厂）：制丝车间、卷包车间、动力车间。 2.车间润滑工每天都要为设备做润滑（就是给齿轮这些零件加润滑油）。 3.现在系统存在几个功能页面：制定计划、执行计划、检验计划。 4.对于以上3个功能页面，如何让不同车间的人进入页面后，只能查询和操作本车间的计划，而对于非本车间的计划看不到。（制丝车间的只能看到制丝车间的计划，同理，包括查询条件机器型号也只能查询到制丝车间的，而不能看到卷包和动力车间的）。

在 ReadEntityBody 之前不能有任何 form,cookie等操作

silvernet@live.com 谢谢

看不懂咧...

支持一下,感觉还不够深入,希望楼主继续!

能发个源码吗？yidaibawang@163.com

贴个代码吧，很感兴趣！

下级有的权限，上级不一定要有

太复杂了，，高手。。sharepoint貌似已经实现这些东东了。。

写的挺好! 有个问题不是很明白,在针对有特定权限的人去取数据列表的时候,怎么做更有效呢个?

对呀，共享吧

高手 就要 贴个源码 供大家研究..哈

高手

@吉日嘎拉 不仅权限管理 楼主是高手，鉴定完毕，

老杨``哈哈```原来是你```果然是WEB高手``还在用ERStudio哦` 高手是应该多发发博文供菜鸟们学习学习，这样的环境才适合技术发展。。

@Macheal.Lee 说话这么激动干什么，上面一行的去掉，有意见说下面一行就行了。 还是支持一下。

做得比我的好，推荐+1

你这权限根本就不可用！ 下级的有权限的话，你上级没有权限 你说你要不要显示下级！

不知所云

@Allen Zhang 动态的。 配置信息都在数据库 Grid Per User. 任何用户都可以有自己的配置。文件型肯定是不行的。