01. 不可能有万能的数据库访问组件，遇到什么数据库都能解决，所以不可能的，这个是错误的，其实
MySqlHelper、OleDbHelper、OracleHelper、SqlHelper 你可以有很多扩展开来，这样就解决这个问题了。
02. 写程序要有理论层次，什么叫工厂模式，一定要搞清楚，什么叫反射，如何动态调用不同的dll里的类要会的。
03. 接口是干啥的？为什么要有接口，如何通过接口动态调用，这些必须要搞明白的。
04. 我不要这么复杂的，我要直接调用，那简单，你就其他的不存在，你不想要的，都删除了吧。
05. 我不需要重量级别的，要最简易的，那你可以直接调用 静态类 DbHelper.什么什么方法，就可以了。
06. 你写的程序是不是很乱？ 这个程序是我写了7-8年精心维护的，所以对初学者来说，给你带个好头。
07. 数据库访问接口能通用嘛？ 电脑也就1、0就搞定了，数据库不常用的不就是 select, insert, delete 这几个嘛？
08. 你这个跟主流的代码生成器什么的，兼容不？ 兼容的，我们跟东软的代码生成器是完全兼容的。
09. 用你这个有什么好处，我有项目了，经常会发布过去，你的模块是基于我这个开发的，我可以采购你的模块。
10. 有些公司的技术水平很菜，也不是技术类型的公司，那你直接用这个，提升一下层次吧。
11. 你的代码下载了编译不通过啊，哪里不通过，实在不行你就删除哪里吧，编译通过了，就可以用了。
External 目录里，需要的dll都在的，你自己添加引用一下，就可以了。
12. 是否考虑了事务什么的？放心这个是最基础功能之一。
13. 一个系统需要同时访问多个多种数据库可以嘛？可以的，而且我们都测试过，项目里用到过了。
14. 你这里是不是没用的东西特多？ 我这里只是管数据库方面的东西，其他东西几乎是没有的，分工很明确。
15. 大家都会觉得自己的才是最好的，特别是有些经验的人，很容易变成老顽固，所以我这个不好的，请大家
指正，我积极改进，若你是菜鸟你没有成熟的，欢迎采用我这个模式。
16. 例子代码有嘛？ 接下来我会发布的。
17. 是否有调试功能，能方便调试出，一个SQL语句执行花费了多上时间，是否需要优化？有的，你可以仔
细看看。
18. 是否B/S、C/S 系统里都可以通用？完全可以的，我们经过了很多年的测试。
19. 是否考虑过并发的问题，同时有好多人用时，会不会产生并发问题？放心，这个我们也演过测试过。
20. 能否处理Oracle的数据锁定问题？ 没问题，我们经常用Oracle数据库开发。
21. 若发现这里有些错误，修正后，会不会影响在这个架构上编写程序的稳定性，修改的工作量大不？ 没问题，你放心用吧。
22. 所有执行过的SQL语句是否都能记录下来，方便DBA调试的？有的，这个功能也做了，可以有开关打开的。
23. 你的代码我看不懂，也不大搞懂这个有啥用，那你先再学习提高提高再来看我的东西吧。
24. 我们是上市公司，所以发展潜力比较大，你采用我这个标准，以后我可以采购你的模块，我们会影响很多
人按我们的要求开发，虽然不是最好的，有总比没有强，所以你看看我们这个，也有些意义。
25. 此架构的圆形是从 .NET1.0 时开始写的，一直比较好用，就没怎么大动过架构，参考了 DNT的架构后有
所启发，还有跟，需要按 .NET2.0 的方式进行一次改进，这里非常感谢，很多人都手怎么怎么的，没能影响
到我啥，你就这么一写出来代码，我就知道需要按 kiler 的意见改进一下。
26. 博客员里的 金色海洋，给了提了一个宝贵的意见，实现接口需要写的代码多，用基础类继承效率高，也能
听得进去，这里非常感谢 金色海洋，你们说的都是对的，我不是老顽固，告诉我道理，告诉我如何修改，我就
改进完善。
下载代码，点这里。 /Files/jirigala/DotNet_Common_V1_5.rar
写得不好的地方，非常欢迎你指点指正，我把代码发布出来，也是为了得到大家的指点。
代码效果图
注释效果图
程序功能排版效果 
代码效果
以下讲解是按最复杂的情况，讲解权限的要用法，若页面上不需要判断那么多，那么复杂的权限，那也不用搞得这么复杂，简单才是硬道理。
第一步： 首先需要在你需要用的页面里，把权限变量定义好，说俗点儿，就是你这个页面能用到哪些权限定义，都分哪几个权限，这些都事先定义好了，后面也好开展工作，很可能一个页面只需要一个权限，也可能需要需要10个权限，我并不认同，每个页面都是添加、删除、修改权限，有可能是这样，但是还有部分情况下不只是这些功能。
第二步：写上标准的GetPermission()函数，在这个函数里，调用this.Authorization（）函数，将当前用户的相关权限获得，为接着按这些权限的处理工作做好准备。 
第三步：在页面的FormOnLoad事件中，调用获取权限的函数，这样这个页面在加载时，就可以调用这个函数了。
第四步：（这步可以省略）若想做配置得很灵活，就可以把页面中判断的权限，做一个配置文件，就是映射前台判断函数与后台权限的，一下图片中 8个页面上的权限判断，统一映射到后台是一个权限配置项目“UserAdmin”这个权限设置。
第五步：在后台配置好，我系统到底有哪些权限项目，进行授权，你可以做比较细的权限配置项目，也可以做一个比较粗的权限配置，可以将页面上进行了很细的控制进行对对一的映射，这样客户需要比较粗的权限控制，你就可以做个粗放的，客户需要细腻的权限控制，你就做个很细腻的权限控制，可以根据客户的需要灵活进行定义。
总结：
其实从严格的意义来讲，我们做事情的思路都是很凌乱的，先想到哪里做到哪里，碰到问题了，再解决问题，其实是先配置规划权限，然后再把前台程序员开发的权限与配置库进行一个匹配，理论上是这样做才对，但是实际工作往往比理论状态残酷很多，谁都会懒得写配置文件，懒得调整来调整去，前台是什么权限，直接就在后台也加一个这个权限，往往会变成一对一的权限对应关系。所以你设计的权限系统，又需要满足最理想的理论状态，又需要满足最残酷的实际情况。
设计逻辑图说明：
前台权限与后台权限设置，可以有2个途径，一个直接映射到后台设计，另一个是通过权限映射表，周转一下，可以把权限配置得更灵活一些。
有疑问请留言，有兴趣请留言，有写错的地方，欢迎指点批评。
第一步：我的后台管理控制端，有一个叫模块配置的功能，这里集中配置，哪些模块可以用，哪些模块先锁定，这里统一进行配置管理，例如哪个模块还没开发完毕，还在开发中，或者哪个模块出现了重大隐患，可以暂时屏蔽起来等，这个功能在真实的开发过程中的确能派上一些用处。
第二步：我有的后台里，有一个模块管理功能，可以管理所有模块的详细情况，模块的名称及连接地址等，有效表明这个模块是否可以用？
公开表明这个模块是否任何都可以访问，例如新闻类的前台展示模块等，这些都是不用配置权限，属于所有内部员工都可以查看、访问的模块。
第三步：有新模块，可以在后台进行添加，若模块的连接地址等不正确，还可以进行配置管理。
第四步：通常的小系统里，我们是直接设置哪些人，有访问哪些模块的权限等，可以通过后台管理软件的用户管理-用户权限-用户模块访问权限进行设置配置，打钩表示用户可以访问此模块，树型机构的好处是配置权限的效率高一些，点选子节点非常方便。
第五步：可以在B/S里通过如下代码，获得当前用户所拥有模块访问权限的所有有效的模块，都可以列出来了，若有兴趣你可以自己研究研究，若没兴趣直接拿过来用就可以了，我们反复测试了很多遍，出错的可能性也很少，就算有错了，也没必要自己修改，及时反馈给我，我会统一进行修正就可以了。这样大家都可以省心省事了，个子按个子的分工工作就可以了，把有限的精力，都放在自己最关心的事情上。
我们的宗旨是，只要学会用通用的权限配置程序把权限按自己的需要进行配置后，就可以通过简单的API函数调用就可以打到我们的最终目的，我们也对权限的实现细节没兴趣，也不想研究这些，对这个也没兴趣，甚至也没时间去学习这些，只是能用就可以了，开发人员把节省下来的时间更多的是用于理解客户的业务知识，实现客户的业务需求，把精力腾出来，用在学习上，用在客户关系处理上，用在家庭娱乐上，我们没必要每个人都从头做起，折腾很久，浪费很多精力在这个上，等有兴趣学习权限时再来做权限的二次开发等，研究源码等。
我们系统里的数据集合权限，主要由2种功能实现，首先是对 用户直接设置数据集权限，其次是对角色设置数据集权限，再把用户归属与某些角色。
数据权限，我们分为：以下7种。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
