1: 由于公司一次性要开发10多个子系统,每个子系统都需要有相关的业务部门进行对应.2: 若用集中式管理方式,每个业务部门人员变动,权限变动时,都需要早IT信息中心进行调整,影响工作效率.及时性.3: 每个部门的实际情况,只有所在部门的人最清楚,一般希望是随时可以在授权范围内进行更改.4: 其实信息系统是否有独立子系统的管理权限,也是看这个系统的灵活性,健壮性的,设计是否合理也能充分考验.5: 每个业务部门能独立管理自己的业务系统,也减轻IT信息信息中心的工作压力,可以集中精力建设业务系统,把一…

可以给自己的信息管理系统增加一些即时消息提醒功能,简单方便,一般是一行代码就可以发送提醒信息了,方便二次开发,个性化改进. 1:可以用简拼,快速查找内部员工. 2:双击直接可以发QQ消息. 3:双击直接可以发手机短信. 4:当然也可以把电子邮件地址也加上. 5:方便查找本部门人员,本公司人员. 6:可以看到头像以及各种联系方式.…

通常情况下,一个公司内部的部门名称,编号是不可能重复的.但是是在多公司的情况下,很可能有部门名称重复的问题存在,这时需要允许部门名称重复. 例如一个大型IT公司,在2个地区都有研发部或者客户服务部,这些部门的简称大多时候应该是重复的可能性也有,当然编号是不重复是最好的,编号重复了容易更乱了. 有些信息系统数据关系里没有用Id的主外键,可能是用了部门的名称做了数据的关联,所以组织机构管理里,虽然部门名称不允许重复,但是特殊情况下只能允许重复. 允许重复也不对,不允许重复也对,没有绝对的,所以干脆来…

折腾了2-3周,终于把全国网点数据权限,省.市.县数据规范化,查询权限规范化,基础数据规范化的思路理清楚了, 今天应该是一个里程碑式的一天 省市区数据规范化后 1:网点的基础数据可以更加严谨规范化. 2:用户的权限设置可以更加规范化. 3:限制用户查询范围的限制可以更加规范化. 4:业务系统调用的函数可以更加规范化. 5:系统底层稳定了后,开发出来的业务模块也可以稳定一些. 6:质变与量变,系统底层基础稳定成熟思路明确与之上开发N多业务子系统的长期建设优化. 7:网点应该从地理位置上,明确归属于…

若全国各地有上千个分公司,加盟店,网点,那就需要一个友善的选择分公司的功能,得有标准的全国省市县的划分数据.这样有了牢靠的基础数据后,才能开发程序得心应手了.当习惯了开发一个公司内部系统时,全国性大公司的业务系统也需要有一个熟悉过度的过程.基础数据不过关,思维不严谨,开发什么程序都会凌乱.…

业务系统里经常会需要计算类似的树形权限树的业务需求 1:往往会有一些需求,a 对 b 有权限, b对c 有权限, 等等. 2:还需要很直观的看到,整个权限的树形关系,一目了然的那种. 3:程序调用简单,写代码很容易能调用我们写好的函数. 4:程序稳定,bug 少,考虑周全. 直接上图: 在模块菜单定义里,需要一个数据权限项的设定,设定方式如下图 代码调用方法: BasePermissionScopeManager permissionScopeManager = new Business.Bas…

最近工作上需要,给苹果客户端开发接口,实现集中统一的用户管理,下面是接口调用参考. 1: 获取OpenId? http://127.0.0.1/GetOpenId.ashx?username=Administrator&password=Administrator 2: 获取用户信息? http://127.0.0.1/GetSignin.ashx?OpenId=fa05d010-dc80-40f8-80c5-4d32e4d7b2c2 3: 修改密码? http://127.0.0.1/Chan…

A.系统有两个添加用户 一个是申请用户.一个是添加用户.这两个分别在什么情况下使用? 回答 1:不是所有的用户都是管理员添加的,特别是分公司多,部门多时,都由管理员添加,效率低,而且很容易输入不精确的数据. 2:每个部门,或者新员工可以让身边的同事帮忙申请帐户,然后管理员一审核通过就可以了,这样效率高,而且还可以申请自己想要的用户名,密码,非常符合实际.   B.我可不可以把用户管理和用户权限合并起来,原先的先添加用户,然后再到另一个地方去授权感觉太麻烦了. 回答 1:可以合并起来,简单的系统可…

客户端会提醒是否有网络订单来了,这样及时处理网络上的用户下单,当然也会有手机短信系统,全国几千个网点就可以协同作战了,竟然有序的处理海量用户的下单.网络订单提醒功能增强效果如下: 系统每5分钟会检查一下当前网点是否有订单 每个网点都仔细维护好自己所外的地理位置,省.市.县.街道为止.若数据有问题的,还可以随时联系后台管理员. 每个功能的背后都有一个小小的故事,每个功能做出来稳定好用,都非常艰辛.…

当用户数据有接近10万时,而且多表的关联也比较频繁时,能把大表拆为小表,也会提高系统的性能,I/O.运算性能.当然以后用户数据会更大可能会到30-40万以上,所有有能力时适当拆表,分分合合,合合分分也是有必要的. 拆表后,响应的类可以自动生成,代码生成器再生成以下就可以了,这样生成好的代码就兼容多种数据库了,Oracle也支持了. 用户的所有联系方式都进行了拆分了,将来有更多的联系方式,来往.易信.微信.旺旺都可以增加,不会影响系统的性能了. 这个是实体类里的代码参考,若新建立的表是空的,没默认…