新定义三层,指挥官模式
一、概念
1、三层:
表示层及UI层: 主要是页面显示与控制操作
业务层:业务逻辑的处理
数据访问层:封装了对数据库的增、删、查和改操作。
为什么三层这么好用
原因是他的结构体系非常的清晰易懂,从功能与实现方面进行了层次划分,实现了高内聚和低耦合。
我们项目最常用结构体系就是在三层的基础加上一个通用层(Common)、第三方接口或者工具层等,方便对一些公用的东西和特殊性的东西进行分类。
至今为止这个结构体系依然是最好用的项目结构体系。
2、指挥官模式:
传统的三层架构
传统的三层架构是不允许跨层调用的 ,也就是说指挥官是UI层
缺点:
1、来回切换
指挥官只能指挥业务层并不能知道数据层在做什么,这就意味着我们在写代码的时候需要看2层才能看清晰这个功能具体做了些什么,在编码过程中就需要频繁的来回切换。
2、浪费
很多时候指挥官只需要直接传达给数据层,现在只能强制传达给业务层,然后在通过业务层转达给数据层
3、写好业务层有难度
为什么说写好这个业务层有难度,也许是大家很疑惑的一件事情下面我就举例子讲解
现实案例:
很多人工作二三年都认为业务层是多余的不方便,不加又不合适,写着写着指挥官就直接调数据层了。
解答案例:
原因是业务层受到了限制,UI层的所有东西不能使用,但是又要把非UI部分进行逻辑分离,在这种情况下 业务层本能发挥100%实力,现在就只能发挥70%。
正是这种原因好多的逻辑都写在了指挥官层(UI层),业务层就是个空架子,只有指挥官层(UI层)东西太多时才交给业务层处理,有经验的程序员才能够真正的把UI层和业务层的东西划分清楚,大大提高了分层难度。
指挥官重定义三层
指挥官模式是将权力全部掌控在自已手上,只做我能做和我想做的事情。
指挥官是用来把控全局的 技术活他做不了(数据访问层),体力活他做不了(包外层)。
优点:也就是解决了传统三层的3个缺点
1、指挥官层就能看透一切,并且没有冗余代码
2、减少不必要的开销,指挥官可以直接向数据层下达指令
3、分层更加清晰,指挥官层只做我想做的事情,不想做的事情直接外包,不能做的事情只能找数据层。
二、基于 ASP.NET MVC +IOC+ SqlSugar.ORM+语法糖.dll实践指挥官模式
DEMO地址:
https://github.com/sunkaixuan/ASPNETMVCCRUDDEMO
1、创建项目:
新建MVC4项目,全部默认删掉没用的文件夹和文件
2、nuget引用dll:
我们使用的ORM为SqlSugar,语法糖框架 SyntacticSugar.dll 主要封装了一些常用函数
3、目录结构
每个控制器都用一个pack文件夹包着 例如homeController为指挥官层,homeController里面不想处理的事情都交给Outsourcing文件,
控制器不能处理的事情通过一个DbService.Command把 DAO层打通
从上图可以看出DAO层已经精简到只有三个文件,是的只要这三个文件及可。
如果需要一些通用数据服务可以对DB对象进行一层封装
控制器代码:
public class ListController : Controller { private DbService _service; public ListController(DbService service) { _service = service; } public ActionResult Index(string title, int pageIndex = 1, int pageSize = 5) { var model = new ResultModel<string, List<dnt_test_topics>, HtmlString, List<dnt_test_forums>>(); _service.Command<Outsourcing>((db, o) => { model.ResultInfo = "增删查改"; var queryable = o.GetQueryable(title);//处理查询逻辑 queryable.DB = db;//设置连接对象 int pageCount = queryable.Count(); model.ResultInfo2 = queryable.ToPageList(pageIndex, pageSize); model.ResultInfo3 = o.GetPageString(pageIndex, pageSize, pageCount);//获取分页字符串 model.ResultInfo4 = db.Queryable<dnt_test_forums>().ToList();//编辑用到的分类下拉列表 }); return View(model); } public JsonResult Delete(int id) { ResultModel<dynamic> model = new ResultModel<dynamic>(); _service.Command<Outsourcing>((db, o) => { model.IsSuccess = model.ResultInfo = db.Delete<dnt_test_topics, int>(id); //减少了2个类的冗余代码,这就是和传统三层最大区别 }); return Json(model, JsonRequestBehavior.AllowGet); } public JsonResult GetById(int id) { ResultModel<dynamic> model = new ResultModel<dynamic>(); _service.Command<Outsourcing>((db, o) => { model.ResultInfo = db.Queryable<dnt_test_topics>().Single(it => it.tid == id); model.IsSuccess = true; }); return Json(model, JsonRequestBehavior.AllowGet); } public JsonResult Insert(dnt_test_topics obj) { ResultModel<dynamic> model = new ResultModel<dynamic>(); _service.Command<Outsourcing>((db, o) => { obj.postdatetime = DateTime.Now; obj.lastpost = DateTime.Now; obj.lastposter=obj.poster = "管理员"; model.ResultInfo = db.Insert(obj); model.IsSuccess = true; }); return Json(model, JsonRequestBehavior.AllowGet); } public JsonResult Update(dnt_test_topics obj) { ResultModel<dynamic> model = new ResultModel<dynamic>(); _service.Command<Outsourcing>((db, o) => { model.IsSuccess = model.ResultInfo = db.Update<dnt_test_topics>( new { title = obj.title, fid = obj.fid } , it => it.tid == obj.tid); }); return Json(model, JsonRequestBehavior.AllowGet); } }
4、指挥官与指挥官的操作
指挥官层也相当于应用接口层,接口与接口之间的操作使用 RestSharp 。
三、总结
指挥官模式是以业务为核心的真正意义上的面向接口面向服务编程架构,适合多平台应用。(传统写法都是表或者类去作为服务一个业务可能会有多张表的操作,所以以表划分的接口是不合理的)
一切从简,没有冗余代,这个是我工作多年总结出的最偷懒写法,但不能保证每个人都喜欢,喜欢的就给个赞。
DEMO地址:
https://github.com/sunkaixuan/ASPNETMVCCRUDDEMO