2011-07-30 25 views
1

我正在研究一個有大量表單的項目,用戶將填寫這些表單來創建最終報表。大多數這些問題都是多種選擇。我正在爲應用程序中的類努力使用適當的架構。使用枚舉在面向對象應用程序中的範圍選擇

爲了交談,可以說這是一個車禍報告。面向對象的方法將決定我們基於每個問題中包含的信息創建結構。所以我們有類似「車輛」,「事故」等的類。但是,如何向用戶提供4種答案供選擇,例如「車輛在碰撞時行駛的速度是多少」等問題呢?

  • 不到10英里每小時
  • 11-30mph
  • 31-50mph
  • 超過時速50英里

什麼是存儲在一類這個信息的正確方法是什麼?我的第一個考慮是枚舉:

enum CollisionSpeed { 
    LessThan10, 
    ElevenToThirty, 
    ThirtyOneToFifty, 
    MoreThanFifty 
} 

但是,這感覺很髒,因爲它是基於演示文稿的數據結構。同樣,如果他們改變了範圍,我們也必須改變枚舉。

所以問題是,你如何處理像這樣的範圍選擇與面向對象的方法?

謝謝!

回答

1

如果是真的通用,你有大量的問題,你可以invastigate非規範化是否是正確的做法。您可以提供一個抽象層,而不是逐個建立每個單獨的主題,以便例如商業用戶可以在稍後沒有IT介入的情況下進一步添加問題。簡單示例(僞編碼):

class QuestionEntity { 
    String question; 
    enum type; // e.g. open question (freetext), closed question (check boxes), etc. 
    String[] values // if it's a closed question 
} 

如上所述,這相當簡單。因爲我確實知道你的確切要求,所以我不能判斷你的情況是否合理。實際上它是爲您的特定業務用例開發DSL。

也許答案並不像你期望的那麼具體,但是當我讀到你的問題時,我想起了......

+0

謝謝你的建議。我考慮過這種類型的實現,但是擔心數據庫體系結構(如果它遵循類似的體系結構)。因此,不用像SELECT * FROM Accidents WHERE CollisionSpeed = 1那樣在邏輯上查詢表,您最終會選擇'SELECT * FROM Answers WHERE QuestionID = 4',這對於數據庫管理員來說很難在數據庫之外輕鬆提取數據應用程序。此外,我們最終使用ID來拉取QuestionEntities集,在這些集中,我可以看到它們與enums本身的magiC#s一樣有問題。 – jkriddle

+0

@ 100acrewood:當然,我理解你的論點。這是我們必須爲抽象付出的代價。順便說一句:關於枚舉;我不會去使用枚舉,而是將數據模型標準化(如表COLLISION_SPEED_VALUES),這又使模型更復雜:-) – home