3.Magicodes.NET框架之路——預覽（一）

3.Magicodes.NET框架之路——預覽（一）

• 前言

一眨眼，已經過去兩個多月了 ，哥已經火力全開了（業余時間和精力，甚至為此放棄了各種私活），所以大家不要抱怨慢哈。編程猶如逆水行舟，不進則退。這段時間，一方面是不斷地重構和設計框架，另一方面也系統的學習了很多新技術，同時也感受到了其強大的生命力。

所以這兩個多月，也感慨良多。兩個多月的業余時間和精力，兩個多月沒玩LOL和CF，兩個多月的全身心投入……

現在本篇就重點說說架構這些事：

1. 架構多次重構，甚至核心模塊多次推倒重來。
2. 架構已支持MVC，不過卻暫時放棄了WebForm，當然也有可能永久放棄WebForm，畢竟我目前只是一個人在戰斗，兼容兩套時間精力都極為有限。
3. 引入了T4，已支持基于T4模板的代碼生成。
4. 已支持SignalR。
5. 已支持asp.net Identity以及集成OAuth（Microsoft、QQ、Google…），暫時移除了對Form驗證的支持。
6. 支持WebAPI和Odata。
7. 前端框架初成，支持響應式布局以及MVVM模式和模塊化加載。
8. 其他

接下來，我一一簡單的介紹下本框架好了。

首先，先從前端開始介紹吧：

• 響應式布局的UI

后臺：

其他設備（為了用戶體驗，后臺框架使用了Iframe，在其他設備上訪問時，可能多少會有些問題）：

還有個列表頁面，但是更改為MVC后，還沒來得及改好。

前臺：

• 模塊化按需加載

前端JS寫了一部分，但是感覺還遠遠達不到完善的級別。很希望哪位前端工程師能夠給予支持，這樣我的重心就更好的放到后端架構上了。

在JS的選擇上，最終選擇了優秀的RequireJs，一直用下來，感覺比SeaJs更完善，更好用和更易用。

先看幾段Demo，比如登錄頁面：

Magicodes.js做了不少封裝，當然是為了最大限度的節省生產力。整個登錄機制就是以上腳本搞定，當然還與MVVM有關聯，這個是下面要介紹的。

Magicodes.js為目前的前端框架核心庫，當然目前還稱不上庫。其內部很多模塊也都是按需加載的，比如：

window.magicodes.messager = {

showMessage: function (title, message, className, funcs) {

var setting = {

title: title,

text: message,

class_name: className

};

if (typeof (funcs) !== "undefined") {

if (typeof (funcs.before_close) !== "undefined")

setting.before_close = funcs.before_close;

if (typeof (funcs.after_open) !== "undefined")

setting.after_open = funcs.after_open;

}

this._addGritter(setting);

},

showInfoMessage: function (title, message, funcs) {

this.showMessage(title, message, 'gritter-info gritter-light', funcs);

},

showErrorMessage: function (title, message, funcs) {

this.showMessage(title, message, 'gritter-error gritter-light', funcs);

},

showWarnMessage: function (title, message, funcs) {

this.showMessage(title, message, 'gritter-warning gritter-light', funcs);

},

removeAll: function () {

typeof ($.gritter) !== "undefined" && $.gritter.removeAll();

},

_addGritter: function (setting) {

require(["jquery", "jquery.gritter"], function () {

$.gritter.add(setting);

});

}

};

這個是彈出消息的，如：

這里就不多說了。

• MVVM

在MVVM框架的選擇上，最終選擇了knockoutjs。主要是夠輕量級，也夠靈活。用下來，感覺相當不錯。

比如登錄頁面：

登陸頁面這個比較簡單，重點是導航的綁定，馬上給大家秀一段。

按照傳統的方式來開發如下圖所示的功能，少不了遞歸綁定（支持多級），一堆的JS控制，一堆的業務代碼（其實開始我也是寫代碼的，后面才改為了MVVM模式，走彎路了，呵呵）

那么現在是怎么做到的呢？如下面代碼：

也就是我的綁定邏輯已經脫離了數據模型，前臺顯示我只需要改動這段代碼即可。是不是很強悍呢？

然后JS只要給到數據即可。后臺從WebAPI拿到如下JSON：

然后JS處理下，根據父子關系，生成children屬性（方便視圖綁定）：

//添加菜單子項

//源數據

//當前項

this._appendChildrenMenus = function (data, itemData) {

var childrenNavs = $.grep(data, function (i) {

return i.ParentId == itemData.Id;

});

if (childrenNavs.length > 0) {

itemData.children = childrenNavs;

$.each(childrenNavs, function (i, v) {

v._active = ko.observable(false);

v._open = ko.observable(false);

self._appendChildrenMenus(data, v);

});

}

};

