[項目設計]考慮抽象出商務邏輯

    我不清除目前有什麼比較好的理論指導，讓項目的結構稍微有點層次感。
    目前項目代碼很簡單，但耦合太大，可以說是以介面為準的。比如，查看所有的合約。我們的操作是直接使用ado.net與資料庫通訊，返回所有的合約後，將其資料集綁定到DataGrid。緊接著提供連結，可以讓使用者查看某個合約的具體細節。
    這樣做，很本能，很直接，也很有效。但是，前提要求客戶需求穩定。至於，它的弊端，我想有過實際經驗的人都知道。我在這裡也不多說了。
    今天的重點不是數落這種初級的思維方式。我的疑難是如何有效地轉變這種方式。換句話說，是該用哪種方式去代替她。
      考慮了很多，我還是覺得套用ORM這些看似比較龐大的架構很不實際 （我考慮過ORM。但感覺ORM會不適合需求不穩定的項目。對ORM我不是很瞭解，更談不上實戰經驗）。
    另外，對於不大的項目來說，工期短，客戶需求模糊。所有的因素決定了我們要在變化當中找出不變的東西來，並把他抽象出來。
    當一些看似在變的實體被抽象出來後，我們也就能把中心從介面轉移到更加重要的商務邏輯上來。我感覺這樣做了之後，至少層次會更清晰。耦合度也將降低，之後的維護工作也會變得更簡單。
    泛泛之談，一般沒有什麼意義。因此，打算對已做過的項目重新分析一下，統計出些比較實用的原則。