錄

摘 要 1

第一章 緒論 2

1.1研究背景 2

1.2研究意義 2

1.3國內外文獻綜述 2

1.3.1國外文獻綜述 2

1.3.2國內文獻綜述 3

第2章 汽車之家門戶網站的需求分析 4

2.1系統的可行性分析 4

2.1.1系統的經濟可行性 4

2.1.2系統的技術可行性 4

2.1.3系統的操作可行性 4

2.2系統的目標分析 5

2.3系統的功能需求分析 5

2.3.1游客用例分析 6

2.3.2會員用例分析 7

2.3.3管理員用例分析 8

2.4系統數據庫分析 9

第3章 汽車之家門戶網站的設計 10

3.1系統功能模塊的劃分 10

3.2系統數據流圖 10

3.3系統數據庫設計 12

第4章汽車之家門戶網站的實現 15

4.1系統實現的功能 15

4.2汽車產品瀏覽查詢模塊實現 15

4.3會員注冊模塊實現 15

4.4留言本功能模塊實現 16

4.5用戶管理模塊實現 16

4.6汽車產品公告模塊實現 16

第5章 汽車之家門戶網站的測試 18

5.1系統測試概述 18

5.2系統測試用例 18

結論 21

參考文獻 22

致 謝 23

摘 要

隨著互聯網的快速發展，汽車企業為了求生存、謀發展，必須順應時代的發展潮流，為汽車企業構建一套企業門戶網站平臺，從而在競爭日益復雜的汽車市場中占據先機。互聯網的商業價值愈發顯現，各個企業以網絡為基礎，構建一個信息化平臺，是大勢所趨，基于網路平臺的市場競爭將是未來汽車企業的主攻點，在充滿機遇和挑戰的現代化浪潮中，汽車企業必須與時俱進，否則將會處于被動的局面。

關鍵詞：汽車企業；門戶網站；ASP.NET；信息化平臺；Web應用程序

第4章汽車之家門戶網站的實現

4.1系統實現的功能

在本文第三章和第四章的基礎上，將基于ASP.NET的汽車企業門戶網站系統的功能模塊劃分為九大模塊，本將將實現這九大模塊，分別為：汽車產品瀏覽查詢模塊、會員注冊模塊、留言本功能模塊、用戶管理模塊、汽車產品公告模塊、汽車產品新聞模塊、留言本管理模塊、汽車產品管理模塊以及密碼找回模塊。

4.2汽車產品瀏覽查詢模塊實現

該功能模塊實現用戶對汽車產品信息的方便瀏覽，包括汽車產品介紹、最新汽車新聞熱點、本網站最新公告等消息，這些瀏覽內容清晰條理，以最大限度的方便用戶的瀏覽，此外為了滿足用戶對本網站汽車產品的查詢要求，本網站提供對汽車產品類別和汽車產品具體信息查詢，通過這種層次化的查詢方式，便于客戶快速準確的查詢到自己關心的商品。

1)汽車產品介紹、最新汽車新聞熱點、本網站最新公告這些內容通過DataList控件進行顯示，對DataList任務進行部署，在項模板(ItemTemplate)上進行編輯，在對表單進行布局設計后，將要顯示的數據項列出，并在每一個數據項目名稱后邊添加一個Label,在其對應的Label任務中完成DataBinds的編輯工作，使用自定義綁定，用代碼表達式方式完成對數據的綁定，建立與底層數據庫的連接，從而完成數據的顯示。

2)汽車產品查詢功能是通過AutoSearch.axpx和AutoSearch.aspx.cs頁面文件來完成的，在汽車產品查詢表單中，通過DropDownList控件來選擇搜索條件，在TextBox控件中輸入搜索關鍵字，在“類別”列表中選擇車型，點擊“搜索”按鈕，執行btnsel_Click”事件，在數據庫中查詢相應數據，并在查詢表單的頁面中通過Gridview控件顯示查詢結果。

4.3會員注冊模塊實現

