常見問題

C# 定論：

1) 循環中的值就是迭代元素,通常不容許在迭代即循環時被修改，必須經過臨時變量作轉換

2) 方法參數不能在該方法中被修改，必須經過臨時變量作轉換

3) 類的公共屬性或字段不能在類中被修改

 

來源路徑：http://bbs.csdn.net/topics/392164212

• 如何統計APP在線時長（容許有必定的偏差），怎樣判斷用戶是否還在線

　　　　在全局應用程序類Global.cs中找到SessionStart開始事件和SessionEnd結束事件　　　

　　　　在Session開始事件中定義Session保存登陸時間和登陸狀態State,而後在Session結束事件中得到登出時間，而且清除登陸狀態，

　　　　經過2個時間相減得到在線時長.經過登陸狀態判斷用戶是否在線

• 數據庫表中有一字段表示類型，不知道這個類型會有多少種，查出每一個類型插入的最新一條數據

select * from(
    select  
    *,　row_number() over(partition by Type order by id(主鍵) desc) rIndex 
    from 表名
) vw where vw.rIndex=1

• 談談你對websocket、webapi的理解

　　WebSocket是基於TCP網絡協議。服務器主動發送信息給客戶端.

　　WebSocket原理:

　　在實現websocket連線過程當中，須要經過瀏覽器發出websocket連線請求，而後服務器發出迴應，這個過程一般稱爲「握手」 (handshaking)。在 WebSocket API，瀏覽器和服務器只須要作一個握手的動做，而後，瀏覽器和服務器之間就造成了一條快速通道。二者之間就直接能夠數據互相傳送.

　　服務器的推送，服務器再也不被動的接收到瀏覽器的request以後才返回數據，而是在有新數據時就主動推送給瀏覽器。

　　Web API是構建REST服務的平臺,它支持MVC路由等功能，控制器，做用結果，濾波，模型綁定器，IOC容器和依賴注入，單元測試

• 支付寶支付，微信支付，銀聯支付
  • 支付寶　

1. 1. 提交支付請求到支付寶獲取支付寶POST過來通知消息，並以「參數名=參數值」的形式組成數組 
      1. 若是已經支付過則跳轉到首頁
      2. 查找沒有支付的訂單
      3. 支付類型,1爲商品購買
      4. 服務器異步通知頁面路徑，需http://格式的完整路徑，不能加?id=123這類自定義參數
      5. 頁面跳轉同步通知頁面路徑,需http://格式的完整路徑，不能加?id=123這類自定義參數，不能寫成http://localhost/
      6. 商戶訂單號,商戶網站訂單系統中惟一訂單號，必填
      7. 訂單名稱,必填
      8. 付款金額,必填
      9. 防釣魚時間戳,若要使用請調用類文件submit中的query_timestamp函數
      10. 客戶端的IP地址,非局域網的外網IP地址，如：221.0.0.1
      11. 把請求參數打包成數組
      12. 創建請求
   3. 解讀支付寶接口實現步驟
   4. 支付寶實現主要步驟：

　　　　　　　由兩部分組成，接入部分與通知返回部分。

　　　　　　　接入部分即爲傳遞參數等信息組合成超級連接，並用該連接來進行跳轉。　　　　

　　　　　　　通知返回部分則是支付寶服務器對該筆訂單處理完畢後，通知與返回該筆訂單的詳細信息到商戶服務器，商戶服務器接收到後，並對其進行數據處理。

• • • • 接入部分原理
        • 選定參數信息
        • 排序
        • 加密
        • 拼接字符串成URL連接
        • 自動跳轉
      • 通知返回部分原理
        • 驗證是不是支付寶服務器發來的請求
        • 排序
        • 加密
        • 判斷
        • 自身網站的數據處理
  • 微信支付
    • 參考路徑:
      
      • http://blog.csdn.net/qq_31927865/article/details/52605296
      • http://www.cnblogs.com/wuhuacong/p/5390468.html
      • https://my.oschina.net/bigfool007139/blog/598431
    • 支付流程
      • 獲取訂單信息
      • 根據訂單信息和支付相關的帳號生成sign，而且生成支付參數
      • 將支付參數信息POST到微信服務器，獲取返回信息
      • 根據返回信息生成相應的支付代碼（微信內部）或是支付二維碼（非微信內），完成支付。
    • 開發步驟
      • 客戶端代碼獲得用戶購買的商品信息，將之傳給本身公司app服務器
      • app服務器調用微信「統一下單」接口，獲得prePayId訂單號並返回prePayId給手機客戶端；
      • 手機客戶端使用prePayId及商品信息調起微信客戶端進行支付；微信客戶端回調支付結果給我們的APP客戶端； 
        • 用戶操做：輸入密碼進行支付；返回鍵取消支付；網絡無鏈接支付失敗等； 
      • 微信服務器異步通知我們公司app服務器支付結果（服務器的工做，與客戶端無關）
  • 銀聯支付
    • 參考路徑：http://blog.csdn.net/chen504390172/article/details/16962905
    • 持卡人瀏覽商戶網站，選擇支付項目，生成訂單信息

    • 持卡人確認訂單信息，開始支付

    • 持卡人確認支付信息，商戶網站開始向支付網關申請支付，支付網關驗證商戶身份合法性和訂單報文的完整性

    • 支付網關向持卡人顯示支付渠道選擇界面，持卡人選擇支付渠道

    • 持卡人在所選擇渠道上，輸入用戶賬號、密碼及其餘安全驗證信息 

    • 持卡人的安全認證信息獲得確認後，進行支付

    • 支付渠道向支付網關返回支付結果

    • 支付網關向持卡人顯示支付結果，同時通知商戶網站支付結果

    • 商戶網站向持卡人顯示商戶交易結果 

    • 支付操做完成。

