技術介紹

Layui

個人而言不喜歡引用一堆東西，越簡潔越好，layui正好能夠滿足我的這種需求，它是一款輕量級UI，JS部分都是采用模塊化設計（AMD），對移動端支持比較不錯。

唯一不足是目前支持的組件有些少，需要有一定前端擴展能力的人才可以順心使用。

用法：

例如我想用form.js和uploda.js我只需要寫use(form,upload)（如下例代碼所示），而不是引用兩個JS文件

/* Demo1.js 使用Layui的form和upload組件 */ layui.use(['form', 'upload'], function(){ //如果只加載一個組件，可以不填數組。如：layui.use('form') var form = layui.form() //獲取form組件 ,upload = layui.uplaod; //獲取upload組件 //監聽提交按鈕  });

SqlSugar

一款高性能輕量級並且功能強大的ORM框架，支持多種數據庫，支持.NET CORE 。MySql版支持了讀寫分離，SQL版支持了並行計算。

Asp.net 4.+	Asp.net Core	說明	依賴
SqlSugar.dll	SqlSugarCore.dll	SqlServer ORM	無
MysqlSugar.dll	MysqlSugarCore.dll	MySql ORM	MySql.Data.dll
SqliteSugar.dll	SqliteSugarCore.dll	Sqlite ORM	System.Data.SQLite.dll SQLite.Interop.dll（Core版不需要）
OracleSugar.dll	-	Oracle ORM	Oracle.ManagedDataAccess.dll
SqlSugarRepository.dll	-	SqlServer MySql Sqlite Oracle 四合一	MySql.Data.dll System.Data.SQLite.dll Oracle.ManagedDataAccess.dll SQLite.Interop.dll

RestSharp

在我項目中作用與WCF相近，面向服務編程的一個核心要素，相比WCF更為簡單更為輕量，只支持HTTP協議

var client = new RestClient("http://localhost/home/getjson"); // client.Authenticator = new HttpBasicAuthenticator(username, password); var request = new RestRequest("resource/{id}", Method.POST); request.AddParameter("name", "value"); // 添加請求參數 request.AddUrlSegment("id", "123"); // 添加 token //添加HTTP頭 request.AddHeader("header", "value"); // 添加文件 request.AddFile(path); // 執行請求 IRestResponse response = client.Execute(request); var content = response.Content; // 返回請求對象 // or automatically deserialize result // return content type is sniffed but can be explicitly set via RestClient.AddHandler(); RestResponse<Person> response2 = client.Execute<Person>(request); var name = response2.Data.Name; //異步支持 client.ExecuteAsync(request, response => { Console.WriteLine(response.Content); }); var asyncHandle = client.ExecuteAsync<Person>(request, response => { Console.WriteLine(response.Data.Name); }); asyncHandle.Abort();

采用的設計思想

從古至今設計模式都是越復雜的大家越喜歡學，哪怕是學了完全都看不懂是個什么東西，就認為這技術高明，可能寫的人自個都沒明白，而相反代碼寫的越多的人越想寫的簡單。

模式這種東西就沒有好壞之分：

不同人用不同的模式發揮出來的水平也不一樣

我的領悟

嵌套邏輯不能超過3層，如果不符合這個約束在美的寫法都要讓步

1.冗余代碼只要好維護也是可以接受的，復制粘貼一把凌，因為簡單的邏輯而導致了代碼的冗余，如果要做的不冗余那寫法就要復雜的多，根據情況不同利弊自已選擇，魚和熊掌很多時候是不能兼得的。

2.一定要以業務為核心分層

3.易讀的代碼和改動少的寫法有沖突的時候我會采用易讀寫法（別人都看不懂，還談什么可維護性，自已做那是無所謂）

代碼講解

代碼結構圖：

我稱這種模式為：指揮官模式

稱詞解釋：

ViewAction ：類型為 ActionResult類型的Action

ApiAction： 類型為JsonResult類型的Action,在這里作為一個業務接口使用

Pack： 為一個業務塊，並且業務塊和業務塊之間是隔離的，每個業務塊有多個 ApiAction 和多個ViewAction，

業務塊與業務塊之間的通信用的是RestSharp調用其它Pack的

Outsourcing：業務塊中的一些公用代碼，可以是一個類也可以是一個文件夾，根據項目復雜度而定

這種架構模式和傳統三層比起來有3大優勢

1.分層容易並且代碼更清晰

以前寫法是以數據表作為服務，如果是SOA架構還要在抽象一層，當然一個復雜業務會有十張以上的表處理，便會出現這種垃機代碼有幾張表會出現幾個Service

        private x1 X1Service; private x2 X2Service; private X3 X3Service; public DocContentController(x1 X1Service, x3 X1Service, x4X1Service) { this.X1Service = X1Service; this.X2Service = X2Service; this.X3Service = X4Service; }

現在寫法,直接獲取一個處理完的業務接口便可以，而不是獲取每個細的表服務。

_service.Command<HomeOutsourcing, ResultModel<DocResult>>((o, api) =>
{
                var DocLIST= api.Get(Url.Action("GetDoc"), new { typeId = typeId }); });

2.可以一套代碼多平台使用

因為都是基於ApiAction如果權限合理完全可以當移動端接口，無形中已經是SOA架構。

3.層次簡單

簡單到比三層更精簡