從LINQtoSQL轉移到Nhibernate的參數？

Question

Backstory：大家好，我只是花了很多時間在這裏和其他網站上閱讀了許多LINQ和Nhibernate的主題。我在一個由4人組成的小型開發團隊工作，我們甚至沒有任何超級經驗豐富的開發人員。我們爲一家擁有大量技術需求但沒有足夠的開發人員來實施它們的小公司工作（現在招聘更多的員工是不可能的）。

通常我們的項目（每個項目都很小）已經單獨編碼，並且沒有真正分層，代碼沒有被重用，沒有類庫，我們只是使用LINQtoSQL .dbml文件來爲我們我們實際上甚至不使用對象，而是傳遞值和東西，我們使用對象的唯一時間是插入到數據庫時（甚至沒有查詢，因爲你不需要將它分配給一個類型，只需綁定到gridview）。儘管如此，正如我所說的，我們公司有很多技術需求，但沒有人可以來找我們一年，我們將有大量的工作來實現所需的功能。

那麼我已經決定通過創建類庫和實際添加圖層到我們的應用程序來改變這一點。有一個很好的機會來製作一些具有全面功能的優秀應用程序。我試圖通過仍然使用LINQtoSQL作爲ORM，並且仍然使用VB作爲語言來中途遇見這些人。然而，我發現它在處理LINQtoSQL中很多事情的時候很乏味，我發現在Nhibernate中很容易（自動處理會話，比表達式樹更容易創建條件，通用動態查詢更簡單等）。 ..

問題：我該如何說服我的首席開發人員和其他高級程序員切換到Nhibernate是件好事？控制我們的域對象是件好事？能夠實現接口是一件好事嗎？我已經嘗試過使用這個優點，但是它們並沒有被他們理解，因爲他們從未以真正的OO &分層的方式進行編程。

也是這個我可以看到的反計數參數之一是sqlMetal自動生成這些類，因此它節省了大量的時間。除了說在基礎設施上花費更多時間使其更具可擴展性和靈活性是好的之外，我無法真正抵制這種情況，但他們看不到如何。每個人都知道每個人的特點和優點（有點足夠我相信），但是我需要適用於我的背景的論點，所以我提供了背景故事。我想我不是一個很好的論辯者。 （注意：對於所有的LINQtoSQL愛好者，我可能不會像LINQ那樣超級熟練，但我覺得很麻煩，因爲您需要爲動態查詢下載一些額外的庫，而這些動態查詢默認情況下不支持guid比較，並且我還發現在數據上下文管理方面更新實體的方式也很麻煩，所以我可能會吮吸嘻哈。）

Answer 1

在我看來，Linq2Sql可能更適合您試圖擺脫的開發模式。當你進入一個更豐富的領域模型時，轉向NHibernate的原因將變得更加明顯。我可以看到的一些最大的問題是：

1. Linq2Sql不像NHibernate那樣是可擴展的（攔截器等）。
2. Linq2Sql只能真正處理父母/子女的急切加載。一旦你擊中父母/子女/孫子關係，事情就會開始走下坡路。
3. NHibernate的HQL使得控制棘手查詢的SQL如何比Linq語法更容易控制。

Answer 2

轉換到新技術的主要論點將永遠說服人們是：「在項目y中將您的團隊保存約x個小時」。他們會將其與「學習新技術花費z小時」的論點進行比較。這將是你的團隊的心理轉換和學習曲線。當你在很多小項目上工作時，比較「學習時間」和多個項目的「節省時間」可能是正確的。有時將現有項目轉換爲新技術是值得的，有時最好在新項目中使用新技術。通過表明您已準備好使用新技術並思考如何爲您的團隊提供幫助並指導您更快地學習新技術，從而使您的論點更加強大。