2010-12-17 52 views
0

目前我基本上引用添加Microsoft.Practices.EnterpriseLibrary.Common。數據.ObjectBuilderC#替代或更多當前數據訪問,則企業庫

我發現自己創建擔任班級像「產品」,那麼有另一個類,使像產品列表:

public class Products : List<Product> 
{ 
    public Products() 
    { } 

    public void SelectAll() 
    { 
     Database db = DatabaseFactory.CreateDatabase(); 

      using (IDataReader r = db.ExecuteReader(cmd)) 
      { 
       while (r.Read()) 
       { 
        this.Add(new Product(Convert.ToInt32(r["PRODUCT_ID"]), 
             r["NAME"].ToString()) 
            )); 
       } 
      } 

    } 

} 


Products p = new PRoducts() 
p.SelectAll(); 

現在我有我所有的產品,這是很好的。

這是好的,但我已經使用了幾年。我聽說過LINQ和實體框架,但並沒有真正採取與nHibernate一起玩的步驟,但沒有真正採取任何。 還在使用這種方法是錯誤的。

回答

2

堅持使用你所知道的東西,只要它有效就沒什麼問題。

但是,我會建議學習你提到的ORM並理解他們試圖完成的任務。

你永遠不應該做的就是停止學習。看看新的框架和開發方法 - 如果沒有別的,它會讓你成爲更好的程序員。

0

不,繼續使用適合您的東西並沒有錯。

企業圖書館仍處於積極的發展階段,可能還會繼續使用相當長一段時間。我們廣泛使用它,並將在可預見的將來繼續這樣做。

我建議您不要理解實體框架等各種各樣的東西,除非理解其中的各種選項可以爲您做什麼。

+0

我知道你的意思,在'真正'的項目中,當舊的工作正常並且你很清楚時,很難轉向新的方法。繼續玩,但我想這是下一步。 – Robert 2010-12-17 14:33:28

+0

@Robert:作爲一個側面說明,我們基於使用企業庫,從我們的對象模型中構建了一個工具,該工具可以編寫我們的DAL代碼。它甚至爲我們編寫所有正常的存儲過程(保存,獲取,刪除)。在我們看來,這比使用像LINQ這樣的常規ORM工具要好上千倍。 – NotMe 2010-12-17 14:46:57

1

使用EntLib DAAB對您的數據訪問層沒有任何問題,特別是如果您只有幾個類/表。

不過,也有使用ORM如LINQ2SQL,EF 4和最新版本的NH的一些顯著的好處:

    數據
  • 自動生成訪問者和實體代碼
  • 延遲加載
  • 支持LINQ表達式樹 - 這允許在沒有任何SQL編碼的情況下查詢具有極大的靈活性(儘管警告對正在執行的SQL的可見性較低 - 這可能會影響性能)

在大多數情況下,您可以使用上述ORM之一完成90%的DAL,而對於良好的「控制」級別,您可以手動構建SPROC。在大多數情況下,您仍然可以將SPROC連接到ORM實體。

+0

+1提及SQL的可見性和潛在影響。 – 2010-12-17 14:32:37

0

以這種方式進行數據訪問絕對沒有錯。它使您能夠最好地控制執行的語句以及數據如何通過代碼流動。

像EF或Hibernate這樣的OR-Mappers在某些情況下給你更多的舒適,但是它們也有它們的缺點。

0

它不是「錯誤的」 本身,但使用這種方法VS的對象關係映射器(ORM)等EF或NH是:

  1. 高度勢在必行風格(相於聲明 - 您所關心的「如何做」比「什麼」)
  2. 更難看了
  3. 更難以維持既因爲它是更難以閱讀和因爲在數據庫中的變化可以引起變化的級聯整個數據訪問代碼庫
  4. 更難以測試

我不會建議重做整個,工作代碼庫中的ORM的工作,但它是值得我們學習和理解。我建議首先看一下LINQ-to-SQL,在一個示例項目中,當然,因爲這是一種輕量級的「小弟弟」ORM,但開始使用起來非常快。從那裏,你可以轉到EF和/或NH。在感覺和工具方面,實體框架與L2S更類似,而NHibernate的學習曲線更陡峭,但功能更強大/更靈活。

同樣,使用企業庫和數據收集器沒有任何問題,但是使用ORM有真正的優勢和節省時間,最值得注意的是數據訪問的「骯髒工作」得到了關注,並且幾乎可以保證缺陷更少,並且比手動數據訪問更有效。這就是說,對於數據庫使用有限的非常小的項目,所有添加的抽象可能不是必需的,直接的ADO.NET將會更快,更容易。