核心代碼主要如下：

使用knockoutjs是不是很方便呢？其實knockoutjs很不錯，除了這些，knockoutjs可以干很多很便捷的事情，比如綁定分頁，綁定列表，綁定表單，這里只是做一些列舉，后面開貼細講，畢竟knockoutjs的實例還是比較少的。

這里再付一個分頁的模板：

<script id="pagesTemplate" type="text/html">

<li class="CSS: { disabled: $root.gridViewModel.currentPageIndex() <= 1 }, click: function () { $root.previousPage(); }">

<a href="#">

<i class="ace-icon fa fa-angle-double-left"></i>

</a>

</li>

<!-- ko foreach: $root.gridViewModel.pages -->

<li data-bind="css: { active: $data == $root.gridViewModel.currentPageIndex() }"><a href="#" data-bind=" text: $data, click: function () { $root.gridViewModel.currentPageIndex($data); } "></a></li>

<!-- /ko -->

<li class="next" data-bind="css: { disabled: $root.gridViewModel.currentPageIndex() >= $root.getTotalPages() }, click: function () { $root.nextPage(); }">

<a href="#">

<i class="ace-icon fa fa-angle-double-right"></i>

</a>

</li>

</script>

前端的先就介紹到這里吧，期待前端工程師的加入，讓我們一起來打造Magicodes前端框架。

現在，來說說后臺框架吧：

• 插件式架構

如下圖，這是目前的項目結構。

視圖頁、控制器、策略、數據模型、Service（含WebApi和Odata）均以插件存在。

在我這里，Service插件和傳統的層有很大區別。我這里的Service組件側重與WebApi和Odata提供的Web接口。

• MVC

目前已經移除了 對WebForm的支持，正所謂有了老婆忘了娘。嘿嘿。

注意：配置管理的所有配置視圖和控制器使用了T4模板自動生成。這個下面會介紹。

• ASP.NET Identity 和OAuth

Magicodes.NET支持?ASP.NET Identity以及OAuth協議，在不編寫一行代碼的情況下，您就可以便捷的集成QQ、Microsoft、Google、Facebook、Twitter等OAuth接口。

后面還會支持更多…

• WebAPI

曾經我也設計了一套WebAPI，目前已經移除了對此API的支持。改為基于微軟的WebAPI進行封裝。從一接觸WebAPI就喜歡上它了，毋庸置疑，她將來的成就會不可限量。這里簡單的介紹下:

比如剛才看到的站點信息配置頁面，其WebAPI如下：

這里很明顯的是一套基于REST協議標準的Web方法。WebAPI并不一定必須基于REST協議來設計哈，只是推薦而已。

Get、Post、Put，其實還有Delete（這里因為配置文件不能刪除），這是Rest協議標準的Web方法。一流公司制定標準，我們要抓緊抱佛腳。不要認為標準離我們很遠，你不去擁抱，人家能主動過來么？

先介紹下REST協議，代表性狀態傳輸（Representational State Transfer，REST）在 Web 領域已經得到了廣泛的接受，是基于 SOAP 和 Web 服務描述語言（Web Services Description Language，WSDL）的 Web 服務的更為簡單的替代方法。接口設計方面這一轉變的關鍵證據是主流 Web 2.0 服務提供者（包括 Yahoo、Google 和 Facebook）對 REST 的采用，這些提供者棄用或放棄了基于 SOAP 和 WSDL 的接口，而采用了更易于使用、面向資源的模型來公開其服務。

也順便多說點。REST 要求開發人員顯式地使用 HTTP 方法，并且使用方式與協議定義一致。這個基本 REST 設計原則建立了創建、讀取、更新和刪除（create, read, update, and delete，CRUD）操作與 HTTP 方法之間的一對一映射。根據此映射：

• 若要在服務器上創建資源，應該使用 POST 方法。
• 若要檢索某個資源，應該使用 GET 方法。
• 若要更改資源狀態或對其進行更新，應該使用 PUT 方法。
• 若要刪除某個資源，應該使用 DELETE 方法。

我前面為什么說WeAPI會爆發出強大的生命力？是因為之前的WebServices也好，還是SOAP等接口已經不滿足現有的使用場景了。很多時候，我們的接口內容得看什么終端輸出什么，就如見什么人說什么話一樣。看見Html調用，給他JSON就好了，C#、java客戶端調用，就給他返回xml讓他去玩好了，MongoDB也要玩，給他BSON就好了。還有不支持的？自己定義好了。總之，程序員們放心了，接口要支持新的平臺，我們啥都不需要干了。我們也不需要維護多套代碼了。這是多么Happy的事情呀。當然返回什么，是HTTP Accept Header決定的。

我們讓他返回JSON

他就乖乖的返回了JSON：