新定義三層，指揮官模式

1、概念

一、三層：

 

表示層及UI層： 主要是頁面顯示與控制操做

業務層：業務邏輯的處理

數據訪問層：封裝了對數據庫的增、刪、查和改操做。

 

爲何三層這麼好用

緣由是他的結構體系很是的清晰易懂，從功能與實現方面進行了層次劃分，實現了高內聚和低耦合。

咱們項目最經常使用結構體系就是在三層的基礎加上一個通用層（Common）、第三方接口或者工具層等，方便對一些公用的東西和特殊性的東西進行分類。

至今爲止這個結構體系依然是最好用的項目結構體系。

 

二、指揮官模式：

傳統的三層架構

傳統的三層架構是不容許跨層調用的 ，也就是說指揮官是UI層

缺點：

一、來回切換

指揮官只能指揮業務層並不能知道數據層在作什麼，這就意味着咱們在寫代碼的時候須要看2層才能看清晰這個功能具體作了些什麼，在編碼過程當中就須要頻繁的來回切換。

二、浪費

不少時候指揮官只須要直接傳達給數據層，如今只能強制傳達給業務層，而後在經過業務層轉達給數據層

三、寫好業務層有難度

爲何說寫好這個業務層有難度，也許是你們很疑惑的一件事情下面我就舉例子講解

現實案例：

不少人工做二三年都認爲業務層是多餘的不方便，不加又不合適，寫着寫着指揮官就直接調數據層了。

解答案例：

緣由是業務層受到了限制，UI層的全部東西不能使用，可是又要把非UI部分進行邏輯分離，在這種狀況下 業務層本能發揮100%實力，如今就只能發揮70%。

正是這種緣由好多的邏輯都寫在了指揮官層（UI層），業務層就是個空架子，只有指揮官層（UI層）東西太多時才交給業務層處理，有經驗的程序員纔可以真正的把UI層和業務層的東西劃分清楚，大大提升了分層難度。

 

指揮官重定義三層

指揮官模式是將權力所有掌控在自已手上，只作我能作和我想作的事情。

 

 

指揮官是用來把控全局的  技術活他作不了（數據訪問層），體力活他作不了（包外層）。

優勢：也就是解決了傳統三層的3個缺點

一、指揮官層就能看透一切，而且沒有冗餘代碼

二、減小沒必要要的開銷，指揮官能夠直接向數據層下達指令

三、分層更加清晰，指揮官層只作我想作的事情，不想作的事情直接外包，不能作的事情只能找數據層。

 

 

 

2、基於 ASP.NET MVC +IOC+ SqlSugar.ORM+語法糖.dll實踐指揮官模式

DEMO地址：

https://github.com/sunkaixuan/ASPNETMVCCRUDDEMO

一、建立項目：

新建MVC4項目,所有默認刪掉沒用的文件夾和文件

二、nuget引用dll:

咱們使用的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);
        }
    }

View Code

 

 

四、指揮官與指揮官的操做

指揮官層也至關於應用接口層，接口與接口之間的操做使用  RestSharp 。  

3、總結

指揮官模式是以業務爲核心的真正意義上的面向接口面向服務編程架構，適合多平臺應用。（傳統寫法都是表或者類去做爲服務一個業務可能會有多張表的操做，因此以表劃分的接口是不合理的）

一切從簡，沒有冗餘代，這個是我工做多年總結出的最偷懶寫法，但不能保證每一個人都喜歡，喜歡的就給個贊。

 

 

DEMO地址：

 

https://github.com/sunkaixuan/ASPNETMVCCRUDDEMO