.Net面試題收集

1、對於 Web 性能優化，您有哪些瞭解和經驗嗎？
一、前端優化
（1）減小 HTTP 請求的次數。咱們知道每次發送http請求，創建鏈接和等待相應會花去至關一部分時間，因此在發送http請求的時候，儘可能減小請求的次數，一次請求能取出的數據就不要分屢次發送。
（2）啓用瀏覽器緩存，當肯定請求的數據不會發生變化時，可以直接讀瀏覽器緩存的就不要向服務端發送請求。好比咱們ajax裏面有一個參數可以設置請求的時候是否啓用緩存，這種狀況下就須要咱們在發送請求的時候作好相應的緩存處理。
（3）css文件放 在裏面，js文件儘可能放在頁面的底部。由於請求js文件是很花費時間，若是放在裏面，就會致使頁面的 DOM樹呈現須要等待js文件加載完成。這也就是爲何不少網站的源碼裏面看到引用的文件放在最後的緣由。
（4）使用壓縮的css和js文件。這個不用多說，網絡流量小。
（5）若是條件容許，儘可能使用CDN的方式引用文件，這樣就能減小網絡流量。好比咱們經常使用的網站http://www.bootcdn.cn/。
（6）在寫js和css的語法時，儘可能避免重複的css，儘可能減小js裏面循環的次數，諸如此類。
二、後端優化：
（1）程序的優化：這是一個很大的話題，我這裏就選幾個常見的。好比減小代碼的層級結構、避免循環嵌套、避免循環CURD數據庫、優化算法等等。
（2）數據庫的優化：（因爲數據庫優化不是本題重點，因此可選幾個主要的來講）好比啓用數據庫緩存、經常使用的字段建索引、儘可能避免大事務操做、避免select * 的寫法、儘可能不用in和not in 這種耗性能的用法等等。
大數據的處理；數據層如何優化（索引、儘可能避免是*、like 、not in等操做、使用分頁、存儲過程的方式）、Redis的緩存數據庫的用法、讀寫分離數據庫的 用法、使用輕量級的ORM（NPoco）等操做；
（3）服務器優化：（這個可做爲可選項）負載均衡、Web服務器和數據庫分離、UI和Service分離等等。

2、Asp.Net Web API VS Asp.Net MVC
一、Asp.net MVC 是用來建立返回視圖（Views）與數據的Web應用，而Asp.net Web API是一種簡單輕鬆地成熟的HTTP服務，它只返回數據，不返回視圖（Views）。
二、Asp.net Web API能夠經過.Net Framework來幫助咱們構建REST-ful服務，並且他支持內容協商（根據客戶端能接受的格式要求，返回相應的JSON，XML，ATOM），同時Asp.net Web API支持自我宿主（self-hosting），而MVC並不支持（只能宿主在IIS中）。
三、Asp.net Web API能夠返回特定的數據類型，好比JSON，XML，或者其餘在請求頭中定義的數據格式。而MVC只能利用Json Result返回JSON數據類型。
四、Asp.net Web API 根據HTTP 謂語動詞來映射Action，但MVC只是映射 Action 名稱。
五、Asp.net Web API 一種全新的框架，它是Asp.net Framework 核心庫的一部分。在Asp.net Web API 一些存在MVC中的特徵（model binding、filters、路由）是存在System.Web.Http程序集中，而MVC是存在System.Web.Mvc中。所以，Web API 能夠和Asp.net一塊兒使用，也能夠作獨立的服務層。
六、若是在一個項目中融合Web API和MVC controller，用於處理複雜AJAX請求，這些請求可能返回JSON，XML或者其餘數據格式。這就是Web API 自我宿主（Web API self-hosting）。
七、若是融合MVC和Web API 控制器（controller），並且須要集成認證，這時，須要建立兩個過濾器（Filters），一個MVC的，另外一個Web API的，由於他們兩個是不相同的。
八、總之，WebApi在提供數據方面，是比MVC更加輕量的架構。

3、WebApi中Filter種類及做用
Authorization IAuthorizationFilter 最早運行的Filter，被用做請求權限校驗
Action IActionFilter 在Action運行的前、後運行
Exception IExceptionFilter 當異常發生的時候運行