• 若是讓你爲APP提供數據接口，你會注意什麼問題
• 參考路徑：http://blog.csdn.net/junli_chen/article/details/51180797
• 跨平臺性 
• 良好的響應速度 
• 接口要爲移動客戶端考慮 
• 考慮移動端的網絡狀況和耗電量 
• 通用的數據交換格式 
• 接口統計功能 
• 客戶端與服務端的肥瘦平衡
• 隱式用戶與顯式用戶 
• 安全問題  
• 良好的接口說明文檔和測試程序
• 版本的維護
• 在APP中，定位附近模塊的數據你是如何提供的。假如A從當前位置(A1)向前移動了100/200/300米到了（A2）位置，A2位置商家信息，是如何到得的。
  • 基於百度LBS雲服務提供了數據接口
  • APP中根據定位實現搜索附近（POI）的功能，採用百度LBS雲服務，將全部POI數據上傳後，能夠實現該功能。
  • http://www.cnblogs.com/licin/p/6809603.html提供了獲取移動app的座標，而後獲取商戶座標，根據2個座標計算得到距離和位置。
• 大數據 併發
  • 參考路徑：http://blog.csdn.net/buynider/article/details/8655804
  • 常見狀況

    • 大量的用戶同時對系統的不一樣功能頁面進行查找，更新操做

    • 大量的用戶同時對系統的同一個頁面，同一個表的大數據量進行查詢操做

    • 大量的用戶同時對系統的同一個頁面，同一個表進行更新操做

  • 第1種狀況通常處理方法
    
    • 對服務器層面的處理
    1. 調整IIS 7應用程序池隊列長度
    2. 調整IIS 7的appConcurrentRequestLimit設置
    3. 調整machine.config中的processModel>requestQueueLimit的設置
    4. 修改註冊表，調整IIS 7支持的同時TCPIP鏈接數
    • 對數據庫層面的處理
    1. 什麼都不作 –若是併發用戶修改的是同一條記錄，讓最後提交的結果生效（默認的行爲）
    2. 開放式併發（Optimistic Concurrency） - 假定併發衝突只是偶爾發生，絕大多數的時候並不會出現； 那麼，當發生一個衝突時，僅僅簡單的告知用戶，他所做的更改不能保存，由於別的用戶已經修改了同一條記錄
    3. 保守式併發（Pessimistic Concurrency） – 假定併發衝突常常發生，而且用戶不能容忍被告知本身的修改不能保存是因爲別人的併發行爲；那麼，當一個用戶開始編輯一條記錄，鎖定該記錄，從而防止其餘用戶編輯或刪除該記錄，直到他完成並提交本身的更改
    4. 當多個用戶試圖同時修改數據時，須要創建控制機制來防止一個用戶的修改對同時操做的其餘用戶所做的修改產生不利的影響。處理這種狀況的系統叫作「併發控制」。

 

• • • 管理數據庫中的併發有三種常見的方法：

• • • • 保守式併發控制 - 在從獲取記錄直到記錄在數據庫中更新的這段時間內，該行對用戶不可用。
      • 開放式併發控制 - 只有當實際更新數據時，該行纔對其餘用戶不可用。更新將在數據庫中檢查該行並肯定是否進行了任何更改。若是試圖更新已更改的記錄，則將致使併發衝突。
      • 最後的更新生效 - 只有當實際更新數據時，該行纔對其餘用戶不可用。可是，不會將更新與初始記錄進行比較；而只是寫出記錄，這可能就改寫了自上次刷新記錄後其餘用戶所進行的更改。
  • 第2種狀況通常處理方法
    • 對錶按查詢條件創建索引
    • 對查詢語句進行優化
    • 能夠考慮對查詢數據使用緩存
  • 第3種狀況通常處理方法　
    • 先將數據保存到緩存中，當數據達到必定的數量後，再更新到數據庫中
    • 將表按索引劃分(分表，分區)，如：對於一個存儲全國人民信息的表，這個數據量是很大的，若是按省劃分爲多個表，在將全國的人民信息按省存儲到相應的表中，而後根據省份對相應的並進行查詢和更新，這樣大併發和大數據量的問題就會減少不少

 

 

• 7.68轉int是多少
  • 8
• EF的優缺點
  • 參考路徑：http://www.cnblogs.com/wintersun/archive/2013/03/16/2963992.html
  • 優勢：

1. 1. 框架的類映射表，須要編寫映射代碼, 而且是很難維護的。 
   2. 可維護性，易於理解的代碼，無需創造大的數據訪問層。 
   3. 提供LINQ查詢數據庫，這須要從初級開發人員不太瞭解SQL。 
   4. EF能夠用做用於數據服務和OData Service的基礎設施。
   • 缺點：
   1. 實時的應用程序不利於EF同步。 
   2. 只能經過存儲過程訪問數據庫。 EF的優點是：跟蹤實體狀態Change時，不只僅在存儲過程上.（即便EF確實對存儲過程支持有限的）。 
   3. 頻繁插入操做（Insert）,  而且EF不支持大數據Bulk 插入。 
   4. 頻繁更新操做，更新的目標主要是當多行（用一個單值） 
   • • 例如：UPDATE 表名 SET ColumA = 10 Where ColumnB =？ 
   1. 這種更新操做更好的使用的ExecuteNonQuery（也可從Context上下文或直接從Ado.Net）。 
   2. 反範式的表設計和高性能查詢。 EF產生查詢，他們是難以維護的，它並不能很好地支持映射到不規範的表。
   3. 對程序有很是的性能要求, 須要對每一個查詢進行監控.