ASP.NET MVC+EF框架+EasyUI完成权力管理连串(3)-面向接口的编程

 
 ASP.NET MVC+EF框架+EasyUI已毕权力管体系
(开篇) 
(1)框架搭建
    (2):数据库访问层的布署Demo

   
“浩然老师,明儿早上大家去三亚旅社就餐,我去那吃了饭再去广场找你,我得以打个车过去,你告诉自己非常地方应当怎么称呼”

  前言:那篇博客在数额访问层的基础方面大家后续求学对这么些Demo的花费,希望大家都好好精通一下那么些Demo的架构,到终极自己达成权力的时候自己就简单来讲一下搭建进度就OK了,因为这么些Demo的思维就是依据权限的设计艺术去规划的,上面大家开始介绍面向接口的编程思想,即使感到好的话可以点一下扶助,下边大家切入大旨。

    “ 四宝山,联通路与宝山路交叉路口向西至四宝山派出所站点下车”

1.新建面向接口编程的类库

 
……广场耀眼的灯光不怕寒冷,殷勤地照耀着那长长的褐色围巾,红红的火苗活泼地跳动,托着展颜而笑的脸如同风中绽放的梅,相同的民谣耐心地五遍遍循环,寒气成霜薄雾一般包围上来,又被心绪的舞步驱散,一个小时急忙过去了……多个奇特的晚自习,已毕了一般近一个月的学科,成立了海军舞速成的吉里昂记录。

  (1)在那篇博客中大家重点针对面向接口进行编程,既然是面向接口,那么我们就非得要在创设一个存放接口的类库,然后创造几个接口,上面我就详细的叙述一下创设这些接口类库和接口类的进度。

     
牛山淄水美人兮,直奔花山浩然来,为健身而舞,为欢乐而学,牢牢把握当下,内寻那份执着,不畏严寒,我自风情万种。那是如何一种舞者精神!

  (2)首先大家在这一个体系上面成立数据库访问接口层的一个类库,起名为:LYZJ.UserLimitMVC.IDAL,然后我们创制两个接口类,依此是:IBaseRepository.cs,IUserInfoRepository,IRoleRepository。我只是那样说的话也许有些人会觉得云里雾里的,所以自己那里就将品种的图纸放在上边,方便我们精通,如图所示:

    “We are on the way back home. Nice to have met you. Thanks again”

      
   图片 1

    原谅自己拽希腊语啦!”

  (3)下边大家详细来分析LYZJ.UserLimitMVC.IDAL类库上边的八个接口类所已毕的功能。

    “我拽汉语”:“我们踏上回家之路。好极了,雅观地遭受,再谢!”

2.
LYZJ.UserLimitMVC.IDAL类库中多少个接口类的分析

   
“在不忙的时候,给你三个作业:一,巩固所学舞蹈;二,再拽篇保加利亚共和国语日记,记录一下出色的宝山广场……”

  (1)IBaseRepository,在这几个基接口中大家封装了拥有操作数据库的点子,从此外一种角度来看接口的话接口就是一个封锁,大家定义接口约束了操作数据库的法门,下边因为每个数据库实体(UserInfo,RoleInfo)都亟需操作数据库的接口,所以自己定义了一个基接口用来落到实处对数据库的造访方法的包裹,然后数据库实体只须要继续自那几个基接口即可,代码如下:

    “Thanks for the homework. A little hard but I will try”

 1    public interface IBaseRepository<T> where T : class, new()
 2 
 3     {
 4 
 5         // 实现对数据库的添加功能,添加实现EF框架的引用
 6 
 7         T AddEntity(T entity);
 8 
10 
11         //实现对数据库的修改功能
12 
13         bool UpdateEntity(T entity);
14 
15  
16 
17         //实现对数据库的删除功能
18 
19         bool DeleteEntity(T entity);
20 
21  
22 
23         //实现对数据库的查询  --简单查询
24 
25         IQueryable<T> LoadEntities(Func<T, bool> whereLambda);
26 
27  
28 
29         /// <summary>
30 
31         /// 实现对数据的分页查询
32 
33         /// </summary>
34 
35         /// <typeparam name="S">按照某个类进行排序</typeparam>
36 
37         /// <param name="pageIndex">当前第几页</param>
38 
39         /// <param name="pageSize">一页显示多少条数据</param>
40 
41         /// <param name="total">总条数</param>
42 
43         /// <param name="whereLambda">取得排序的条件</param>
44 
45         /// <param name="isAsc">如何排序,根据倒叙还是升序</param>
46 
47         /// <param name="orderByLambda">根据那个字段进行排序</param>
48 
49         /// <returns></returns>
50 
51         IQueryable<T> LoadPageEntities<S>(int pageIndex, int pageSize, out int total, Func<T, bool> whereLambda,bool isAsc, Func<T, S> orderByLambda);
52 
53     }

      “you are really great.”

  (2)IUserInfoRepository,那么些接口只必要完结屡次三番自基接口即可,当继承基接口的时候就落到实处了基接口中的所有办法,代码如下:

      …… 人下车了,包包还在车上呢!

