3.Magicodes.NET框架之路——預(yù)覽（一）

3.Magicodes.NET框架之路——預(yù)覽（一）

• 前言

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

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

現(xiàn)在本篇就重點說說架構(gòu)這些事：

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

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

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

• 響應(yīng)式布局的UI

后臺：

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

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

前臺：

• 模塊化按需加載

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

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

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

Magicodes.js做了不少封裝，當(dāng)然是為了最大限度的節(jié)省生產(chǎn)力。整個登錄機制就是以上腳本搞定，當(dāng)然還與MVVM有關(guān)聯(lián)，這個是下面要介紹的。

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

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。主要是夠輕量級，也夠靈活。用下來，感覺相當(dāng)不錯。

比如登錄頁面：

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

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

那么現(xiàn)在是怎么做到的呢？如下面代碼：

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

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

然后JS處理下，根據(jù)父子關(guān)系，生成children屬性（方便視圖綁定）：

//添加菜單子項

//源數(shù)據(jù)

//當(dāng)前項

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可以干很多很便捷的事情，比如綁定分頁，綁定列表，綁定表單，這里只是做一些列舉，后面開貼細(xì)講，畢竟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前端框架。

現(xiàn)在，來說說后臺框架吧：

• 插件式架構(gòu)

如下圖，這是目前的項目結(jié)構(gòu)。

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

在我這里，Service插件和傳統(tǒng)的層有很大區(qū)別。我這里的Service組件側(cè)重與WebApi和Odata提供的Web接口。

• MVC

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

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

• ASP.NET Identity 和OAuth

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

后面還會支持更多…

• WebAPI

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

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

這里很明顯的是一套基于REST協(xié)議標(biāo)準(zhǔn)的Web方法。WebAPI并不一定必須基于REST協(xié)議來設(shè)計哈，只是推薦而已。

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

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

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

• 若要在服務(wù)器上創(chuàng)建資源，應(yīng)該使用 POST 方法。
• 若要檢索某個資源，應(yīng)該使用 GET 方法。
• 若要更改資源狀態(tài)或?qū)ζ溥M(jìn)行更新，應(yīng)該使用 PUT 方法。
• 若要刪除某個資源，應(yīng)該使用 DELETE 方法。

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

我們讓他返回JSON

他就乖乖的返回了JSON：