一、SSM（Spriing springMVC Mybatis）框架搭建常見web應用時所需注意的細節問題及相關思考：
1、項目設計中要注意其直接間接可能涉及的問題，思考邊緣性相關內容，思考可擴展性。比如在通用的網站項目中，廣告是個很重要的盈利部分。所以在設計廣告的數據庫時，根據頁面顯示狀況，判斷每頁顯示的信息數量，以及商業運營過程中，廣告位的排序問題，比如競價排名，如何表現呢？比如爲每條廣告信息增加一個權重字段，比如權重參考值爲充值金額，所以設計數據庫時，不能僅僅看到當前界面，更要考慮到可擴展性；
2、如上，數據庫的字段長度在設計時，要考慮其可能最大長度。圖片資源考慮到現實部署中，圖片、文件等io靜態資源，會存放到單獨的靜態服務器，而非web前端接口服務器上。所以存放的是圖片的文件名，而不是真實路徑。因爲萬一隨着數量擴充，靜態資源服務器需要擴充，直接寫靜態服務器絕對地址也是不方便的。真實狀態下，通常是將靜態資源存放路徑作爲一個配置文件，給外界，進行靈活部署。
3、項目通常會先做增加數據的功能，之後是查詢功能，然後是刪除功能，最後是修改功能，因爲先開發增加數據的頁面，好先往數據庫中添加數據，之後可查詢，而刪除功能再做時即比較方便，修改，更像先刪除再增加數據。
4、頁面中，能共用的部分，可抽取時，適當考慮共通化。比如，界面上到處都需要共用項目部署時真實的環境上下文路徑，可以
抽取出如下用於定位的jsp中用的共通變量，然後再各個頁面引入，而爲了不在每個頁面中寫引入語句，可以在配置文件中搞定。
根據提示找到該文件，確定文件所在路徑，發現路徑級別錯誤，更正爲如下：
5、DTO的使用。實際開發中，鑑於減少寬帶流量和數據安全性考慮（防止數據泄露，或者被有心人去分析網站等），後臺只向前臺傳輸必需的數據，當數據庫中單個表所對應的實體類，無法直接滿足界面上相應數據顯示時，一般做法是，新創建一個DTO業務類，繼承和數據庫完全匹配的基礎類，然後在其中增加相應的界面顯示屬性。
6、SSM常見web項目部署架構圖如下，通過該圖，可以反映出大致的業務訪問路徑，和各部分之間的關係。比如由此圖可便於理解，爲何訪問靜態資源如圖片時的路徑不直接通過request獲取，因爲經過Nginx、CDN等，加上各個部分的擴充，路由可能會一直在變化，所以存放圖片的數據庫字段只是存放了圖片的名稱，而不是完全的路徑。同時圖片等文件內容存放的地址通過讀取配置文件的方式（配置文件由運維人員部署時根據真實環境按照所需信息進行填寫配置）
二、商戶管理考究：
1、實體和數據庫表設計：
注意實體設計時，畫着實線的屬性表示直接可源於商戶的屬性，而虛線的屬性表示冗餘，或者來源有特殊考究的屬性。比如距離，應該是瀏覽者到商戶的位置經過計算得來的。已售數量和星級應該來源於訂單。如此等等。
2、接口注意問題：SpringMVC 使用RESTful風格接口的解決方案是,在表單提交請求時，在其中埋入一個隱藏的input，命名一個
_method 的name,value對應到後端實質性的接口。當然，這裏依賴於spring MVC進行的特殊處理，即通過過濾器的方式，將http
映射到RESTful API 風格的接口上。
其中映射對應關係爲：
spring mvc的配置爲：
此處以根據一個商戶id刪除某個商戶爲例說明：
表單提交時的使用方法爲：注意，這裏傳統的http請求方法是將id作爲hidden元素藏到表單裏，因爲我們希望通過restful api的方式進行，故這裏的表單提交隱藏元素是如下_method value 爲delete。然後通過js的方式進行處理。
js 對應爲：
後臺接口爲：
如上，basepath 爲上下文，比較常見，不贅述。如果能打印出id值，即說明刪除數據成功。
3、關於商家的搜索相關問題：
正常大項目，搜索 應該是會考慮全文搜索，而不是簡單的通過sql的like 模糊匹配進行搜索；
其次，在搜索時，一般比如城市、類別等項目比較多時，一般會考慮code 和 名稱進行匹配，單獨創建一張表這樣的方式進行
處理，簡化後期可能的代碼維護工作。
4、補充一個對數據進行修改的操作示例：
該示例將一方面介紹如何做修改功能和需要注意的事項，同時說明一個問題，即在如上所說的http請求轉restful api接口請求過程
中會出現的一個問題，就是普通數據和上傳圖片、文件等multipart類型數據在處理時，需要spring mvc做的一個特殊處理。否則
會出現不識別的問題，如下爲原理探究：
一個mvc工作流程：
如下爲需要在spring mvc配置文件中增加的過濾器，且，spring mvc配置文件中的過濾器在配置時是有順序規範的，是從上往下依次進行執行和處理的。
