與n層設計(BLL / DAL)相關的小巧玲瓏

bll business-logic-layer dapper data-access-layer

我有一個關於Dapper的基本邏輯問題。

在嘗試做最好的設計實踐時,Dapper是否模糊了DAL和BLL之間的界限?許多建議是DAL應該對BLL一無所知,並且DAL應該只返回BLL應該轉換為某些有用對象的一些blob數據。

我想在這裡得到一些專家對Dapper適合的意見。

這是一個偉大的項目,並且運作良好,但它似乎與BLL緊密結合。我個人並不反對這種方法,但是想知道1)是否有更好的方法來解開Dapper和BLL,或2)如果它不是真正的問題,因為我們不打算離開MS SQL。

謝謝。

編輯:回應馬克的評論:

Dapper是一個很棒的產品,這不是對它的任何影響......我的意思是,當你執行一個查詢時,它通常會返回一個特定類型的集合。

var dog = connection.Query<Dog>("select Age = @Age, Id = @Id", new { Age = (int?)null, Id = guid });

在這種情況下,查詢將返回Dog的集合。

如果Dapper部署在DAL層中,則必須具有對BLL層的引用,以便了解它將返回的對像類型。

許多建議是DAL永遠不會對BLL有任何了解。我只是試圖確定部署Dapper和保持良好的N層設計結構的最佳實踐。

我知道這有點主觀,但如果它足以支持Stack Overflow,那麼你們都必須找到在設計良好的環境中部署它的最佳實踐方法。

編輯:注意到由於HTML符號,查詢示例中未顯示“Dog”的類型。

再次編輯以響應Hogan的評論:我的問題的核心與上面的代碼行將在DAL中的想法更相關。為了清楚起見,我們可以假設我們有一個DAL和BLL作為單獨的類項目的解決方案。現在,當這行代碼進入DAL項目時,DAL必須引用BLL來獲取“Dog”對象。這種交叉依賴性可以嗎?或者只是最常用的Dapper的方式?或者這是一個不好的做法,而不是使用Dapper的最佳方式?我知道很多'純粹主義者'會說DAL不應該知道關於BLL的任何事情......依賴於上面一行中的“狗”對象會違反這個原則。但是,上面的行似乎是Dapper最常見的示例用法。

一般承認的答案

把dapper想像成一個數據庫架子 ,閱讀: http//samsaffron.com/archive/2012/01/16/that-annoying-insert-problem-getting-data-into-the-db-using-dapper

Dapper不會強迫您使用存儲庫或任何特定模式。

它不會告訴你在哪裡放置業務邏輯。如果您想使用數據訪問代碼混淆業務邏輯,那就這樣吧。如果你不這樣做,不要。小巧玲瓏是不可知論者。它是一種簡單的數據訪問技術。


熱門答案

我認為你的問題是忽視背景。 DAL和BLL通常與上下文有關。它不是關於單行代碼(如您的問題所示),而是關於類,命名空間甚至項目中包含行代碼的源文件的路徑。很多時候,想要編寫好的DAL和BLL的程序員會忽略這些問題,並認為如果他們使用正確的工具,問題就會立即得到解決。

讓我根據您上面提供的代碼行給出一些示例,以明確我的觀點。

如果我正在閱讀項目的源代碼並發現* .aspx.cs文件中的代碼行,我會有點心疼。該項目不是n層或模塊化。

相反,如果我正在閱讀源代碼並在項目的DAL子目錄中名為dog.cs的文件中找到該代碼行,那麼很明顯,此代碼旨在充當解決方案中dog對象的數據訪問權限。

如果它位於目錄調用BLL中,則可以得出類似的結論。

不要錯過理解我的觀點 - 我不是建議您在解決方案中有一個目錄名稱DAL和BLL - 我只是說定義這些元素的內容是執行數據訪問的一段代碼的外部。這樣的代碼行可能有助於設計良好的n層系統或減損它。



許可下: CC-BY-SA with attribution
不隸屬於 Stack Overflow
這個KB合法嗎? 是的,了解原因
許可下: CC-BY-SA with attribution
不隸屬於 Stack Overflow
這個KB合法嗎? 是的,了解原因