最近花了幾個夜晚幫師妹整了一個企業網站

背景：

話說年前有個師妹淚眼汪汪，楚楚動情地找我幫她弄個企業網站。

不過那時候，天天都苦B地閃着：「加班中，相信不用多久升職加薪,當上總經理,出任CEO,迎娶白富美,走上人生巔峯，想一想還有點小激動呢」。

因此每夜都懶懶地累到不想動，一直拖延到年後，回到廣州才動有了寫代碼的衝動。

想一想畢竟是自家師妹，承諾過的仍是要還的，因此打算認真負責的花些時間把它整出來。

 

技術選型：

1：時間考量： 

首先這是一個義務型的網站，因此會考慮時間不能佔用太多， 儘可能知足基礎功能，比較異想天開的功能先忽略。

總體先後溝通和小調整，歷長1-2周，實際編碼時間，大概24小時內，換算起時間，那也是三個工做日，六個夜晚啊。

2：技術選型：MVC仍是WebForm：

A：時間不能佔用過多，開發週期不能拉長。

B：我的能臨時提供的服務器是2003，只有.NET 2.0，後期可能會轉移到對方購買的虛擬主機，因此部署要方便。

C：友好的URL並非對方在意的。 

因此綜合考慮：WebForm。

像MVC，它的優勢是：提供簡單友好的URL，對外是一個好的唬頭，MVC架構分層思想對新手是一種引導。 

3：數據庫選型：MSSQL？Access？Sqlite？

用MSSQL，在這種簡單的企業站裏，大財小用了。

Access：擁有最弱的併發限制，64K，這個在我之前QBlog系列文章裏，把它優化上天了，後來仍是離開了。

Sqlite：這個須要最高的信任權限，某些虛擬主機商可能會不支持，並且併發能力和Access差很少一個級別。

 

以我多年的實戰經歷，這裏我選擇文本數據庫，這裏有幾個重要思考因素。

1：數據量少：少到能夠預估的時間內，文章不會超過1千。

2：佔用資源少：目前VPS就1G內存，數據庫勉強跑上了sql2000，並且服務器上跑了好幾個項目，不適合把這外部的數據放置到本身的項目中。

3：性能要高，抗併發要強：服務器自己配置很低，若是不能抗併發，隨便用我提供的分佈式壓力測試就能搞掉的話，那不坑我本身的服務器。

4：數據的安全性隱私木有要求：這些數據都是可公開的。

綜合上面的考慮，MSSQL，雖然能抗併發，這個吃內存，不行，而Access和Sqlite不抗併發，若是選擇了它們，意味着我必須考慮到整個緩存機制或生成靜態頁面機制，這無疑會加長個人開發時間。

 

好在我發現了文本數據庫：恰好知足以上的條件，並且文本數據庫一直在應用，基本上這個企業站也不在話下，因此最後是用上了CodeFirst方式的文本數據庫。

而選擇文本數據庫，經壓力測試，幾千上萬個併發也不是問題，它自然的內存數據庫機制自己就是緩存機制，一次開發，就能夠收工了。

實戰開發：

1：美工的界面來源： 

首先，她不是美工，我也不會美工，因此，網站須要有參考，好在她給了一款參考網站。

因此，以個人經驗，把對方網站那點皮膚弄下來不是什麼問題，因此美工的問題看似就解決了，具體看一眼下圖，發現是很清秀簡潔的：

 2：代碼編寫：

因爲數據庫選項是文本數據庫，因此基本上就是CodeFirst，定義好業務實體，什麼分層，在這裏就是浮雲：

 

Web.Config就這麼一行了：

< connectionStrings >
         < add  name ="Conn"  connectionString ="txt path={0}App_Data\db;ts=0" />
     </ connectionStrings >

 

具體運行後產生的數據存儲，就在App_Data下的db文件夾下了，一個表就對應一個文本數據了。

另外考慮到文章的字節大，就單獨隔離出來一個body文件夾來存放文章，代碼也很簡單：

