G 開源的分布式部署解決方案（二）

【g】開源的分布式部署解決方案 - 預告篇

【g】開源的分布式部署解決方案（一） - 開篇

【g】開源的分布式部署解決方案（二） - 好專案是從爛專案基礎上重構出來的

眼前出現這麼一坨坨的資料夾，相信很多人已經看不下去了。是的，首先就是要把它給做掉。

按照這個專案資料夾的命名意圖，大概可以劃分如下：

1.business：業務**

2.data：資料訪問

3.helpers：輔助類（通用類庫之類的）

4.models：各種模型（包括檢視模型）

6.controller、views、db：這些就先不動他了。

首先整理出4個解決方案資料夾（注：解決方案資料夾是個虛擬的結構，並非真實的物理資料夾，雖然原始碼存放位置也缺失按照目前分層做的，但這個概念要分開），分別是 business、model、data、infrastructure，將業務、模型、資料、基礎設施給分拆出來。

其中business、model兩個資料夾主要與業務相關，這兩個資料夾會根據功能模組建立對應的專案，比如 deploymanage、usermanage等。像部署下的一些小的概念，如部署伺服器、部署伺服器組、部署專案等這些只需要在對應專案下建立1級資料夾區分開即可。

最後的infrastructure則把一些公共的類放到了這裡。

可能有人不禁要問一下，就這麼簡單？這就是最終專案結構了嗎？

當然不是，重構即是乙個動作，也是乙個過程。後面會根據專案發展不斷的進行重構。

首先遇到的問題則是它，authenticationdescription，按照已有的命名空間引用，正常推論是只要引用 microsoft.owin.security.dll 就可以了。但事實證明不行。

為了知道到底是什麼原因，我又把這個類放回原來的位置，f12跟蹤進去一看，嘿，原來是個李鬼裝李逵。

最終通過新增了microsoft.owin.dll 解決，這個類其實跟microsoft.owin.security.dll沒關係的。真真是被戲耍了一番。

大家可能比較喜歡使用vs自帶的這個小燈泡，是的它很方便，但它不是萬能的。如果你按照這裡的選項來做你有2個選擇，要麼新建乙個類自己實現，要麼引用 system.runtime.remoting.context

雖然通過上面的辦法我們也能找到最終是誰做的好事，但這個時候經驗出現了，我一眼就看出來這是ef幫忙擴充套件了的（畢竟踩的坑多）。它做了好事兒，但它還沒留下自己的名字，只告訴我它是個無名氏。當初第一次踩這個坑也是通過第乙個方法解決的，性質跟是一樣的，但這裡想告訴大家，積累也很重要。

當處理到business的時候，發現它終於可以給乙個正確的提示了，這就好像a是b的老婆，b是c的同事，c認識b自然問b就知道a是誰了。

把引用關係都改好了，過程中修改名字也都使用了大家喜歡的小燈泡同時更改所有的引用，為什麼還會出現這個問題？難道view你就不管了嗎？她不是你生的？

就是這個潑出去的水，你生的還要我來擦屁股。這裡僅僅只是吐槽罷了。

看到了這個頁面我長舒了一口氣，終於是不報錯了。

再來看下 g.client.ui.admin 好像是順眼多了。

但這就改完了嗎？這只是個開始而已，後面的路還長呢。

好好的乙個業務層**，引用了ef，著實是不爽。不僅如此，model裡也引用了system.web來獲取userid。

作為乙個有道德的人，別人臉上長了青春痘，你應該拿個揚聲器對著他喊：喂，你臉上有青春痘，好大一顆，好難看！

同樣的，system.web的也通過infrastructure裡提供就好了。從此再也不擔心青春痘亂長了。

作為乙個懶人，第乙個要解決的肯定是解放雙手。

後面對資料庫操作的還有好多地方，到處都要這樣賦值真的是心疼自己細白嫩長的五指。

嘖嘖嘖，瞬間又順眼了好多，整個人都好了。

最後最後，本專案暫定名為 g，唯一群號：7424099