MVC4 Web API：從哪裏開始正確？ **意見** **

Question

我正在創建一個EF/MVC4/Web API項目來試用Azure並將Json數據提供給Windows應用商店。由於這個項目將是對公衆高度可見的，我想，以確保它儘可能作爲等安全......但是我討厭以後返工的代碼，因爲我發現我的東西離開了通過我的代碼流淌下來，所以我真的希望第一次做對。我正在尋找的不是一些教程，它向我展示瞭如何從微軟的臃腫模板創建一個項目。我正在尋找一些高層次的指導。例如（但不限於...）

• 他們的任何必須有nuGet軟件包？哪些和爲什麼？
• 什麼是使用此設置的最佳認證形式？
• 在進入實際的 應用程序之前，我應該考慮採取哪些步驟？ （也許鎖定路線或設置Log4Net ...等？）
• 我應該首先使用代碼第一EF或DB像我一直有？
• 等...

我想我只是含糊適當的步1,2,3從點擊「新建項目」按鈕，在那裏我只是建築的肉點獲得應用程序，而不必擔心配置，身份驗證，安全漏洞等等，以及一些最佳實踐建議也不會受到影響。

當你開始一個這樣的項目時，你會在你點擊應用程序之前做什麼？爲什麼？

Answer 1

1）

• 如果你正在使用VS 2012（強烈推薦），無nugets。雖然你應該安裝更新1，因爲它對VS處理EF EDMX文件（特別是代碼生成工具）有一些很好的補充。
• 如果你使用VS2010，準備好Nuget EF 5和儘可能多的MVC 4組件找。疼痛。

2）最好的asp.net項目驗證形式（esp mvc）是asp.net Membership API。它有一些喜歡在數據庫上運行reqsql.exe來安裝模式的瑣碎內容。但Mem API接口與MVC無縫連接，無需提示。雖然我會改變很多，但它會處理用戶身份驗證，密碼加密和通行字檢索等基礎知識。它的API是本地的，並在項目中自動引用。大多數功能都可以通過Stored Procs訪問。隨着你長大，你可以擴展它。

3）概述你的子系統，並決定有多少控制器用於你的應用程序，以及哪些子系統將共享控制器以及有多少個控制器有自己的控制器。我相信健康數量的控制者。我喜歡有不同種類的控制器。

• 我喜歡在每個菜單項周圍組織控制器。如果您的應用程序具有子系統菜單（例如，客戶，供應商，潛在客戶和員工），則每個應具有用於高級別行爲的專用控制器。如果存在多種用途或子菜單（例如，客戶管理[10個屏幕]，客戶服務[12個屏幕]，客戶分析報告[6個屏幕]），則他們可能需要自己的控制器。

控制器的結構和組織與模式設計一樣重要，但很少得到應有的重視。而MVC的領導往往驚歎於他們的用戶界面的混亂。

• 將EF與存儲過程和Web服務結合使用以實現安全。兩種抽象級別都可以保護您免受腳本和注入攻擊。
• 在你的應用快要完成之前，IDo不會鎖定你的路由或處理基於角色或權限的訪問。

4）USE DB First！代碼首先聽起來不錯，直到你使用它。問題是將實體模型與數據庫同步。 DB首先，DB的任何更改可以是

導入。代碼首先，通過刪除和重新創建表推出更改。亂！！！ 另一種方法是在數據模型之後手動更改數據庫。這是一個頭疼。你發現自己做了兩次工作。而且，不幸的是，我發現生成邏輯模式比映射到邏輯模式的對象關係要容易得多。

Answer 2

這是個人偏好，正如西蒙已經提到的那樣。也就是說，我可以給你一些我的偏好的答案。

1. Nuget包裹： a。 WebAPI - 必須有WebAPI :) b。 ARR - 這使得一些非常強大和有用的路由工具 c。實體框架。 d。 Resharper - 不是一個Nuget包，但一個有用的工具

2. 身份驗證：再次，個人喜好。我使用舊的會員身份驗證取得了巨大成功。它的嘗試和真實，並有大量的文件。也就是說，現在MVC 4已經有了一些內置的OAuth認證選項，尋找這個開始向這個方向轉移。這是非常有趣的東西。 http://www.asp.net/mvc/tutorials/mvc-4/using-oauth-providers-with-mvc

3. 初步的東西取決於你的架構需要什麼。這裏沒有很好的答案恐怕......

4. 守則第一VS DB首先取決於兩個因素：偏好和當前的環境。如果你從頭開始，不想多花數據庫的代價，那就先找代碼吧！這很有趣，並讓你動態地在駕駛座上。另一方面，如果你正在使用現有的數據庫，你的選擇是有限的。我仍然喜歡DB，因爲我可以在模型化代碼之前查看並觸摸我的數據庫。

我發現了很多的時間，應用有機增長，這是對待他們的最好方式。希望這有助於一些:)