該功能模塊實現用戶的注冊功能，本網站汽車信息查詢，用戶留言等內容的完成需要用戶登陸，當游客注冊本網站成為本系統的合法用戶時可以使用這些功能。該功能模塊UserRegister.aspx頁面來實現，當點擊首頁中的注冊按鈕時，頁面轉到UserRegister.aspx頁面，在該頁面中部署好表單布局，羅列出用戶注冊成會員的所有待注冊信息，用戶名、密碼等內容使用TextBox控件來完成，角色通過DropDownList控件來實現，在ListlItem成員中添加“普通用戶”，用戶就可以以“普通會員”的角色來注冊；當點擊本表單中的“注冊”按鈕時，執行“BtnUser_Reg_Click”事件，執行SQL插入語句，將用戶的注冊信息，插入到數據庫的會員表中。

4.4留言本功能模塊實現

該功能模塊實現留言本功能，給本系統的用戶提供留言功能，是實現企業和用戶密切交流的有效途徑，通過構建這樣一種溝通橋梁，企業可以及時的得到用戶的反饋信息，對企業中存在的產品和服務問題進行調整和改進，同時用戶也能快速的得到企業的答復，從而解除心中的疑慮，這樣，企業和用戶之間可以建立良好的信息傳遞機制。

該功能模塊通過LeaveMes.aspx頁面來實現，當會員登陸本系統后，通過點擊導航欄中的“留言本”，頁面轉到LeaveMes.aspx頁面，在此頁面中已經對表單完成了布局，用戶在TextBox控件中添加留言主題、留言內容、留言時間以及留言人等內容，通過點擊“提交留言”，完成BtnLeaveMes_Click”事件，將會員提交的留言，通過執行SQL插入語句，插入到數據庫表LeaveMes中，此外通過點擊表單中的“查看我的留言”按鈕，執行“BtnCheckMes Click”事件，通過SQL選擇語句來顯示會員的所有留言。

4.5用戶管理模塊實現

該功能模塊實現管理員對本網站注冊會員的管理，包括添加用戶、修改用戶和別除用戶，實現該功能的頁面為UserManger..aspx.當管理員成功登陸后臺系統時，通過點擊“用戶管理”按鈕，彈出用戶管理表單頁面，在該頁面中引用木板，將母版中的ContentPlaceHolder控件與本頁面合并，通過GridView控件來顯示所有的會員信息，信息的顯示是通過數據綁定操作來實現。

點擊“添加新用戶”按鈕，轉到UserMangerAdd.aspx頁面，在該頁面中完成用戶信息添加，通過點擊“添加”按鈕，執行BtnUserAdd Click”事件，將表單信息插入到數據庫User表中；點擊UserManger.aspx頁面中“修改”按鈕，轉到UserMangerUpdate.aspx頁面，將表單中的信息修改，執行SQL更新命令，更新到數據庫表User中；點擊UserManger..aspx頁面中“刪除”按鈕，轉到UserMangerDelete.aspx頁面，執行SQL刪除命令，將數據從數據庫表User中刪除。

4.6汽車產品公告模塊實現

該功能模塊實現管理員對本網站汽車產品公告的管理，包括添加公告、修改公告和刪除公告，實現該功能的頁面為Notice Manger..aspx。

當管理員成功登陸后臺系統時，通過點擊“公告管理”按鈕，彈出公告管理表單頁面，這個過程與4.5小節類似，在該頁面中引用木板，將母版中的ContentPlaceHolder控件與本頁面合并，通過GridView控件來顯示所有的公告信息，信息的顯示是通過數據綁定操作來實現，公告管理模板的表單如圖4.6所示。點擊“添加公告”按鈕，轉到NoticeMangerAdd.aspx頁面，在該頁面中完成公告信息添加，通過點擊添加”按鈕，執行BtnNoticeAdd Click”事件，將表單信息插入到數據庫Notice表中；點擊NoticeManger..aspx頁面中“修改”按鈕，轉到NoticeMangerUpdate.aspx頁面，將表單中的信息修改，執行SQL更新命令，更新到數據庫表Notice中；點擊NoticeManger..aspx頁面中“刪除”按鈕，轉到NoticeMangerDelete.aspx頁面，執行SQL別除命令，將數據從數據庫表Notice中刪除。

