要採取哪種DAL方法？

ActiveRecord通常太受限制。然而，就團隊中每個成員在使用ORM方面所持的觀點而言，我處於困難的境地。我們目前使用的是一個非常基本的ActiveRecord，遺憾的是我主要是用一些基本的代碼編寫的。我想爲我們構建一個新的DAL，但避免了ActiveRecord的限制，所以DDD更是如此。但是我對作戰的點（包括舊派開發商和我很年輕）：要採取哪種DAL方法？

團隊負責開發

是贊成的存儲過程，但不洽...一些就拿一張表格SELECT * FROM公司和一些得到SELECT C. *，O.OtherTableValue FROM公司C ...（非常令人沮喪）
真的不知道一些最新的ORM工具的好處
不會承諾任何工具都是「太嚴格」，如果有問題，你會怎麼做？

DBA

不喜歡動態SQL
不喜歡SELECT *

我並不是說上述是關閉的限制，其更convicing否則。我相信我們可以通過使用ORM來大幅提高效率，但是否則很難說服他們。如果我能爲這些領域的某些領域提供證據，我可能能夠說服他們，甚至通過在不知情的情況下實施，然後看到好處。

您可以給我什麼建議來幫助我的情況？我相信很多開發者會遇到這個問題，不能選擇他們想使用的架構。

來源

2010-08-06 user203538

我認爲您的團隊領導需要承諾保持一致或在ORM研究項目上花費一些時間來提出建議。換句話說，一個不一致的和設定的團隊領導者不應該擔任這個角色。其次，我傾向於同意你的DBA出於多種原因。只要他/她足夠靈活，就可以知道有些情況下動態SQL可以更好地解決問題。

針對您的具體情況，我想請您的數據庫管理員制定存儲過程每次都要使用的法律，除非在個案基礎上提供理由並通過策略和監控加以實施。這將解決一致性問題。也許那時，就手中的這一政策而言，ORM看起來比將所有內容手寫到團隊領導者手中更誘人。

來源

2010-08-06 16:44:43

關於團隊負責人 - 他不會改變自己的方式，他沒有真正的工作興趣來讓事情變得更好......它會做更多的事情。不應該做我認爲的工作，但不是我的呼籲，所以我必須做關於DBA，他沒有真正從應用程序中得到問題，因爲數據庫是他的背景，我認爲他學到了一點，並沒有從那以後，因此還沒有了解到新的變化，即動態sql現在不是'一直'不好。 – user203538 2010-08-13 10:51:10

然後我建議你閱讀「死亡之旅」一書。可能會幫助你的情況。 – 2010-08-13 13:38:39

看起來像一個新的DAL或其他工作 – user203538 2010-08-13 16:20:07

首席開發人員應該傾聽DBA的意見。「SELECT *」不好。從關於主要開發人員的重點來看，這聽起來像是你有一場熟悉的艱苦戰鬥。有時候，在這種情況下，阻力最小的路徑是使用ORM（如NHibernate）實現某些東西，併爲團隊安排某種演示。

鼓勵他們提供他們的意見，特別是來自首席開發人員，DBA和任何其他可以說話的人。在您瞭解更多信息時，他們可能會有合法的抱怨，可以使用該工具實際解決。另一方面，他們可能只是因爲沒有合乎邏輯的理由而對它不利。如果是這樣的話，最好找出來，因爲這可能意味着沒有贏得反對他們的這個論點，因爲他們並不是真正的辯論。

來源

2010-08-06 16:45:08 David

非常多的它不是真正的辯論......正如我上面評論，他們學到了一些東西，並沒有說5-10年，並認爲這仍然是最好的方式。我認爲贏得和改進事物的唯一方法是推出我自己的DAL ..但是從哪裏開始，這是一個很大的任務。我知道人們說不，但我真的不認爲我有很多選擇:( – user203538 2010-08-13 10:53:35

他們對使用ORM有什麼異議？如果他們不只是固執而頑固，那麼如果你知道他們特別反對你並解決這些問題。像其他人一樣，我認爲你的DBA是正確的。但是如果他關心動態sql中的SQL注入，ORM就會緩解這個問題。選擇*應該是發射的理由。

我很想知道如何在LINQ-to-SQL或亞音速或nhibernate上使用某些東西。使用ORM顯示開發速度更快，更清潔。

來源

2010-08-06 17:07:35 nportelli

關於創建一個新的DAL，哪個ORM最好基於它？？如果它看起來我已經創建它，那麼他會使用它，所以只需要一個起點，調整它，並從其他ORMs一些想法。亞音速似乎是一個簡單的代碼庫..思想？ – user203538 2010-08-13 16:32:05

要採取哪種DAL方法？

回答

相關問題