4、關於webapi開發接口的安全問題，推薦使用JWT的方式進行接口調用的加密
JWT即JSON web Tokens ,能夠用來安全的傳遞信息，由於這些信息是通過數字簽名的
JWT可使用一種加密算法好比HMAC算法，也可使用公鑰/私鑰的非對稱算法
由於JWT簽名後的信息夠短，能夠放在URL裏，request body裏、http header裏，傳輸夠快
負載信息裏面包含全部你想要的信息，避免不止一次的去查詢數據庫
JWT的使用場景主要包括
1）認證，這是比較常見的使用場景，只要用戶登錄過一次系統，以後的請求都會包含簽名出來的token
,經過token也能夠用來實現單點登錄
2）交換信息，經過使用密鑰對來安全的傳遞信息，能夠知道發送者是誰，放置信息被篡改
JSON web Tokens由三部分組成，用英文句點分割（.）,通常看起來例如xxx.yyy.zzz
分爲：
Header 頭信息
PayLoad 負載信息，實際數據
Signature 由頭信息+負載信息+密鑰 組合以後進行加密獲得
1）Header頭信息一般包含兩部分，type:表明token的類型，這裏使用的是JWT類型。alg:使用的Hash算法
，例如HMAC SHA256或RSA
{
"alg":"HS256",
"type":"JWT"
}
//這會被通過base64URL編碼造成第一部分
2）PayLoad 一個token的第二部分是負載信息，它包含一下聲明Claim(實體的描述，一般是一個User信息，還包括一些
其它的元素）
聲明分三類
a）Reserved Claims,這是一套預約義的聲明，並非必須的，這是一套易於使用。操做性強的聲明，包括iss(issuer)
exp(expiration time)、sub(subject)、aud(audience)
b)Public Claims
c)Private Claims,交換信息的雙方自定義的聲明
3）signature使用header中指定的算法將編碼後的headr、編碼後的payload、一個secret進行加密
例如使用的是HMAC SHA256算法，大體流程相似於：HMACSHA256(base64UrlEncode(header)+"."+base64UrlEncode(payload)+"."+secret)
這個signature字段被用來確認JWT信息的發送者是誰，並保證信息沒有被修改；
因爲沒有使用Cookies,Cross-Origin Resource Sharing(CORS)，跨域的資源訪問不會成爲問題；

5、MVC路由理解？
一、首先咱們要理解MVC中路由的做用：url Routing的做用是將瀏覽器的URL請求映射到特定的MVC控制器動做。
二、當咱們訪問http://localhost:8080/Home/Index 這個地址的時候，請求首先被UrlRoutingModule截獲，截獲請求後，從Routes中獲得與當前請求URL相符合的RouteData對象， 將RouteData對象和當前URL封裝成一個RequestContext對象，而後從Requestcontext封裝的RouteData中獲得 Controller名字，根據Controller的名字，經過反射建立控制器對象，這個時候控制器才真正被激活，最後去執行控制器裏面對應的 action。

6、談談你以爲作的不錯系統，大概介紹下用到了哪些技術？
WPF、MEF、Vue、Xamarin （展開）

7、IOC和DI
其實它們是同一個概念的不一樣角度描述，控制反轉IOC(Inversion of Control)是說建立對象的控制權進行轉移，之前建立對象的主動權和建立時機是由本身把控的，而如今這種權力轉移到第三方，好比轉移交給了IOC容器，它就是一個專門用來建立對象的工廠，你要什麼對象，它就給你什麼對象，有了 IOC容器，依賴關係就變了，原先的依賴關係就沒了，它們都依賴IOC容器了，經過IOC容器來創建它們之間的關係。DI(依賴注入)其實就是IOC的另一種說法，DI是由Martin Fowler 在2004年初的一篇論文中首次提出的。他總結道：控制的什麼被反轉了？就是得到依賴對象的方式反轉了。

NETCore下DI使用總結
AddSingleton ： 在整個應用生命週期裏都是惟一
AddTransient：每次獲取一次服務就建立一個實例
AddScoped：在咱們自定義的Scope內的生命週期，在Scope內是惟一

