LightSpeed——針對.NET的商業化ORM

LightSpeed是 一種針對.NET的商業化ORM，它擁有多種特性，像實體序列化、健壯的VS設計器、內建的LINQ支持、對DTO的支持等等。咱們聯繫了 Mindscape（開發LightSpeed的公司）的共同創始人John-Daniel Trask，對產品進行了深刻探討，並在整體上對ORM進行了討論。

InfoQ：如今已經有了不少種開源或者商業化的針對.NET的ORM產品，你爲什麼決定要建立一種新的產品呢？

JD：LightSpeed是Mindscape的第一款產品，咱們是基於之 前在IT服務領域的經驗來建立的。咱們使用過現存的對象-關係映射器（ORM），可是那時在.NET領域並無太多選擇。要麼使用NHibernate， 要麼就從頭建立本身的工具，而不少組織都構建了本身的ORM。咱們以爲現存的ORM在性能上和使用的體驗上都不是很好，同時也相信業務部門會樂於爲優良 的、易於學習、高性能的ORM付費，相對於其它產品或者DIY的方法來講，那會節省他們不少的時間。

InfoQ：你認爲ORM應該處理的關鍵問題有哪些？

JD：ORM的基本目的就在於爲數據庫和對象世界提供良好的映射關係，因此固然須要把這一點作好。

除 此以外，性能很是重要。最多見的抱怨就是ORM的性能很差，儘管咱們並不確信是那樣。好的ORM能夠將不少技術自動化，像對象融合（object hydration）、查詢批處理、有效地生成查詢、熱切載入（eager loading）、智能緩存等等，那會讓基於ORM的代碼和手動編寫的代碼執行得同樣快。

生產率也是關鍵的問題。使用ORM不是要節省 計算機的時間，而是要節省開發時間——更快地構建應用，消除各類錯誤、執行好的實踐、讓快速可靠的測試和部署成爲可能。例如，LightSpeed會自動 對查詢進行參數化，那和手動編寫的SQL相比，會避免大多數SQL注入的***。咱們都須要花費時間建立模型來實現強驗證，或者數據綁定通知，或者編輯回 滾。有了LightSpeed咱們努力把這些類型的問題歸到「拿來就用（it just work）」一類。從原始的數據訪問代碼轉爲使用ORM就像從彙編轉爲C#或者Java同樣。可能你會放棄一點兒性能，可是比你想象的要少，而你換回的是 上百倍的生產效率。

最後一點特別針對.NET ORM的是對LINQ的支持。咱們已經大量使用了LINQ，很難想象如何在沒有它的狀況下工做。因此擁有真正穩定的LINQ提供程序很是重要。構建壞的 LINQ提供程序很難。構建好的LINQ提供程序更難。多年以來咱們一直在改善LightSpeed中的LINQ提供程序，這是咱們值得自豪的一點。對 LINQ的支持已經成爲.NET開發者工具箱中指望獲得的特性，因此一種ORM中不支持LINQ或者支持不好都是不可接受的。

InfoQ：LightSpeed支持相似於EF使用POCO實現的代碼先行（code-first）之類的功能嗎？

JD：模型先行和代碼先行在概念上很是相似，它們都是說開發者在數據庫結構存 在以前以代碼的方式來講明模型。LightSpeed固然支持模型先行，並且早在多年前就已經支持，然而，那依賴於使用LightSpeed的模型設計器 建立和管理數據庫的變動，並基於定義的模型來建立類。EF的代碼先行比模型先行更進一步，它讓開發者能夠只編寫類自己，而後就能夠從那些類生成對數據庫的 更新，而不須要設計器。咱們幾乎沒有收到添加這種支持的請求，由於它會形成生產力的極大下降，那是因爲須要你手動編寫全部應用程序所需的實體，而後才能創 建類。

關於POCO，咱們不會把它設置爲默認的選項。LightSpeed實體依賴於「Entitiy」基類，坦白說， 這是由於咱們相信它會爲開發者帶來巨大的價值。記住，ORM是與生產力相關的。咱們看到喜歡POCO的人們花費多個小時來管理T4模板，只是爲了生成支持 的類，比方說INotifyPropertyChanged，或者跟蹤改變了的字段，或者處理驗證（或者更壞，手動編寫全部這些代碼而不使用代碼生成 器！） 唉，你有更好的方法，不須要手動編寫那類代碼。咱們的經驗是，天哪，用額外的繼承層次來換取這些內容是很值得的：LightSpeed的開發者一般會喜歡 它，由於他們能夠專一於解決實際的問題，而不是手動繼承或者編寫他們本身的樣板代碼（plumbing code）。

這麼說，分佈式場景會從POCO得到很大的益處，所以LightSpeed支持兩種方法來進行分佈式開發：

• 經過線（wire）和「DistributedUnitOfWork」進行實體序列化，從而開發者能夠在客戶端編寫LINQ查詢，而後 LightSpeed會自動把它傳送給服務器，運行查詢，而後再把結果發送回來。咱們還會作一些聰明的事情，像只把變動的實體發送回來，從而讓速度更快。 這種方法功能更完整，而且會被視爲「有魔力」的。
• DTO——LightSpeed設計器不只能夠爲用戶生成DTO，並且咱們會提供方法，使得把DTO導入到服務器上徹底成熟的Entity對象中更加容易。這很簡單，不那麼神奇，可是有些開發者更喜歡這樣。

InfoQ：關於自動遷移狀況如何呢？

LightSpeed支持比自動遷移更好的功能。

