這星期在整理工程的文件。發現一些問題。
1、dao層應該進行具體的操作還是抽象程度高的操作？
抽象程度越高，復用的可能性就越大。但是效率上確實眼睜睜看著它提高不了。
2、dao層的操作應該事先準備完整的「增刪改查」，還是等用到的時候再針對性的增加？
由於當初在開始建立工程時，時間緊迫而且需求不清晰，所以dao層給所有的資料庫表甚至所有表的字段都編寫了「增刪改查」的介面。這次整理**的時候發現有好多資料表中的操作（如修改），或者某些欄位的操作都是用不到的，因為業務本身就注定了這些字段一旦寫入就不會再更改或不允許更改。所以，本人其實更傾向於後者，即用到的方法在新增。一是**結構更清晰也更有針對性，二是不必浪費程式設計師的時間開發不用的**。畢竟不是搭建開發平台，要提供盡量充足的介面。更多情況下，都是有針對性，面向一定需求來進行開發的工程。
3、當原先定好的類需要增加新的屬性時，是增加到類中還是新建乙個類？
現在的現狀是經緯度資訊封裝成乙個bean，那麼在不破壞現有**結構的基礎上，可以在原來的sightbean中增加乙個經緯度bean屬性，這樣就可以解決事物增加了屬性而函式卻無法返回新屬性的問題了。相反的，如果將經緯度資訊不進行封裝，而直接增加到原來的sightbean中，那麼與經緯度相關的dao層的傳遞資料型別都要由經緯度bean更新成景點bean，資料冗餘不說，更改**後的測試問題就是牽一髮而動全身。
4、業務邏輯變複雜時，複雜度是否應該向下轉移？
servlet本身應該是作為頁面請求以及業務層處理之間的接頭人。但是在之前的開發中，servlet承擔了過重的角色，一部分邏輯判斷放在了控制層。其實邏輯判斷放在控制層也不能說是錯的，因為控制可以想象成多閘開關，控制它接通哪乙個，判斷也可以算是其中一項任務。但是現在一部分的業務邏輯已經流到了控制層就是很可怕的事情。業務邏輯應該嚴格的控制在業務層中，只有這樣才能將展現與模型分離，當換一種展現方式（如從web方式轉為桌面方式時）才可以不改動模型而只變更展示層的**。
另外，如果業務層的複雜度增加，如需要多個跨表操作時，這個複雜度是否應該由模型層下移到dao層，由sql語句來完成？如果下移，那麼應該下移到哪個dao？
dao層中的類應該與每一張資料表對應還是應該與業務模型中的事物的型別相對應？現在的做法是與資料表相對應，為的是資料介面層與模型層分離。這樣當業務模型改變時，資料介面依然可以保留以適應新的業務模型。但是這種選擇導致的跨表操作的尷尬問題又讓選擇那個dao進行跨表sql變成了一種權衡。
後端開發時碰到的一些情況和一些思考
後台返回給前端的提示語需要和客戶溝通。有個介面不呼叫了，需要在舊的呼叫的地方返回提示語句說明一下不呼叫了。我在這個地方改了，覺得簡單，沒想過會不會涉及其他的地方，也沒測過，直接給測試人員測，出現問題了。問題詳細不便描述，但解決的方法捋清了邏輯如下 舊的邏輯 判斷某個物件是否存在 不存在，呼叫介面。存...
Web獲取的一些思考
幫朋友做乙個天氣預報的web獲取的方式。之前是使用分析xml的方法去分析html，有點類似閱讀網頁原始碼的味道去獲取資料。這樣的好處是比較有邏輯性。而且直接獲取標籤的值，不像直接處理字串的方式那麼原始。壞處，如果網頁標籤有所變得，程式需要可能要重寫。另一種辦法，是我在嘗試的，使用正規表示式。這樣有乙...
Web獲取的一些思考
幫朋友做乙個天氣預報的web獲取的方式。之前是使用分析xml的方法去分析html，有點類似閱讀網頁原始碼的味道去獲取資料。這樣的好處是比較有邏輯性。而且直接獲取標籤的值，不像直接處理字串的方式那麼原始。壞處，如果網頁標籤有所變得，程式需要可能要重寫。另一種辦法，是我在嘗試的，使用正規表示式。這樣有乙...