1. 首頁
  2. 問答
  3. 針對SQL Server的ORM推薦

針對SQL Server的ORM推薦

2009-06-08 113 views
2

我將在我的項目中使用SQL Server，爲此我想選擇一個ORM。我有一些NHibernate as an ORM的經驗。實際上，鑑於該項目（MySQL後端）的性質，NHibernate的確是，只有的選擇。針對SQL Server的ORM推薦

我也使用strongly typed dataset as my ORM，這是微軟Access作爲後端。我也有一些LINQ2SQL的經驗。

現在，我知道，所有路徑導致羅馬;很多ORM可以很好地處理sql server。但我想在

  1. 開發時間方面最好的ORM。也就是說，拖放設計器將我的實體類映射到數據庫模式。所以，如果我改變我的模式，我的實體類會自動更新。
  2. 多個數據庫支持。 ORM必須能夠以最佳方式處理多個數據庫查詢。此外，多個連接字符串支持也必須輕鬆完成。
  3. 擴展性。如果我想添加一個查詢，而不想混淆設計器文件;他們是一個脖子上的痛苦惹惱。

可能是這樣。有任何想法嗎？

來源

2009-06-08 Graviton

+0

成本是一個問題？ – 2009-06-08 14:56:07

+0

想一想......不。 – Graviton 2009-06-08 15:12:11

+0

說真的，去LLBLGen。要求＃1殺死NHibernate（除非你是唯一的開發人員，或其他人都有經驗），＃2有效殺死Linq 2 SQL和數據集。 – 2009-06-14 03:14:35

回答

5

根據他的要求，LLBLGen是要走的路。請注意，LLBL和NH之間存在很大差異。 LLBL是ORM/Generator，你的實體將有很多預先生成的代碼，並且它從數據庫開始。所以如果拖放是你想要的，那麼一定要用LLBL。

來源

2009-06-08 15:01:35 epitka

0

ADO .NET Entity Framework？

這似乎符合每一項要求在一定程度上，雖然不能完全

來源

2009-06-08 14:50:50

+0

我等待第2版。我的印象是，EF的V1並沒有準備好黃金時段。 – 2009-06-08 14:54:54

3

LLBLGen可能是一個選擇。

它有最好的設計應用程序之一，它功能非常豐富。

來源

2009-06-08 14:53:40

0
  • 類型化數據集：0/3
  • 的LINQ to SQL：三分之一它可以做第3項。它可以做一些項目2：針對不同的查詢多個連接字符串是沒有問題的 - 但如果你想多個數據庫在一個查詢中，您必須使用視圖或存儲過程才能到達那裏。第1項是胸圍 - 如果您更改模式，您必須自己刷新設計器中的實體。

來源

2009-06-08 14:55:46

0

強類型數據集不應被視爲OR/M工具。 （強類型）數據集只是數據庫中數據的內存中表示形式（1：1表示形式）。

當您使用OR/M時，將數據庫中存在的數據與內存中的業務對象（不必是數據庫模型的1：1表示形式，可以包含其他數據邏輯等）。可能你可以看一下MS Entity Framework，但據我所知，NHibernate在功能，性能，抽象等方面仍然是更好的解決方案，並且你可以更好地控制它（但是，這可能會帶來一點成本（在開發時）（沒有拖放的設計，但是你可以從你的映射生成你的數據模型）

（延遲響應 - 網絡故障...）

來源

2009-06-08 15:04:48

相關問題

 相關問題