8、設計模式的六大原則
單一職責原則：一個類只負責一個職責，不能有多個致使類變動的緣由
開閉原則：一個軟件實體，如類、模塊和函數應該對擴展開放，對修改關閉
里氏替換原則：避免子類重寫父類中已經實現的方法
迪米特法則：一個對象應該對其餘對象有最少的瞭解
接口隔離原則：接口儘可能小，接口要高內聚
依賴倒置原則：要儘量使用接口或抽象類

9、談談你對設計模式的認識？結合你用得最多的一種設計模式說說它的使用
單例模式：1）一個類只有一個實例；2）提供一個全局訪問點；如何保證一個類只有 一個實例，定義私有的構造函數，這樣外界就不能經過new關鍵字進行 建立實例了；
工廠模式
觀察者模式

10、數據庫優化經驗（後端工程師很是常見）
一、數據庫運維方面的優化：啓用數據庫緩存。對於一些比較經常使用的查詢能夠採用數據庫緩存的機制，部署的時候須要注意設置好緩存依賴項，防止「過時」數據的產生。
二、數據庫索引方面的優化：好比經常使用的字段建索引，聯合查詢考慮聯合索引。（PS：若是你有基礎，能夠敞開談談彙集索引和非彙集索引的使用場景和區別）
三、數據庫查詢方面的優化：避免select * 的寫法、儘可能不用in和not in 這種耗性能的用法等等。
四、數據庫算法方面的優化：儘可能避免大事務操做、減小循環算法，對於大數據量的操做，避免使用遊標的用法等等。

11、關於代碼優化你怎麼理解？你會考慮去代碼重構嗎？
一、對於代碼優化，以前的公司每週會作代碼審覈，審覈的主要做用就是保證代碼的正確性和執行效率，好比減小代碼的層級結構、避免循環嵌套、避免循環CURD數據庫、儘可能避免一次取出大量數據放在內存中（容易內存溢出）、優化算法等。
二、對於陳舊代碼，可能不少地方有調用，而且開發和維護人員頗有可能不是同一我的，因此重構時要格外當心，若是沒有十足的把握，不要輕易重構。若是必需要重構，必須作好充分的單元測試和全局測試。

12、談談你的優勢和缺點
優勢：對於新的技術學習能力強，能很快適應新環境等等
缺點：對技術太過於執着等等

十3、關於服務器端 MVC 架構的技術實現及理解
MVC，顧名思義，Model、View、Controller。全部的 界面代碼放在View裏面，全部涉及和界面交互以及URL路由相關的邏輯都在Controller裏面，Model提供數據模型。MVC的架構方式會讓系 統的可維護性更高，使得每一部分更加專一本身的職責，而且MVC提供了強大的路由機制，方便了頁面切換和界面交互。而後能夠結合和WebForm的比較， 談談MVC如何解決複雜的控件樹生成、如何避免了複雜的頁面生命週期。

十4、運行慢，如何定位問題？發現問題如何解決？
後臺日誌查看請求耗時，而後再去查找耗時的根源並解決該問題

十5、說說你最擅長的技術？並說說你是如何使用的？
MEF、 DIP、IOC、DI、插槽、服務

十6、寫過多線程組件？簡要說明！
Reduce
當任務觸發的頻率很是高時，合併名稱相同的任務處理函數，保證名稱相同的任務只一個在執行，保證第一個任務能執行到
保證名稱相同的任務只一個在執行，且最後一個任務能執行到，中間某些任務的返回結果會被覆蓋掉，返回最後一個任務的執行結果
保證相同參數的任務只有一個在執行
保證參數相同的任務只一個在執行，且最後一個任務能執行到，中間某些任務會被忽略掉
合併指定時間段內的事件，間隔小於時間段的事件都被忽略，保證最後一個任務能被執行
TaskQueue
TaskPool