互控件的名稱和定義在學術界并沒有統一的標準，也許在說某一個名字的時候你并沒有理解它的意思，本文主要是讓大家來見識一下那些常用的交互控件，一起來看看~

曾幾何時，對于剛入圈的交互設計師遇到一些具有國際視野（略帶一絲裝逼）的產品經理時，也會出現上圖中的情形。亦或許在某個不經意的瞬間，你也曾犯過下圖的錯誤。那我們今天來認識一下那些常用的交互控件~

按照功能劃分

其實關于交互控件的名稱和定義在學術界并沒有統一的標準，但是目前市場主流的OS廠商都有自己的標準定義，分為：Apple的Human Interface Guidelines 和 Google的Material Design。

可以看到：在Apple的Human Interface Guidelines中apple將交互控件歸入視圖（Views）中，而Google的Material Design將交互控件歸入組件（Components）中。

在這里我不會嚴格按照兩家給出的標準對每一個控件都做詳盡的贅述，我將把工作中常用的組件按照功能來劃分一下并參考iOS和Google對于這些組件的描述，來向大家簡單梳理一下他們的定義和用法。

模態與非模態

在正式開始之前，我先簡單介紹一下模態與非模態。下面是維基百科關于模態窗口（Modal window）的標準解釋。其含義就是：模態窗口下，用戶被強制必須先與當前視窗進行交互才能回到主窗口，此時用戶的行為是線性的。由于其會打斷用戶操作并且強制用戶進行交互，因此模態控件的使用必須謹慎。

反之，非模態即用戶不被強制先與當前視窗進行交互也可以回到主窗口，用戶行為是非線性的，擁有更多主動權。

收納+引導

這類控件包括Popup（或者叫Popover）、Action views、Action sheets/ Sheets_bottom、Dropdown menu，其共同特點是由用戶主動觸發（默認隱藏）、輕量化、指向性較強、包含操作、不會自動消失。

這類控件多用于屏幕空間的移動設備，作為低頻但重要的操作入口（Dropdown menu在PC的應用場景同樣很多）。這一類控件多半是非模態的。

1. Popup（Popover）&Dropdown menu

iOS的Popup（Popover）與Android的Dropdown menu的使用場景和展現形式基本類似，主要用于收納一些默認不展示的低頻選項， 不過值得注意的是：Popup和Dropdown menu出現的位置和方式與其入口的位置是有很大關系的，特別當入口按鈕是位于屏幕邊緣的時候尤其需要注意。

此外，Popup（Popover）自帶箭頭的強指示性，同樣適用于展示隱藏操作或新功能上線后的用戶教育。

2. Action views&Action sheets

不同于Popup（Popover）和Dropdown menu幾乎可以出現在屏幕的任何位置，Action views和Action sheets/ Sheets_bottom一般出現在屏幕底部。同樣，他們也是用于容納并展示低頻但重要的操作。

提示+引導

這類控件包括Toast、Snackbars、HUD，其共同特點是：不一定由用戶主動觸發、輕量化且一般不包含操作，展示時間較短（一般在3秒以內）且會自動消失，這類控件多用于系統狀態或者用戶操作結果的展示。同樣，這類控件基本都是非模態的。

1. Toast

根據維基和android開發者指南的解釋：Toast是一種小巧的作為操作反饋的信息窗口，并且會自動消失。

有意思的是，據說一位微軟前員工在開發MSN Messenger時，覺得MSN彈出通知方式很像烤面包（Toast）烤熟時從烤面包機（Toaster）里彈出來一樣，因此把這種提示方式命名為Toast，后來這位微軟前員工帶著這一習慣命名跳槽去了Google。