public  class ArticleBody
    {
         public  static  void Set( int id,  string body)
        {
             string path = AppDomain.CurrentDomain.BaseDirectory +  " /App_Data/db/body/ " + id +  " .body ";
            File.WriteAllText(path, body);
        }
         public  static  string Get( int id)
        {
             string path = AppDomain.CurrentDomain.BaseDirectory +  " /App_Data/db/body/ " + id +  " .body ";
             if (File.Exists(path))
            {
                 return File.ReadAllText(path);
            }
             return  string.Empty;
        }
    }

 

紅色那一塊是後臺，因爲偷工減料，因此就不方便公開名稱。

3：技術點須要思考的地方：

整個網站，基本上都是簡單相似如下的代碼：

public  partial  class ArticleCate : System.Web.UI.UserControl

    {
         protected  void Page_Load( object sender, EventArgs e)
        {
             if (!IsPostBack)
            {
                BindList();
            }
        }
         void BindList()
        {
             using (ArticleClass a =  new ArticleClass())
            {
                a.Select( " order by orderNum asc ").Bind(rptList);
            }
        }
    }

不過也有一些須要費點腦的：

3.1：左側的分類列表，有的點擊是直接進入到文章詳細，有的點擊是直接進入列表界面：

面對這個問題，有着最開始的設計思惟：

A：分類名稱難道是文章的名稱（由於見過的不少基本上都是同名） ？

B：那麼要區分顯示在列表仍是單獨的，要在文章里加個字段以區別？

中間的過渡思惟：

A：分類名稱就是分類名稱？

B：分類名稱上加個字段，以區別點擊是進入指定的某個文章？

最後的決定性思惟：

A：分類名稱仍是分類名稱。

B：當分類名稱只有一條文章時，地址變爲直接指向那篇文章。

 

3.2：文本編輯器的引入：

一開始我是很偷懶的，用一個文本框來發文章，就想了理了。

後來想一想不能懶到這程度，畢竟人家是師妹啊，況且我還單身，因此引入文本編輯器升級一下檔次也是有必要的。

網上可選的編輯種類不少，FCK,King等網上一搜一個堆，不過我仍是思考了一下，若是用上這些：

第一，重，隨便一個都幾M起步；

第二，圖片上傳須要本身再折騰，若是運氣很差，研究+實現可能會花上一天時間。

第三：我太懶了，我想最多1小時之內就把它給換完。

 

我想到之前QBlog裏我寫過一個編輯器（改來的），因而直接弄過來，發現原來的代碼和QBlog的開發模式有點結合。 

花了幾分鐘，改了點代碼，基本上就能用了，並且重點是文件上傳，基本上小改幾分鐘也適合着用了，省了很多時間。

 

 

3.3 產品中心lightBox.js的引入：

這一塊就沒什麼好說的了，就是那種一點圖片出來一遮照層，整個背景黑的那種，06年就開始流行的，沒想到如今還用的上。 

關於後臺：

對於後臺，一開始打算用QBlog那種後臺方式，或者像EasyUI那種前端，而後搞個CodeSmith批量生成同樣，不過一想到這CS不知道放哪了，光找出來就要很多時間，再說它也不支持個人文本數據庫。

雖然CodeFirst也支持多種數據庫，改個數據庫連接就能夠轉移到其它數據庫，而後再借CS去生成，不過感受這轉來轉去的麻煩。 

因而，心一橫，就那幾個表，也就幾個界面，還不如手工來的快，因而一個木有樣式，慘不忍睹的界面，只有最簡單的增刪改查邏輯的後臺就出來了。

因爲後臺界面這一塊太醜，就不截圖了，免的亮瞎了大夥的眼睛。

 

網站預覽：http://paileju.com
至於源碼，想要來學習的也能夠Q我，隨便給。

總結：

到此，基本上就算完工了，搞完以後，收到了師妹寄來的零食，也算是一種回報了，雖然大部分零售是辣的不合我口味，不過仍是有很多零售味道仍是不錯的，像那個1塊錢1個的肉鬆餅就很好吃，但是，爲啥只買了一個，納尼？

 

新的一年，要從新賣身了，打算漂泊，城市不限，歡迎大夥推薦買主，謝謝。

from:http://www.cnblogs.com/cyq1162/p/3573726.html