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

在上一篇中我们讲了大致怎么搭建一个项目,以及一个项目的基本构架,这一次,我们讲解基本的权限管理思路.

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

首先是数据库设计:

在此期间,我们贴上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界面传参的修改,我们的目标是,让修改更简单,业务的变动,我们仍然能够清晰的把握细节.

/*  作者：       tianzh
*  创建时间：   2012/7/26 15:52:19
*
*/
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Web;
using TZHSWEET.Entity;

namespace TZHSWEET.ViewModel
{
    public class ViewModelButton
    {
        #region - 属性 -

        public int ID { get; set; }

        public string Action { get; set; }

        public string Name { get; set; }

        public bool IsVisible { get; set; }

        public string Script { get; set; }

        public string Icon { get; set; }

        public string Controller { get; set; }

        public string Description { get; set; }

        #endregion

        #region - 构造函数 -

        public ViewModelButton()
        {

        }

        public ViewModelButton(HttpContextBase context)
        {
            ID = Convert.ToInt32(context.Request["ID"]);
            Action = context.Request["Action"];
            Name = context.Request["Name"];
            IsVisible = context.Request["IsVisible"] == "1";
            Script = context.Request["Script"];
            Icon = context.Request["Icon"];
            this.Controller = context.Request["Controller"];


        }

        #endregion

        #region - 方法 -
        #region ToEntity
        public static tbPermission ToEntity(ViewModelButton permission)
        {
            tbPermission item = new tbPermission();
            item.PermissionID = permission.ID;
            item.PermissionName = permission.Name;
            item.PermissionAction = permission.Action;
            item.Script = permission.Script;
            item.Icon = permission.Icon;
            item.IsVisible = permission.IsVisible;
            item.PermissionController = permission.Controller;
            item.Description = permission.Description;
            return item;
        }

        #endregion
        #region ToViewModel
        /// <summary>
        /// 转化为ViewModel
        /// </summary>
        /// <param name="permission"></param>
        /// <returns></returns>
        public static ViewModelButton ToViewModel(tbPermission permission)
        {
            ViewModelButton item = new ViewModelButton();
            item.ID = permission.PermissionID;
            item.Name = permission.PermissionName;
            item.Action = permission.PermissionAction;
            item.IsVisible = permission.IsVisible.Value;
            item.Icon = permission.Icon;
            item.Script = permission.Script;
            item.Controller = permission.PermissionController;
            item.Description = permission.Description;
            return item;
        }

        /// <summary>
        /// 转化为List集合
        /// </summary>
        /// <param name="list"></param>
        /// <returns></returns>
        public static IEnumerable<ViewModelButton> ToListViewModel(IEnumerable<tbPermission> list)
        {
            var listModel = new List<ViewModelButton>();
            foreach (tbPermission item in list)
            {
                listModel.Add(ViewModelButton.ToViewModel(item));
            }
            return listModel;
        }
        #endregion

        #endregion


    }
}

一般情况下,我们只需要定义实体,和一个构造函数,这个构造函数,大家可能觉得为什么要传递HttpContext?

原因就是,封装Controller中的请求,把Controller中表单的数据请求单独用ViewModel处理,看看关于Controller的一个函数处理

我们把关于请求的数据从Controller中分离处理啊,Controller就相当简洁了,很清晰的看到具体的思路,而我们的业务逻辑层,就可以相当简洁的调用

而这个T是什么呢?T就是tbPermission实体这个东西了,是不是发现页面非常清晰,简洁?

而我们经常通用的几种UI格式,LigerUI Grid格式请求,Select格式请求,GridTree格式请求,Tree格式请求,都是ViewModel中的封装,

GridRequest请求的ViewModel:

 /*  作者：       tianzh
 *  创建时间：   2012/7/19 18:16:08
 *
 */
 /*  作者：       tianzh
 *  创建时间：   2012/7/16 15:31:37
 *
 */

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Web;
namespace TZHSWEET.ViewModel
{
    public class LigerUIGridRequest
    {

        private string sortOrder;

        private int pageSize;
        /// <summary>
        /// 字段查看视图(暂时没做到)
        /// </summary>
        public string View
        {
            get;
            set;
        }
        /// <summary>
        /// 排序字段名称
        /// </summary>
        public string SortName { get; set; }
        /// <summary>
        /// 排序规则
        /// </summary>
        public string SortOrder
        {
            get
            {
                if (this.sortOrder == "desc")
                    return this.sortOrder;
                else
                    return "asc";
            }

            set
            {
                this.sortOrder = value;
            }
        }
        private int pageNumber;
        /// <summary>
        /// 页号
        /// </summary>
        public int PageNumber
        {
            get
            {
                if (this.pageNumber <= 0)
                    return 1;
                else
                    return pageNumber;
            }
            set
            {
                if (value <= 0)
                    pageNumber = 1;
                else
                    pageNumber = value;
            }
        }
        /// <summary>
        /// 每页的多少条数据
        /// </summary>
        public int PageSize
        {
            get
            {
                return this.pageSize;
            }
            set
            {
               this.pageSize= (value==0?10:value);
            }
        }
        /// <summary>
        /// 查询条件
        /// </summary>
        public string Where { get; set; }
        /// <summary>
        /// 初始化读取信息
        /// </summary>
        /// <param name="context"></param>
        public LigerUIGridRequest(HttpContextBase context)
        {
            this.View = context.Request["view"];
            this.SortName= context.Request["sortname"];
           this.SortOrder = context.Request["sortorder"]=="desc"?"desc":"asc";
           this.PageNumber =Convert.ToInt32(context.Request["page"]);
           this.PageSize =Convert.ToInt32(context.Request["pagesize"]);
            this.Where = context.Request["where"];

        }
    }
}

在这里我们可以做数据的校验工作,这样我们的控制器就非常非常的简洁了,

在业务逻辑层,我们可以通过Request的ViewModel模型,进行数据处理,

可以看到我们仅仅通过数据的封装就让我们的UI和业务逻辑更简洁,更丰富,

当然这个业务逻辑层写的很有问题..............就是业务逻辑层竟然直接返回json格式,这个大大的不好,因为我们的业务逻辑层尽可能的跟数据的展示格式没关系,应该直接返回数据,集合就直接返回IEnumerable<T>接口,而数据如何展示应该在控制器中控制.

一个好一点的方法设计就是这样子的,

可以看到我们的工作大部分就是让不同的类减压,尽量更简单,单一指责,如果一个类的职责过多就更难维护,特别是控制器,很容易出现大量的代码,

就像我们的这个

让代码更精简,这样我们才能更清晰,本来我们返回的Grid数据需要json化,我写了一个扩展方法,返回json,而且格式针对UI更友好,配合前台的封装的ajax,让消息的提示更友好,

前台利用LigerUI中的封装,

 

 

 

 

总结:可以看到我们每一部细节的改进,都能让我们代码更简洁,而且让我们的思路更清晰,清晰,才是我们的追求,清晰的代码是我们的追求!