其實，在實際應用中，Toast的應用延伸較多，除了作為操作反饋的信息展示窗口，還常常被用來作為系統狀態更新時的提示，并且在出現的位置上，也沒有非常嚴格的定義。

2. Snackbars

按照使用場景和元素來說，Snackbars可以簡單理解為Toast的升級版本，但根據Google Material Design的定義，我們可以發現：Snackbars與Toast的主要差別在于前者可以包含一個操作按鈕，而后者不包含。

在實際應用中，Snackbars的應用范圍其實比較廣，我們會發現：Snackbars主要被用在展示一些對用戶很重要的操作結果，比如：刪除文件或者快速引導。

3. HUD

HUD全稱叫做UIProgressHUD，其實在iOS Human Interface Guidelines中并沒有Toast和Snackbars這樣的定義，但是與之對應的是UIProgressHUD（直譯為界面進程浮層），這種控件是iOS系統私有的，在App Store上線的app原則上是不能直接獲取的，所以出現了許多模仿的第三方控件（主要是app開放者用以與iOS的UI風格保持一致的嵌入式組件）。

4. Toast& Snackbars& HUD小結

其實，我們這樣理解這三者之間的關系更加簡單明了：Google的Toast≈iOS的HUD，Snackbars=Toast+操作按鈕，Toast+Snackbars+HUD都是用來展示app或者系統內的狀態信息。

提示+操作

這類控件主要是Dialogs/ Alerts，嚴格意義上來說，其實Alerts（警告型對話框）也是屬于Dialogs中的一種。Google的Material Design將Dialogs分為：Alert Dialog、Simple Dialog、Communication Dialog和Full-screen Dialog，但是在iOS中并沒有定義Dialogs這種控件，而只是對Alerts做了定義。

對話框的精髓在于讓用戶聚焦，它一般有兩種使用場景：

1. 系統的關鍵狀態提示，并且如果不處理當前狀態會影響到用戶的下一步操作，如：系統錯誤或者電量過低。
2. 需要用戶特別注意的關鍵信息處理，如：刪除文件、支付確認Google Material Design關于對話框的定義。

1. Alert Dialog

由于警示型對話框出現的形式非常直接（包含用戶主動觸發與系統自動觸發），且常常會打斷用戶當前操作行為（強打擾性），因此絕大部分的警示型對話框被用在關鍵信息處理或者關鍵狀態提示上，

如：

• 文件操作場景 — 刪除文件，放棄編輯；
• 支付場景 — 支付二次確認，余額不足提示；
• 重要狀態改變場景 — 手機電量低，版本更新。

值得注意的是：在警示型對話框中的按鈕文案使用一定要避免歧義，不要讓用戶做選擇變成一道哲學命題。

Google Material Design總結了一些Alert Dialog按鈕文案的一些基本規則：

（1）文案要釋義操作行為，比如：當問題為“您是否要放棄編輯當前的郵件”相比于用簡單的“是”或“否”，使用“放棄編輯”和“繼續編輯”用戶更能清楚操作后的預期效果。

（2）從用戶習慣來說，對于當前提問的肯定回答應置于右側，而否定回答應置于左側 。

同樣接著上一個例子，當問及“您是否要放棄編輯當前的郵件”時，“放棄編輯”應該置于右側，而“繼續編輯”應該置于左側。

（3）對于APP內或系統重要狀態的提示，不要給多余的按鈕而讓用戶費解。

（4）最好不要在警示型對話框中放置諸如“了解更多”等第三個按鈕，因為它會將用戶引導至其他內容而導致用戶中斷/忘記當前對話框的操作。

2. Simple Dialog

簡易對話框用以展示用戶做即時決斷的選項，選項本身既是信息又是按鈕，不包含單獨的文案按鈕。

一般用于多選其一且不用二次確認的場景，如：地區選擇、語言選擇、郵箱地址選擇等。

3. Confirmation Dialog

確認對話框用于需要用戶進行選擇并手動確認的場景，不同于簡易對話框，用戶可以選擇一項或者多項，并且包含確認和取消按鈕。

4. Full-screen Dialog

