啊,终于到写三层架构的时候了,老实说,我都不知道自己这个算不算三层架构,姑且就当它是吧,具体属于哪一个体系,希望有大佬指点一下 (^o^)/
不晓得有人注意到没有,我写了三篇博客,然后就改了三次标题ヽ ( ̄▽ ̄)ノ,
从最开始的 Core 建数据库 ,到 Core 数据库操作 ,再到现在的 Core 建站,也算是下决心写个系列啊,,感觉要更好久的样子,,
好吧,不要在意那些细节,文中可能会有一些我不知道的坑,毕竟自己也是一边自学一边写,不过保证功能还是能用的,发现有坑记得说,,我改,,(〃'▽'〃)
// ===================emmm,我是分割线 ===================
强烈推荐阅读: 设计模式六大原则 讲的相当浅显易懂,,
首先上一个截图,看看现在的项目结构,今天的主角是 DataBase 文件里面的那一堆项目啊,BLL,DAL 和 Interface,,Models 是生成数据库时使用的,所以今天用不上,,
按我的理解,先说说正常的三层架构吧,
UI:界面层,这个层最简单,只是给 BLL 传递数据,然后,将 BLL 返回的数据进行一些处理,方便展示,
BLL:业务逻辑层,接收 UI 层给的数据,写一些业务逻辑,第一步干啥,第二步干啥,什么什么的,然后把界面需要的数据返回出去,感觉更像是一个 API
DAL:数据访问层,BLL 的业务逻辑处理时,总要涉及到数据库的操作,这时候就要用到 DAL 层了,,
还有一个 Model 层,用来传递数据的,,不在三层范畴,,,
不知道大家是怎么使用三层的,给大家展示一下以前学校教我们怎么用的三层架构啊,,
分别对应三个类,UI 层:HomeController,BLL 层:DT_UserBLL,DAL 层:DT_UserDAL
- // UI层
- public IActionResult Index(int userID)
- {
- // 根据条件,返回用户
- // 和BLL说,给你一堆条件,帮我把这些人找出来
- var userList = DT_UserBLL.GetUser(0,18);
- return View(userList);
- }
- /// <summary>
- /// BLL层,返回符合条件的用户
- /// </summary>
- /// <param name="sex">性别</param>
- /// <param name="age">年龄</param>
- /// <returns></returns>
- public List < DT_User > GetUser(int sex, int age) {
- #region数据校验
- // 性别检测,0:女,1:男
- if (sex != 0 && sex != 1)
- // 拒绝人妖
- return null;
- // 年龄检测,[0,150]岁
- if (age < 0 || 150 < age)
- // 拒绝妖怪
- return null;
- #endregion
- // 和DAL说,数据我校验好了,不是恶搞,
- // 帮我查出来这些人,然后我交给UI就完事儿了,,
- return DT_UserDAL.GetUser(int sex, int age).ToList();
- }
- /// <summary>
- /// DAL层,返回符合条件的用户
- /// </summary>
- /// <param name="sex">性别</param>
- /// <param name="age">年龄</param>
- /// <returns></returns>
- public IQueryable < DT_User > GetUser(int sex, int age) {
- DbContext DB = new DbContext();
- return DB.Set < DT_User > ().Where(c = >c.Sex == sex && c.Age == age);
- }
当时学着感觉蛮好的,挺新奇的一个编程思想,不过每一个数据表对应的 DAL 里面都得写一套增删查改,,简直是灾难,,[○・`Д´・ ○]
出来实习之后,花了个把星期,把我们老大写的一个框架看明白了,就按图索骥地写了起来,嘿嘿
其实和三层架构差不多的,只是把每个数据表对应的 DAL 里面的增删查改全部提出来,封装成了一个类,,
然后对这个类进行继承,具体操作如下,,,
首先啊,要大概了解一下依赖注入,,讲真,这个我也是一脸懵逼,所以就不复制百度百科了,,
说说自己的理解吧,,,,emmm,此处可能有大量谬论,建议不要被我误导了,看看就好,别往心里去
依赖注入这东西就好像一个全局的字典类型变量,,都是以键值对的方式存储的
因为注册依赖注入服务的大部分语法是酱紫的,,,
- 1 services.AddTransient(typeof(IDT_UserService), typeof(DT_UserService));
而 services 这个变量的话,就像一个容器,用来存储这些键值对的,具体从哪来的,我也不知道,ヽ ( ̄д ̄;) ノ
而要使用的话,语法是酱紫的,,,
- public class HomeController : Controller
- {
- private IDT_UserService _UserService;
- public HomeController(IDT_UserService _UserService)
- {
- // 依赖注入得到实例
- this._UserService = _UserService;
- }
- public IActionResult Index()
- {
- ViewBag.list = _UserService.LoadEntites(c => true);
- return View();
- }
- }
对的,完全不需要 new,,其原理,,起码我不晓得,感觉甚是神奇,,
先注册一个依赖注入的服务,然后要实例的时候,直接在构造函数里面把键的类型写上就好,,
好了,灌毒就到此为止了,,还是继续上代码吧,,
首先,得写一个数据库操作的底层类 DalService 又因为很多地方调用,所以,肯定是泛型,,
然后为了解耦和方便注入,所以实现一个接口 IDalService,
我暂时只写了添加和查询的方法,,其他的方法可以自由发挥,,不过记得先写接口,然后去实现接口中新加的方法,,不然无法使用的,,
IDalService
DalService
然后就没有 DAL 层啥事了,,咱们去看 BLL 层
同样的写一个业务逻辑的父级类 BllService,依旧是泛型,以及实现接口 IBllService
IBllService
BllService
然后基本就完成了,,我们可以在 BLL 层创建一个 DT_User 的逻辑处理类,继承 BllService,并实现接口 IDT_UserService
IDT_UserService
DT_UserService
最后使用的话,要把他们统统注册到服务里面,新建一个类 DIBllRegister,用来注册这些和数据库相关的服务
DIBllRegister
在 Startup 的 ConfigureServices 方法中添加两行代码
- /// <summary>
- /// 运行时调用此方法。使用此方法向容器添加服务。
- /// </summary>
- /// <param name="services"></param>
- public void ConfigureServices(IServiceCollection services) {
- services.AddOptions();
- // 数据库连接字符串
- var conStr = Config.GetVal < string > (ConfigKey.ConStr);
- services.AddDbContext < DBCodeFirst > (options = >options.UseSqlServer(conStr));
- DIBllRegister bllRegister = new DIBllRegister();
- bllRegister.DIRegister(services);
- services.AddMvc();
- }
然后我们就可以愉快的使用三层架构来写项目了,,ヽ (≧∀≦)ノ
示例以及项目结构如下:
运行结果:
其实这个是我从 Framework 搬过来的,心塞得简直不要不要的,,,填坑日记就不写出来了,,
具体的搭建思想也不太好用文字表述,大佬不要吐槽,萌新可以照着步骤去建一个小项目调试着看,,
个人感觉还是比较好懂的,,毕竟,基本上全是核心代码还带注释,加一个使用样例,
然后就是下集预告了,云服务器的 FTP 发布和数据库连接吧,,毕竟云服务器到手辣么久了,也该拉出来溜溜,,(❁´◡`❁)*✲゚*
最后,,有坑记得说,,,,
来源: https://www.cnblogs.com/Onlooker/p/8231522.html