1     public interface IUserInfoRepository:IBaseRepository<UserInfo>
3     {
4 
5     }

      最终轮着我拽半句美语了:“you are really great,too!”

  (3)IRoleRepository,和第(2)个说多美滋(Dumex)样,代码如下:

图片 2

1    public  interface IRoleRepository:IBaseRepository<Role>
2 
3    {
4 
5     }

图片 3

  (4)注意:当大家操作IUserInfoRepository和IRoleRepository的时候我们须求添加LYZJ.UserLimitMVC.Model的引用,因为我们要用到数据库实体对象。

图片 4

3.数据库访问层的再次设计(LYZJ.UserLimitMVC.DAL类库)

硝烟弥漫文化咨询承接集团管理、法律、合同、安全、环保、消防、建设管理咨询策划、诗书交换、个人周易起名、舞蹈培训。15689302858

  (1)角色仓储(RoleRepository)的统筹

      
当大家做到多少访问接口层的时候,那时候我们即将重复修改数据库访问层的数码,因为要用到数据库访问接口层,所以我们要添加数据库接口层的DLL,LYZJ.UserLimitMVC.IDAL。

      
然后大家的角色仓储要三番一次数据库访问接口层的角色仓储接口,代码如下:

1     public class RoleRepository : BaseRepository<Role>, IRoleRepository
2 
3     {
4 
5     }

 (2)用户仓储(RoleRepository)的宏图,和地点的分解一样,代码如下:

1     public class UserInfoRepository : BaseRepository<UserInfo>, IUserInfoRepository
2 
3     {
4 
5     }

 (3)数据库访问层的规划思路是:先三番五次基类,在促成接口。上面的完毕正是引用了那句话来落到实处。

注脚:数据库访问层大家就说到此处了,假若大家有怎么样不懂的要么不明了的,可以给本人留言,我将在第一时间回复,下边大家先导商量业务逻辑层的兑现

4.工作逻辑层(BLL)初探

  (1)从伊始到现行我们的数据库访问层只好算得暂时告一段路了,因为在前边大家还会修改数据库访问层,我们前几天写的代码并不是直接不变的,而是随着写渐渐的大家就会领取出来很多事物进行包装,所以只要您细心看我博客的话我直接在修改那些代码。

  (2)业务逻辑层是怎么样吧?我深信只要做过asp.net三层架构的用户都是领会的,就是对数据库访问层的包裹,在那里我也不详细的演讲什么是业务逻辑层了,倘若大家不太知道的话能够去百度或者谷歌找寻一下。

  (3)上面咱们对工作逻辑层开端开展操作

5.业务逻辑层(LYZJ.UserLimitMVC.BLL)的贯彻

  (1)首先大家新建一个UserInfoService类,那些类就是对UserInfo的事体逻辑举行落实(增删改查)。

  (2)若是我们要落到实处业务逻辑层的话,大家即将添加数据库访问层和实体层以及操作Entity
FrameWork框架的的DLL,如下:LYZJ.UserLimitMVC.DAL,LYZJ.UserLimitMVC.IDAL,LYZJ.UserLimitMVC.Model,System.Data.Entity。

6.UserInfo业务逻辑类的兑现

  (1)首先我贴出UserInfo.cs类的代码,在此地大家要细心的剖析一下UserInfo类的代码的落到实处:

 1 namespace LYZJ.UserLimitMVC.BLL
 2 
 3 {
 4 
 5     /// <summary>
 6 
 7     /// UserInfo业务逻辑
 8 
 9     /// </summary>
10 
11     public class UserInfoService
12 
13     {
14 
15         //访问DAL实现CRUD
16 
17        //private DAL.UserInfoRepository _userInfoRepository = new UserInfoRepository();
18 
19 private IUserInfoRepository _userInfoRepository = new UserInfoRepository();
20 
21        
22         public  UserInfo AddUserInfo(UserInfo userInfo)
23 
24         {
25 
26             return _userInfoRepository.AddEntity(userInfo);
27 
28         }
29 
30  
31         public bool UpdateUserInfo(UserInfo userInfo)
32 
33         {
34 
35             return _userInfoRepository.UpdateEntity(userInfo);
36 
37         }
38 
39     }
40 
41 }

  (2)因为我们的政工逻辑层要用到实体对象,也就是UserInfo,所以那边大家需求加上引用,那么些我再下面已经涉及过了。业务逻辑层就是去拜访数据库访问层(DAL),然后完毕对数据库的增删改查,所以大家就须要定义一个数据库访问层的实例:private
