一步一步Asp.Net MVC系列_权限管理数据库与ViewMod

yibin 2015-02-09 建站源码 552

在上一篇中我们讲了大致怎么搭建一个项目,以及一个项目的基本构架,这一次,我们讲解基本的权限管理思路.
说道权限管理,相信大家都 不太陌生,这个东西几乎什么系统都会涉及到,因此,抽出时间去思考,去研究复用的模块,架构,就是一个非常好的提升水平的方式,特别是对于我们这些学生来 说,没有太多经验,更需要去研究这些东西来更多的掌握实战方面技巧.数据库设计是一个几乎人人都要面对的一个话题,我就来讲,我的数据库设计.当然只是 个人见解,博客园的很多人都设计的各种各样的权限,各种各样的思路,但是可能大多数设计的比较复杂,我只是从一个菜鸟的角度讲解,我能够理解的权限管理.
首先是数据库设计:
在此期间,我们贴上powerdesinger设计图


大致就是7张表:
tbModule模块表
tbModulePermission模块权限表
tbPermission权限表
tbRole角色表
tbRolePermission角色权限表
tbUserRole用户角色表
tbUser用户表
首先要注意的就是命名:
可以看到,我的数据库命名风格是非常统一的,呵呵,这个可能是习惯,tb代表table,如果是视图我就在前面加上v,后面全部是Pascal风格的命名,字母大写的方式.
一个清晰的命名可以让我们很容易看清细节,起一个好名字非常重要.
这也告诉我们,我们平时注意细节,命名,代码规范统一,让我们节省大量的时间.
在博客园看到很多权限设计思路,
我觉得上面这个可能是比较清晰的,呵呵,参考了好多人的设计,
权限设计要设计那些呢?
首 先,一个模块对应多种权限,增删改查,导入导出等等等等,这里权限在mvc里面可以控制到每一个请求,每一个ajax响应,在mvc里面有一个很好的对应 关系,一个模块对应就是一个控制器,一个action就是一个权限(当然这种可能太细了,但是我们可以先这么看),这样我们就需要在tbModule和 tbPermission中间加一个tbModulePermission表了,因为不同角色的同一模块的权限可能都是不一样的,所以这里要加入一个 tbModulePermission表.
其次,角色的设计,角色拥有模块权限,每个用户对应多种角色,这个用户可能即是普通管理员,又是其他后台编辑,等等,权限当然是不一样的.
这样一个思路就很明显了,角色直接拥有各种模块的功能权限,而用户可以扮演各种角色.
至于字段的设计,我看了很多人的设计,很多细节的字段,比如IsDeleted,CreateUserID,CreateDate,ModifyUserID,ModifyDate,Description这些几乎大部分表都是需要的,多加一些表,更是让设计更灵活.
数据库的设计ID用GUID的习惯,我还没有养成,可能现在没遇到麻烦吧,也是没有真正的工作经验,呵呵,别人都说应该主键用GUID,呵呵!
我 看到很多人直接设计Menu和Button来表示tbModule和tbPermission,其实感觉从命名来讲,页面任何一个ajax请求都可以算是 一种功能权限,可能不是Button,如果用Permission表示可能更好一点,至于Menu,我认为用Module来命名可能更好,在 tbModule里面有一个IsMenu字段来表示是否是菜单,里面有一个Controller字段,其实大致对应一个Controller控制器,每一 个模块在mvc中以控制器的方式展示,我们在设计UI菜单的时候也可以通过反射的方式来获取Controller,对于菜单的设计更友好,不需要自己去配 置URL,更自由.当然,在Permission表里面有PermissionAction和PermissionController字段表示,每一个 动作请求和对应的控制器.


对于菜单的添加我们可以做到非常轻松,点点点就能够配置好,以前需要在数据库输入的一些预定义的数据!
数据设计好了,这种数据库可能我感觉比较清晰.呵呵!
接下来,我们继续谈关于设计的问题,上次基本上已经讲完关于数据访问层的设计,这次讲解,关于ViewModel的设计和公共类库的设计,
ViewModel呵呵,我用它来干什么,我用它来做UI层和业务逻辑层交互的实体对象.
可能大家觉得EF已经帮我们设计了数据库的实体对象,为什么还要另外一个单独的层来定义交互的实体对象?


我 把这个ViewModel就是和界面交互的实体对象,在EF基本上是根据数据库直接生成的实体,所以命名字段都是跟数据库紧密结合在一起的,往往我们给 UI层展示的时候,要做大量的处理,而UI交互,经常性我们用的后台框架都要求提供指定格式的json数据,我们以前甚至这么干过,从数据访问层直接 select DeptID as id,name as title from deptment……………这种代码简直太坑爹了,而几乎数据库的东西和界面都关联到一起了,如果我们修改个字段,界面改点东西,两头都要动,所以,这种 模式太痛苦了.
因此,我专门独立了一层,用来做UI和业务逻辑层的交互使用,这样ViewModel与UI更友好,用例子说说吧!
数据库的Permission在界面中大量显示为Button,我们就可以直接定义一个ViewModelButton类,来做UI和业务逻辑的交互,
如果对于普通字段的添加,我相信在这个代码中,你的改动非常少,几乎只是EF模型重新生成,ViewModel,和html界面传参的修改,我们的目标是,让修改更简单,业务的变动,我们仍然能够清晰的把握细节.
  1:  
  5:  using System;
  6:  using System.Collections.Generic;
  7:  using System.Linq;
  8:  using System.Text;
  9:  using System.Web;
 10:  using TZHSWEET.Entity;
 11:  
 12:  namespace TZHSWEET.ViewModel
 13:  {
 14:      public class ViewModelButton
 15:      {
 16:          #region - 属性 -
 17:  
 18:          public int ID { get; set; }
 19:  
 20:          public string Action { get; set; }
 21:  
 22:          public string Name { get; set; }
 23:  
 24:          public bool IsVisible { get; set; }
 25:  
 26:          public string Script { get; set; }
 27:  
 28:          public string Icon { get; set; }
 29:  
 30:          public string Controller { get; set; }
 31:  
 32:          public string Description { get; set; }

扫码添加微信

13013082126 扫描微信 建站咨询 优化咨询