全屏對話框包含一些列的操作任務，這些操作任務可能需要用到鍵盤輸入并且還可能包含子對話框，典型的使用場景如：填寫表單、設置日程等。

附上參考文獻的原文鏈接：

Google Material Design— https://material.io/design/components/dialogs.html#usage

iOS Human Interface Guidelines— https://developer.apple.com/ios/human-interface-guidelines/views/alerts/

Android Developers— https://developer.android.com/guide/topics/ui/notifiers/toasts

Modal window— https://en.wikipedia.org/wiki/Modal_window

UIProgressHUD— http://iphonedevwiki.net/index.php/UIProgressHUD

Toast（computing）— https://en.wikipedia.org/w/index.php?title=Toast_（computing）&oldid=459336160

本文由 @ johnnylhj 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖作者提供

 using (HouseEntities db=new HouseEntities())
 {//新建了一個數據上下文，它實現了IDisposable接口，使用USING可以確保其最終被dispose。如果不是用using，請在返回前主動調用db.Dispose(); 
 }

 House house=new House()
 {
 Area=10.2m,
 Seller_ID=1,
 Floor=1,
 Street="南京路",
 Name="第一百貨商店",
 Price=99999.1m,
 Region="黃浦區"
 };
 using (HouseEntities db=new HouseEntities())
 {
 house=db.House.Add(house);
 db.SaveChanges();
 //db是數據上下文，House是數據實體類的一個集合,Add方法用于向上下文中添加實例，最后必須要經過db.savingchanges()來進行數據存儲
 }

 /// <summary>
 /// 通過ID查找House
 /// </summary>
 /// <param name="id">House的ID</param>
 /// <returns>查找到的HOUSE</returns>
 public static House GetHouseByID(int id)
 {
 House house=null; //需要返回的house
 using (HouseEntities db=new HouseEntities())
 {
 house=db.House.Where(x=> x.ID==id).FirstOrDefault();
 //db是數據上下文，House是數據實體類的一個集合，where里是lambda表達式，進行查詢
 //最后的FirstOrDefault是取第一條或默認，如果取不到對應條件的數據則會返回NULL
 }
 return house;
 }

 /// <summary>
 /// 通過地區查找Houses
 /// </summary>
 /// <param name="region">House所在區域</param>
 /// <returns>查找到的HOUSES</returns>
 public static List<House> GetHousesByRegion(string region)
 {
 List<House> houses=null; //需要返回的house列表
 using (HouseEntities db=new HouseEntities())
 {
 houses=db.House.Where(x=> x.Region==region).ToList();
 //查詢條件后跟ToList方法，就可以獲得指定條件下的數據表了
 }
 return houses;
 }

 /// <summary>
 /// 更新House
 /// </summary>
 /// <param name="house">House的實例</param>
 /// <returns>是否成功</returns>
 public static bool UpDateHouse(House house)
 {
 bool isComplete=false; //需要返回的bool
 using (HouseEntities db=new HouseEntities())
 {
 house=db.House.Attach(house);
 db.Entry(house).State=System.Data.Entity.EntityState.Modified;
 isComplete=db.SaveChanges() > 0;
 //對于無法驗證是否存在于映射中的實例，首先要進行attach操作，其次，為了保證update指令被執行，我們還需要entry到這個數據上下文的實例匯中，把它的狀態設置為已修改
 }
 return isComplete;
 }

 /// <summary>
 /// 通過ID刪除House
 /// </summary>
 /// <param name="id">需要刪除的house的ID</param>
 /// <returns>是否執行成功</returns>
 public static bool DeleteHouseByID(int id)
 {
 bool isComplete=false; //是否執行成功
 using (HouseEntities db=new HouseEntities())
 {
 var house=db.House.Where(x=> x.ID==id).FirstOrDefault();
 //首先查詢需要刪除的house
 db.House.Remove(house);
 //然后執行remove方法，將對象從映射中移除
 isComplete=db.SaveChanges() > 0;
 }
 return isComplete;
 }