Linq to SQL仍然是開發應用程序的可行選擇嗎？

Question

在使用Ruby on Rails進行簡短（偶爾持續）的定製後，我正在閱讀.NET的東西。我想知道，在爲新應用程序選擇ORM時，如果LINQ仍然是一種選擇，或者我應該學習像NHibernate這樣的東西，而這種東西似乎仍然很強大。我知道Linq基本上被Entity Framework所包含，但是當我嘗試EF（這是前一陣子）的時候，我發現它太重，太「鼠標驅動」（即很多玩弄設計師）。我已經觀看了NHibernate的幾個簡短的屏幕錄像，我喜歡分離它強制實施的關注點，以及模型可以保持清潔的想法。

Linq的語法雖然不錯，但它不是一個真正的ORM，我不想看看學習的東西基本上已經過時，當我可以學習一些正在使用或將要使用的東西時（EF和/或NHibernate，例如）。因此，Linq仍然是應用程序應該考慮使用的東西（讓我們假設一些中等的複雜性;不是一個簡單的應用程序，但不是一個巨大的任務;周圍像37Signal的Highrise一樣複雜的基於Web的應用程序）還是有更好的東西值得一看？

Answer 1

您需要區分作爲程序設計語言概念的LINQ（Language Integrated Query）和作爲面向SQL Server的數據庫映射（「ORM」）工具的Linq-to-SQL。

LINQ這樣 - 作爲一項技術 - 絕對是在這裏 - 毫無疑問。

Linq-to-SQL有點不同，因爲微軟不會將更多的資源投入到其進一步的開發中。對於.NET 4.0，他們出現了一些增強和錯誤修復，但沒有什麼重大的。

因此，如果您的應用程序很小，並且您沒有真正設想它在生產中保持10年或更長時間，那麼您仍然可以選擇Linq-to-SQL作爲一種非常可行且實用的技術，以便快速啓動和運行，很容易 - 只要你只需要SQL Server作爲你的數據庫後端。

如果您處於更加面向企業的環境中，如果您的應用可能會持續10年或更長時間，或者您需要異構數據庫後端，或者需要映射數據庫中完全不同的物理架構和對象域模型 - 然後選擇ADO.NET實體框架和Linq-to-Entities。它提供了比Linq-to-SQL更多的優勢 - 以更高的學習曲線爲代價。

你挑 - 這兩種技術是絕對偉大的方式在今天構建應用程序，並在未來2，3，5歲 - 在那之後，所有的賭注的:-)

熄滅馬克

Answer 2

我相信StackOverflow（仍然）在LINQ to SQL上運行，所以說它不是一個可行的選擇會有點奇怪。我在WPF和ASP.NET中做了一些演示，它非常簡單易用。你無法用直接的SQL做什麼。

Answer 3

LINQ的不一個ORM和Linq很棒。如果可能的話，你很可能要使用Linq。

LinqToSql是一個ORM，雖然它是非常明亮的功能。它爲您提供基於SQL Server數據庫定義的基本（主要是一次性）活動記錄類型數據層類的代碼生成。雖然它支持一些基本的ORM功能，但大多數其他任何你想要的，你都必須創建自己。

EntityFramework也是一個ORM。雖然它共享LinqToSql的一些限制，但它也會做一些更好的事情，有些事情更糟糕。目前的V1有許多限制，其中一些將在Visual Studio 2010推出的下一個版本（V4）中解決。

LinqToSql或EntityFramework都不是成熟的，經過驗證的ORM。兩者都有很大的缺點，您可能會遇到大多數「正常」軟件開發項目。

NHibernate提供比微軟的ORM更多的功能，你會發現它幾乎適用於任何「真實世界」的情況。如果你喜歡ActiveRecord模式，並遵循微軟的ORMs，那麼NHibernate也支持這種模式，Castle ActiveRecord。

這三個ORM都支持Linq。

一個字的謹慎。根據您將數據層與其他層分開的程度，在項目中間切換ORM可能會很困難且代價高昂。例如，你不能輕易地從LinqToSql開始，然後在你遇到LinqToSql的許多限制之一時切換到NHibernate，除非你真的很聰明地將你的ORM與其他實現分開，根據ORM可能非常困難。

Answer 4

對於需要實現不是非常複雜的數據庫訪問層的開發人員來說，LINQ to SQL是一個方便的選擇（這是比較常見的情況）。
我公司正在不斷完善LINQ to SQL tecnology for Oracle, MySQL, PostgreSQL and SQLite databases的執行情況。

Answer 5

我想補充一點，你在.NET上的L2S是one of the fastest options。考慮到支持的LINQ功能的質量，它可以成爲廣泛案例的最佳選擇。