表示层及UI层: 主要是页面显示与控制操做git
业务层:业务逻辑的处理程序员
数据访问层:封装了对数据库的增、删、查和改操做。github
为何三层这么好用数据库
缘由是他的结构体系很是的清晰易懂,从功能与实现方面进行了层次划分,实现了高内聚和低耦合。编程
咱们项目最经常使用结构体系就是在三层的基础加上一个通用层(Common)、第三方接口或者工具层等,方便对一些公用的东西和特殊性的东西进行分类。架构
至今为止这个结构体系依然是最好用的项目结构体系。框架
传统的三层架构ide
传统的三层架构是不容许跨层调用的 ,也就是说指挥官是UI层函数
缺点:工具
一、来回切换
指挥官只能指挥业务层并不能知道数据层在作什么,这就意味着咱们在写代码的时候须要看2层才能看清晰这个功能具体作了些什么,在编码过程当中就须要频繁的来回切换。
二、浪费
不少时候指挥官只须要直接传达给数据层,如今只能强制传达给业务层,而后在经过业务层转达给数据层
三、写好业务层有难度
为何说写好这个业务层有难度,也许是你们很疑惑的一件事情下面我就举例子讲解
现实案例:
不少人工做二三年都认为业务层是多余的不方便,不加又不合适,写着写着指挥官就直接调数据层了。
解答案例:
缘由是业务层受到了限制,UI层的全部东西不能使用,可是又要把非UI部分进行逻辑分离,在这种状况下 业务层本能发挥100%实力,如今就只能发挥70%。
正是这种缘由好多的逻辑都写在了指挥官层(UI层),业务层就是个空架子,只有指挥官层(UI层)东西太多时才交给业务层处理,有经验的程序员才可以真正的把UI层和业务层的东西划分清楚,大大提升了分层难度。
指挥官重定义三层
指挥官模式是将权力所有掌控在自已手上,只作我能作和我想作的事情。
指挥官是用来把控全局的 技术活他作不了(数据访问层),体力活他作不了(包外层)。
优势:也就是解决了传统三层的3个缺点
一、指挥官层就能看透一切,而且没有冗余代码
二、减小没必要要的开销,指挥官能够直接向数据层下达指令
三、分层更加清晰,指挥官层只作我想作的事情,不想作的事情直接外包,不能作的事情只能找数据层。
DEMO地址:
https://github.com/sunkaixuan/ASPNETMVCCRUDDEMO
新建MVC4项目,所有默认删掉没用的文件夹和文件
咱们使用的ORM为SqlSugar,语法糖框架 SyntacticSugar.dll 主要封装了一些经常使用函数
每一个控制器都用一个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); } }
指挥官层也至关于应用接口层,接口与接口之间的操做使用 RestSharp 。
指挥官模式是以业务为核心的真正意义上的面向接口面向服务编程架构,适合多平台应用。(传统写法都是表或者类去做为服务一个业务可能会有多张表的操做,因此以表划分的接口是不合理的)
一切从简,没有冗余代,这个是我工做多年总结出的最偷懒写法,但不能保证每一个人都喜欢,喜欢的就给个赞。
DEMO地址: