我開始的新地方剛開始從頭開始開發一種全新的產品。他們正在應用程序服務中使用事務腳本，完全愚蠢的實體，以及帶有存儲過程的手動DAL（參數是nhibernate不能很好地優化sql，加載太多東西，不能很好地擴展到大型項目等等等等） ）。該應用程序應該是剛剛處於初期階段的巨大項目。從域模型到交易腳本
我來自一個位置，我正在做域模型，封裝了所有的業務邏輯，而應用服務只處理基礎設施+使用nhibernate加載模型並編寫腳本。
我真的相信用第二種方法會好得多。我打算做一個爲什麼介紹。我有大量的書籍/文章/個人意見，我可以支持......但更多的是「初級」，這可能沒有多大意義（我也是我最後一個地方的單一開發者）。
我在找的是一些經驗/技巧/更多資深人士失敗的項目的例子，爲什麼要交易腳本/手卷DAL是不正確的想法。
除了什麼Paul T Davies和Magnus Backeus都說過。我認爲，在一天結束時，這將是一個人與文化問題。如果人們思想開放，願意學習，那麼說服他們會相對容易。如果他們認爲你是「初中」（這是一個不好的徵兆，因爲唯一重要的事情是你說的話沒有多大/經歷你），你可以上訴到「上級機關」：
存儲過程都死了，你是不是only one who thinks so：
令我們驚訝的是，我們繼續在2011年 中找到實現存儲過程中重要業務邏輯的新系統。 編程語言通常用於實現存儲過程 缺乏表現力，難以測試，並且阻礙了清潔 模塊化設計。在特殊情況下，您應該只考慮在數據庫引擎中執行 的存儲過程，其中 是一個經過驗證的性能問題。
說服人們不願意改進和學習是毫無意義的。例如，即使你設法贏得一個參數並擠壓NHibernate，它們也可能會寫出與以前一樣的緊密耦合的，不可測試的，面向數據或者LINQ的代碼。 DDD很難，它需要改變很多假設，傷害自我等等。根據公司的規模，這可能是一場不值得開始的持續戰鬥。
Driving Technical Change是可能幫助你處理這些問題的書。它包括可能遇到的幾種行爲刻板印象：
祝你好運！
謝謝......都是好迴應。我已經閱讀了幾本提到的書，並計劃引用它們。 「初級」的意思是我的年齡，所以我的簡歷並不像其他人那樣廣泛，以支持我的觀點......所以我想要如何接近它的意見，而不是「讓任何人失望」 – maciek
好點。有時候我並不重要，你有什麼優點和缺點。團隊必須分享相同的觀點，如果你有幾個不開放的「自我」，那麼它有一個風險去爭取你的觀點。 –
不幸的是，Stackoverflow是一個非常注重技術的論壇，你所描述的這些問題（團隊協作，團隊願景，領導力，項目成功因素等）都是「軟」問題。我希望有類似這樣的論壇來處理像管理，項目，團隊協作等問題。非常有趣的東西，對於項目而言通常比所有「最佳實踐 - 技術 - 東西」更重要。 –
那麼總有兩面硬幣。 他們可能會有一些關於Nhibernate和性能問題的觀點。但總是有解決方案，比如加載策略，您可以準確地知道Nhibernate應該如何處理特定的關鍵查詢。 通過加載策略，緩存和sql索引調優，您可以在性能方面取得很大的進展。 但是ORM真正的好處是它減少了代碼庫並使其更加乾爽。使您的系統更易於維護。由於您不需要存儲過程，因此它也減少了「圖層」。
我已經在幾個項目喜歡你，相信我，他們面臨mainaince問題 *在應用服務可能是多餘的代碼，因爲你沒有，可以在一個地方把邏輯，而不是出現在的域核心幾種應用服務方法。
包含多個存儲過程的巨大DAL層。
邏輯很容易滑出到GUI
我可以讓列表更長......但我的觀點是，人們往往會選擇交易腳本有時只是因爲它很容易理解，開始與和，並且可以善於表現。 但通常問題發生在顧問，員工離開項目和維護團隊接管時。通常沒有明確的說明應該做什麼改變，而且我見過的大多數TS應用程序都被架構濫用。從開始開始，它們就是很好的應用程序，但是由於邀請您將邏輯放入SP，服務，GUI（因爲缺少受限的API，接口等）。
你跟着我？ /馬格努斯
PS你可以得到強大的性能和DDD與CQRS辦法...
我同意......我認爲這是一場噩夢。 – maciek
我要說服用材料對其進行備份是要走的路，這樣，他們不能用你的經驗不足爲一個論點（儘管聽起來你並不特別缺乏經驗或者初級！）。我的主要reccomendation是這本書：
在146頁，它指出：
「TS適合於簡單的場景中的商業邏輯非常簡單，更好，但不太可能改變並發展。「
這並沒有描述你正在使用的系統。
然後它繼續描述域模型，以及它爲什麼適合更大的系統。
我會懷疑是否明白它是交易腳本他們選擇？根據我的經驗，TS通常是沒有經驗的組織的默認選擇，他們甚至不知道甚至有選擇權。他們只是認爲'這是如何做'。他們目前的代碼有多成功和可維護？如果他們選擇大型項目的TS，我的猜測會是'不太'！當事情出錯時，他們是否責怪客戶改變規格？如果是這樣，這表明他們選擇的架構是錯誤的。
根據我的經驗，實施域模型的開銷很小。它比嘗試擴展和維護體系結構嚴重的系統要痛苦得多。另外，在這個時代，數據庫服務器應該能夠處理基於NHibernate的系統，而不會出現任何問題。如果它不能，那麼這是數據庫服務器的問題。他們打算如何單元測試這些存儲過程？我通常發現SP是開發者錯誤最大的一點。
就像馬格努斯說的，我可以繼續談論這件事。我不知道系統的細節，但是一旦使用了「巨大」這個詞，域模型就成爲最明顯的選擇。
謝謝...你連接的這本書正是我想給SP的「外界意見」，呵呵 – maciek
不用擔心，祝你好運！ –
祝你好運。我處於類似的情況。最糟糕的情況是雙方都在不同的方向拉項目。 – driushkin
謝謝。希望我能做出強有力的事例。我可以忍受一些交易腳本......但是用nhibernate/EF imho這樣的框架來編寫所有的SQL代碼有點荒謬和浪費時間（如果說框架被正確使用，我並沒有看到很多低效率他們）。 – maciek