我聽說有些人對這樣的工具比較有興趣：從資料庫的元資料中獲得對映物件有資訊。我實在懷疑這種工具的價值。從資料庫獲取元資料資訊非常容易，包括名稱、型別
(含有些可變長型別的長度
)、是否可空、主鍵及外來鍵引用
(獲取關係
)。但是有建模經驗的人基本上都知道，這些資訊是遠遠不夠的，其一是因為元資料還有元資料，有一些關係是不便通過資料庫元資料定義來表達的
(例如自引用
)，有些是表達不全面。例如每個
column
除了column
名還有乙個
caption(
所以datatable
中的datacolumn
就同時擁有
columnname
和caption
兩個屬性
)，這兩個屬性的功能是不同的，
column
名用於資料庫的
schema
定義，而
caption
基本上是用於領域定義
(設計良好的
ms access
可以獲得
caption)
；另外他們的字符集
(有些資料庫規定只能用
ascii
碼，並且與標籤的命名規則相同，儘管
ms sql server
在這方面比較寬鬆
)、特性
(有一些關鍵字不可以用於
column
名定義)
也不完全相同。所以二者不能互相替代。其二是資料庫的元資料規範與物件導向的元資料規範也完全不同，很多情況下
table
名不能直接用作
class
名、column
名也不能直接用作
class
的property
名。t_customer
怎麼也不象個
class
名；f_customername
怎麼看也不象個
property
名。所以我反對直接從資料庫結構直接生成業務層實體物件的原始碼不是沒有道理的。
類似的道理，在將資料庫元模型對映為領域元模型的時候，同時也將列舉對映到領域元模型中就非常有必要。例如：很多人對性別的定義是這樣的：
public
enum
gender
當屬性為
gender
型別並對映到
propertygrid
的時候，彈出下拉列表，其中有「
male
」和「female
typeof
(int
), 「性別」,
false
)]public
enum
gender
0, 「男」,
false
1, 「女」,
false
)]female
}這樣就簡單了。你可以修改
gender
型別的編輯器，以便讓
propertygrid
可以識別
和兩個標籤，能夠列出「男」和「女」兩個項。
有人已經注意到了，
標籤中，第乙個引數是列舉的基型別
(其實是儲存到資料庫中的基型別，可以支援
int、
bool
、string
和char
四種，在
enum
中的基型別永遠都是
system.int32)
；第二個引數是對應的
caption
；第三個引數是
bool
型別的可選的控制引數。當第三個引數為
true
的時候，將可以從該型別所在的
assembly
中獲取資源，查詢名稱為
caption
的資源串來替換執行時的
caption
。乙個非常簡單的可選引數定義，解決了多語言化的問題。
當然，對於可以多選的詞典項，
也可以象
flagsattribute
那樣進行自動組合成集合型別。
列舉是領域中的乙個非常重要的元素，所以
kanas.net
從2003
年的第乙個版本開始，就支援列舉的對映。
顯然，域物件中定義為
gender
型別的實體，有機會透明地按照列舉的定義來儲存到資料庫中，
coding
的時候可以直接使用對應的標識，在
ui層也可以如願地按照客戶的要求顯示合適的內容，一切都是按部就班。
列舉詞典有三個共性。第乙個是業務無關性，無論在什麼地方引用，都不牽涉到相互的聯動關係。一旦列舉詞典項發生改動，則一定是列舉項本身的改動所引起，與引用者不發生任何關係。第二個是相對穩定性，大部分情況下是不需要頻繁變動的。第三個是共享性。引用可能發生在同乙個實體內的多個屬性中。這些共性決定了可能採用某種共同的、抽象的方式來處理。
我很早以前的專案實踐中採用的策略是單一表：
其中有兩個域復用：
category
為自引用，值為零的時候，表示本行為類別；值為非零的時候表示本行為對應類別的項。
fixed
為true
的時候，如果本行為類別則表示該類別不允許新增新項，否則為允許新增新項。如果本行為項，則表示本行不可編輯，一方面是業務中肯定能夠用到，另一方面可能是已經被用到了。
category
是不可新增的
(事實上新增
category
也不合乎邏輯
)，所有的操作只有新增新項和刪除作廢項兩種。項的操作有三種：修改名稱及可編輯狀態、刪除該項、合併到其他項。前兩個比較好理解，最後乙個項意味著可以刪除已經被引用的項，將引用改到指定的其他項中。例如有乙個項是
30~40
歲，後來有人錯誤地輸入了
35歲，當然要被合併了。記得當時我提供給使用者的錄入非常自由，可以隨意在乙個
combobox
中選擇列表中的項同時也可以手工填入乙個字串，如果該字串在該類別中不存在則在該類別中自動新增乙個新項。久而久之，五花八門的輸入都出現了，幸好我事先給管理員提供了合併項的功能，讓他感激不盡。
這種方式一直覺得很好使，於是在
kanas.net1.0
中加入了乙個自動的型別：
dictionary
。後來發現，這個類還是太簡單，稍複雜一點就無法處理了。於是在後續的版本中我取消了這個類。事實上，不同的列舉詞典型別並不像我設計的那樣只有可新增項和不可新增項那麼簡單，很可能不同的列舉詞典還必須承載其他的業務屬性。例如單位，除了名稱外還有換算關係，不同列舉類別間很可能還會發生一對多或者多對多的引用關係。不過可以肯定的是：列舉詞典項不同於普通實體型別的處理，在物件關係對映中也必須採用完全不同的方式。
細節決定成敗
剛剛結束asp的期末考，深刻體會那句細節決定成敗的至理名言。巨長的程式題寫的有種要崩潰的感覺，結果一交卷猛然發現，忘了寫單引號。其實這事情在人家來說是粗心，在對我來說，絕對是對細節的在意，導致低智商型錯誤的頻發。說道細節這事，班裡有三個女生，乙個太在意細節性，以至於一件很快能完成的東西，在其手裡作品...
細節決定成敗？
以下文字摘自donews資深作者 郭子威。1 拍 鐵達尼號 的時候，有八卦說，詹姆斯.卡梅隆要求在船上裝載來自歐洲的瓷器，然後在顛簸中全部摔碎，因為 歐洲貨才能還原現場氣氛 結果憑空多出來幾十萬美金的成本。最後 鐵達尼號 賣了18億刀票房。這則八卦，很容易聯想到 細節決定成敗 等偉大的格言。不過你想...
細節決定成敗
在程式設計師的世界裡，細節對於一位程式設計師來說是至關重要的，稍微乙個小的疏忽輕則會浪費大量的時間去定位 而對於一些應用在 重要領域的裝置上的軟體而言，這種重要性更加不言而喻了，醫療，軍事，這些方面的裝置的故障率是0容忍度的 對與很多剛入行甚至已經時行業大牛級別的人物來說，細節的關注 性都是必要的，...