十7、Http協議
一、http協議是瀏覽器和服務器雙方共同遵循的規範，是一種基於TCP/IP應用層協議。
二、http是一種典型的請求/響應協議。客戶端發送請求，請求的內容以及參數存放到請求報文裏面，服務端收到請求後，作出響應，返回響應的結果放到響應報文裏面。經過F12能夠查看請求報文和響應報文。
三、http協議是」無狀態」的，當客戶端向服務端發送一次http請求後，服務端收到請求而後返回給客戶端相應的結果，服務器會當即斷開鏈接並釋放資源。在實際開發過程當中，咱們有時須要「保持」這種狀態，因此衍生出了Session/Cookie這些技術。
四、http請求的方式主要有get/post。
五、http狀態碼最好記幾個，博主有一次面試就被問到了。200（請求成功）、404（請求的資源不存在）、403（禁止訪問）、5xx（服務端錯誤）

十8、http常見狀態碼
2開頭狀態碼
2xx (成功)表示成功處理了請求的狀態代碼
200 (成功) 服務器已成功處理了請求。 一般。
3開頭狀態碼
3xx (重定向) 表示要完成請求，須要進一步操做。 一般，這些狀態代碼用來重定向。
302重定向
304 (未修改) 自從上次請求後，請求的網頁未修改過。 服務器返回此響應時，不會返回網頁內容。
4開頭狀態碼
4xx(請求錯誤) 這些狀態代碼表示請求可能出錯，妨礙了服務器的處理
1:400 (錯誤請求) 服務器不理解請求的語法。
2:403 (禁止) 服務器拒絕請求。
3:404 (未找到) 服務器找不到請求的網頁。
5開頭狀態碼
5xx(服務器錯誤)這些狀態代碼表示服務器在嘗試處理請求時發生內部錯誤。 這些錯誤多是服務器自己的錯誤，而不是請求出錯
500 (服務器內部錯誤) 服務器遇到錯誤，沒法完成請求。
501 (還沒有實施) 服務器不具有完成請求的功能。 例如，服務器沒法識別請求方法時可能會返回此代碼。
502 (錯誤網關) 服務器做爲網關或代理，從上游服務器收到無效響應。
503 (服務不可用) 服務器目前沒法使用(因爲超載或停機維護)。 一般，這只是暫時狀態。
504 (網關超時) 服務器做爲網關或代理，可是沒有及時從上游服務器收到請求。
505 (HTTP 版本不受支持) 服務器不支持請求中所用的 HTTP 協議版本。

十9、Ajax提交數據
$.ajax({
url: "admin/check_login", // 提交到controller的url路徑
type: "post", // 提交方式
data: {"username": username, "password": password}, // data爲String類型，必須爲 Key/Value 格式。
dataType: "json", // 服務器端返回的數據類型
success: function (data) { // 請求成功後的回調函數，其中的參數data爲controller返回的map,也就是說,@ResponseBody將返回的map轉化爲JSON格式的數據，而後經過data這個參數取JSON數據中的值
if (data.message == "success") {
//跳轉到系統首頁
......
} else {
......
}
},
});

二10、IIS的工做原理
一、當客戶端發送HTTP Request時，服務端的HTTP.sys（能夠理解爲IIS的一個監聽組件） 攔截到這個請求；
二、HTTP.sys 聯繫 WAS 向配置存儲中心請求配置信息。
三、而後將請求傳入IIS的應用程序池。
四、檢查請求的後綴，啓動aspnet_isapi.dll這個dll，這個dll是.net framework裏面的，也就是說到這一步，請求進入了.net framework的管轄範圍。
五、這個時候若是是WebForm，開始執行復雜的頁面生命週期（HttpRuntime→ProcessRequest→HttpContext→HttpHandler）；若是是MVC，則啓動mvc的路由機制，根據路由規則爲URL來指定HttpHandler。
六、httpHandler處理請求後，請求結束，給出Response，客戶端處理響應，整個過程結束。

二11、SQL Server數據庫操做的原子性 SQL Server數據庫操做的原子性，出Select以外，Update、Insert、Delete的操做都是原子性的，不可拆分，執行的最小單位；能夠用於充值交費中 ，若是多個請求進行更新同一條 數據時，直接使用update Table1 set money=money+100 這種方式就能夠避免多個語句，更新一條記錄致使的更新失敗的問題（通常想法是，先查詢當前的帳戶餘額，而後進行更新，這種想法太low）;能夠直接使用一條更新語句便可；