LightSpeed是惟一一種擴展了Visual Studio，添加了集成的schema遷移管理的ORM。這包括捕獲變動，顯示存在什麼樣的遷移，針對數據庫執行它們，並生成變動腳本（以任何你喜歡使 用的數據庫）。固然，服務器上不該該安裝Visual Studio，所以咱們對於生產數據庫會包含命令行工具來運行遷移操做。或者你可使用一種API把它集成到應用程序當中。

遷移只是事情的一部分——一旦你肯定模型的改變是你所須要的，那麼一般就會作出遷移。LightSpeed設計器從 咱們發佈的時候就支持名爲「360度的數據庫往返（360 database round tripping）」特性，用戶很是喜歡這種特性。它的意思是，若是你是喜歡使用模型先行的開發者，那麼你就能夠先對領域建模，右鍵點擊「更新數據庫」， 而後LightSpeed設計器就會在開發數據庫和模型之間執行尋找差別的操做，並讓你確認是否想要應用變動。當完成的時候點擊「OK」，數據庫就更新 了。

可是若是你使用數據庫先行的方式呢？ 很簡單，右鍵點擊你的模型，選擇「從數據庫更新」，LightSpeed的模型設計器就會找到變動，展現給你，讓你確認你是否想要應用到實體上。最神奇的 事情是，你可使用混合的方式，若是某些開發者喜歡模型先行，而另外一些喜歡數據庫先行，他們能夠按照喜歡的方式工做，一切均可以同時進行，那樣就會生效。

InfoQ：你曾經在一篇博文中提到，LightSpeed在單獨一個實體模型設計器能夠支持最多2000個實體，而且還可以保持用戶的友好性，請你說明一下這是如何達到的。

JD：在一個模型中放2000個實體對用戶來講永遠都不會是友好的，可是咱們已經作了不少努力幫助用戶使用很是複雜的模型。

例如，咱們提供了一種快速的方式在模型中查找你所須要的實體——只須要鍵入它的名字，咱們就會進行過濾，並找到匹 配的實體。而後，你能夠對其擴展，以包含相關的實體或者整個集合。若是你想要看到整個子領域——比方說銷售或者物流——而不是單獨的集合，那麼你能夠對實 體設置標籤，並經過標籤來過濾。因此咱們很容易就能夠從模型返回到你剛剛感興趣的那幾個實體。你還能夠經過多個文件來擴展模型——例如，每一個子領域一個文 件——那並不是是整合的方式，可是，若是多我的員同時操做模型的不一樣部分，那有助於解決源代碼控制的問題。

實體着色是一種看起來很微不足道的特性，可是對於大型的模型可以起到幫助。一般在你的模型中會有相對較少的關鍵業務實體，而模型的其餘部分都圍繞這些關鍵實體。以可區分的顏色來顯示那些實體，這樣一會兒就可以很容易地找到它們——它們在各類噪音中顯得很特別。

在低層次，咱們還在快速獲取數據庫元數據方面付出了不少努力。例如，咱們避免拉取不須要的表的元數據——當你處理不規則的遺留數據庫時，這會致使很大的不一樣。

因此這意味着即使在數據庫更大的狀況下，咱們也能夠高效地完成schema的round-tripping。

InfoQ：對於當前使用NHibernate或者實體框架的應用程序來講，是否有一種簡單的遷移方式，而不須要對代碼作出太多變動？

JD：這在很大程度上取決於開發者如何創建應用程序的架構。

如 果開發者使用了LINQ（例如，使用實體框架或者LINQ to SQL），那麼就很容易。咱們有的客戶只花費了幾個小時，就把構建在實體框架上的大型應用程序轉換爲LightSpeed。之因此簡單，是由於若是查詢已 經在LINQ中，那麼就不須要從新編寫，用戶只須要使用LightSpeed UnitOfWork來替換會話對象，把模型遷移到LightSpeed模型，並對應用程序添加一些配置。相反，若是大量查詢邏輯都是用 HQL（Hibernate Query Language）編寫的，那麼你就有大量工做要作！

對於模型遷移來 說，LightSpeed包含了一些特性來幫助把實體框架和LINQ to SQL的模型遷移到LightSpeed。把EDMX文件或者LINQ to SQL模型文件拖拽到LightSpeed模型的界面上，就會讓LightSpeed設計器讀取模型並自行生成。然而，要記住，模型遷移一般只是過程的開 始而不是結束。測試很重要——例如，你可能發如今LINQ提供程序，特別是帶有很是複雜的查詢的提供程序中會有區別。

就像在全部遷移過 程中同樣，你會想要避免受到目標平臺的影響。例如，你可能想要把你的驗證代碼遷移到集成的驗證框架中，設置熱切載入（eager load）使你的查詢效率更高，諸如此類。可是在通常的LINQ語法和模型導入支持之間，至少嘗試遷移到LightSpeed是很容易的，而後就能夠看下 它是否適合你的應用程序。

InfoQ：依你所見，哪些一般須要的特性不在ORM的責任範圍以內，爲何？

JD：咱們遇到過一些開發者，他們但願ORM可以徹底取代與數據庫交互的工 做。例如，要求ORM管理數據庫複製，或者是一些一般是數據庫關注的問題。儘管這些特定的特性不在ORM的範圍以內，而且理論上能夠添加到其中，可是不多 有用戶會利用這些特性，所以包含那些特性在成本上是不合算的。大多數那類特性咱們是不會支持的。

chaunceyhao