1.資料層（持久層、dao）要抽象，封裝。盡量不要在sql上寫大段邏輯，這樣業務耦合太大，也不利於系統擴充套件。
2.上層分層要清晰，model和dto要區分對待，各個業務模組之間要解耦。
3.寫**時，要從上往下寫，而不要從下往上寫。從業務場景出發，面向介面程式設計，這樣邏輯比較清晰，介面也分的比較細。如果從下往上寫，往往會被「實現」所束縛，寫出一些很重的介面和模組。
4.業務實現的手段有三種：
1）一股腦在某個業務場景中寫，這樣最省力，但也冗餘最大。
2）在sql中，聯表查詢。這樣靠建表或加欄位實現。對業務場景有抽象了，但是也和底層資料結構繫結了。以後涉及到資料同步，分布式系統，分庫分表的時候會很麻煩。
3）面向介面程式設計，底層只實現基本的資料介面，上層介面呼叫下層介面。這要求對業務場景比較熟悉，並能很好的抽象成介面。
重構之維 關於重構及《重構》的隨想
重構之維 關於重構及 重構 的隨想 重構 究竟重構了什麼？不止一次地，我聽到我們這個行業裡的大師們對重構技術提出 至少是 置疑 那是我們過去十五年裡一直在做的事 我從 上世紀 70年代就已經開始這樣做了 unix上的黑客們一直都是這樣做的 這些說辭讓我很有興趣探其究竟。在這本 重構 裡，martin...
關於重構的思考
目前組內專案的 數量已經到了1.7w行了，架構或者說設計已經逐漸顯示出了疲態，有些功能我們已經超出了我們之前的設計範圍。我們當前的困境，我們在新增部分新功能的時候已經開始強行相容，用一些很變扭的操作實現。同時也已經埋下了很多坑。我們應該進行重構的操作，把當前看到的問題整理調並整我們的設計。這週我進行...
機房收費系統重構 介面設計
終於開始做機房收費系統個人版了。最初是想著如何如何複雜，自己前怕狼後怕虎的，哆哆嗦嗦就是下不了手。一畫圖10幾天過去了，一考試乙個星期又過去了。現在總算是入手了，思路也漸漸清晰起來。問題也隨之而來 在做frmmain這個窗體時，新增的textbox和label的大小不隨窗體最大化而改變。找了一些資料...