Visual Studio功能可以實現(xiàn)修改測試代碼和方法，還有相關(guān)Visual Studio功能的策略。然而，我們要改變折扣策略Visual Studio功能，就要重新編寫一下代碼，還有一些文件配置的相關(guān)問題。

設(shè)計數(shù)據(jù)模型的重點不是去分析到底什么地方是可變的，什么地方是不可變的，業(yè)務(wù)會以什么樣的方式變化（OO里面經(jīng)典的Hotspot分析），所以整個系統(tǒng)慢慢會變成一堆數(shù)據(jù)，根本無法理解它真正的行為。

其實我要求不高，給我一個對象的世界，讓我實現(xiàn)業(yè)務(wù)，你去展現(xiàn)、去持久、去分布，不要讓別的東西來打擾我。當然，萬一我需要數(shù)據(jù)你也得給我，我還要做報表呢。呵呵。

看來你是比較傾向?qū)ο蠼?呵呵，這樣就引出對象建模與關(guān)系建模的爭論了 我是比較喜歡關(guān)系建模的，很簡單，我不會對象建模……（別拿板磚砸我） 關(guān)系建模的基礎(chǔ)是集合理論，而集合的研究在數(shù)學上是比較完善的，可以說，關(guān)系建模是有一個嚴密的理論基礎(chǔ)。Visual Studio功能這個基礎(chǔ)是相當簡單的－－至少概念是這樣。

簡單往往意味著高效。 而對象建模呢？我不清楚 基于集合理論的關(guān)系數(shù)據(jù)庫在處理數(shù)據(jù)的性能上是無可匹敵的，對象數(shù)據(jù)庫的效率絕不可能和關(guān)系數(shù)據(jù)庫處在統(tǒng)一水平線上。完全的面向?qū)ο髷?shù)據(jù)庫搞了十幾年了，始終無法打入主流市場，這是一個很主要的原因。

本不用討論Visual Studio功能?；趯ο蟮臄?shù)據(jù)庫倒有幾個，但我的看法實際就是關(guān)系數(shù)據(jù)庫的底層上加一個ORM，只是這個ORM做在數(shù)據(jù)庫端。 到底什么是對象建模呢？各位老大能否給我等掃掃盲？#t#

然后我們就可以修改測試代碼和方法實現(xiàn)，直到完全滿足以上的折扣策略。然而，Visual Studio功能這意味著如果我們要改變折扣策略，就需要重新編譯代碼，至少也需要修改配置文件。

如果這段邏輯存儲在一個數(shù)據(jù)表里，那么我們可以將訂單的價格傳入一個存儲過程，然后在表中查詢折扣數(shù)量。不過，當我們著手創(chuàng)建Visual Studio功能表格和存儲過程時，很快就會遇到一些問題。這個表格的結(jié)構(gòu)是怎么樣的?我們該如何表示一個范圍的最低值和最高值?如何處理邊界情況?