DAL.UserInfoRepository _ userInfoRepository=new
UserInfoRepository();不过一旦大家这么做的话就完全的违反了俺们说的依靠接口编程,所以大家不提出那样写,既然我们曾经有了接口了,那么大家可以借助接口定义:private
IUserInfoRepository _ userInfoRepository=new
UserInfoRepository();,那么那三种写法的差距在哪里吧?它们有哪些异样呢?下来自己几乎的说一下:

  (3)下边三种概念的界别在哪个地方

      下边那三种写法,可能有些人会以为并未分别,其实不然,那里如此写的不相同很大,若是大家在底下有众多艺术的话,大家具备的措施都要去调用存储里面的艺术,而这些蕴藏却是接口实例,跟实际的兑现就不曾什么关系,也就是说我们工作逻辑层看重的数据访问层的接口,只要接口不成形,那么上面的代码都是不会转移的,假诺某一天大家须要用ADO来完结这几个职能的话,我们只须要替换掉new前边的UserInfo仓储,换成ADO.NET完成的储存,那样的话大家下面的不二法门都是不需要转移的,那就是所谓的看重接口编程。只要接口不扭转,那么大家下边的代码永远不会变卦。

7.不想new
UserInfoRepository();仓储,怎么办?

  (1)通过上边大家定义接口来实例化对象已经使用了看重接口的编程,不过现在本身还不想new
UserInfoRepository();实例,因为这一个目的极有可能转变,有可能行使EF完结的存储,有可能选用ADO达成的存储,而且大家统筹到工作逻辑层的实例都要定义仓储对象,那么当大家实体很多的时候,维护起来格外的不便宜,大家须求各种页面的去修改这几个事物,所以在此处大家就可见想着使用一种什么方式将那些蕴藏做为一种参数传递进去,而我辈只要求在传递参数的类里面进行维护,上面大家就分析一下怎么选择。

  (2)蒙受变化点,大家就要想办法看能或不能封装起来,那里当然可以了,咱们将得到此仓储实例的法门放到一个集体的地方,改变的时候平昔改动那么些公共的地点就行了,
那么这里怎么弄呢?我们第一想到的最简便易行的就是简约工厂,那么什么样是简约工厂呢?其实很粗略,我们倘诺领悟只即使工厂,就是为大家创立实例的类,既然大家那里必要一个共用的地点,那么大家就要在LYZJ.UserLimitMVC.DAL这么些类库上面添加一个RepositoryFactory类,那几个类里面我们成立了一个UserInfoRepository属性,这几个静态属性之中就是为大家回去这一个蕴藏即可。那么此时假如大家想要修改的话就径直去改变UserInfoRepository属性即可

  (3) RepositoryFactory类的已毕

      (1)同大家地方的解析,下边大家完结那个类的代码,代码如下:

 1 namespace LYZJ.UserLimitMVC.DAL
 2 
 3 {
 4 
 5     public static class RepositoryFactory
 6 
 7     {
 8 
 9         public static IUserInfoRepository UserInfoRepository
10 
11         {
12 
13             get { return new UserInfoRepository(); }
14 
15         }
16 
17     }
18 
19 }

       
 (2)然后大家修改工作逻辑层的定义实例化仓储的代码如下:

      private IUserInfoRepository
_userInfoRepository = RepositoryFactory.UserInfoRepository;

   (3)那时候大家就形成了那个蕴藏的卷入,现在大家只要想要替换仓储的话,我们只必要去替换RepositoryFactory中的方法即可,这也就是一个粗略的粗略工厂,当大家添加上那么些简单工厂之后,我们数据库访问层和业务逻辑层之间的借助就尤其的滑坡了耦合度。

8.小结

  (1)到此处那篇博客终于不负众望了,现在自己才晓得针对着种类写博客真心倒霉写,语言社团尚未写技术点那么便民,导致自身那篇文章写了5个钟头,然则功夫不负有心人,终于不负众望了,比较我们看得时候会相比难懂,假设大家有怎么着不懂的可以问我,我将那篇博客的代码上传到CSDN中,我们可以去下载一边看代码一边看博客,我想那样大家简单领悟。

  (2)上面是明天写完那篇博客之后现在的项目架构

     图片 5

  (3) 看重接口编程图纸

     图片 6

源码下载

 

   (1):一体化源码下载

 

  Kencery重返本种类开篇

  

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图