在一個人的項目上工作時最糟糕的是缺乏通常從同事那裏得到的輸入。而由於缺乏這些，你往往會犯明顯的錯誤。建築難題
經過一段時間後，我需要社區的幫助。
我開始了一個小家庭釀造項目，應該變成某種門戶。而困擾我的主要問題是我編制的持久層。對於初學者來說，它應該與表示層完全分離，並且OR映射器也在某處。這是因爲我有多個數據存儲必須使用。
所以基本思想是，各個「存儲庫」在各自的數據庫上進行操作，然後業務層將業務對象聚合，然後將表示層中的業務對象轉換爲查看對象。
的主要問題我面對的是以下內容：
多個類爲相同的概念 - 有一個用戶的DAL表示和BL 用戶的表示和的視圖表示用戶。我可以用一個工具來處理這個轉換，但這真的是正確的方法。我的意思是他們都很好地分開，但是開銷很大。
您認爲如何？我是否過分關注兔子洞的分離還是這仍然正常？
這比平常更多。
通常沒有人會這樣做，並在呈現html或whatnot時對ORM懶惰加載問題大聲疾呼。
寫DTO層比寫DA，BLL和UI更容易。有些甚至更進一步，並且在建築規模中應用命令&清晰地繪製輸入/輸出之間的界線（其解決了像實際僅用於報告目的的人爲業務對象的需要這樣的問題）。
另一方面 - 取決於。如果您的應用程序很簡單，那麼您可能不需要太多抽象（例如簡單的公司組合主頁）。
這就是擁有多個存儲庫的危險。這引發了「你需要他們全部還是不需要」的無關緊要的問題？鞏固它們中的任何一個都有意義嗎？可以嗎？
我建議你在Data Architecture上做一些閱讀 - 我自己是一個完全新手，但我從一個非常有經驗的人那裏得到了一些很好的建議。一種觀點是數據架構師更關心數據的定義方式，而不是物理數據庫的實際組合方式：我的建議是從邏輯數據模型和物理數據模型中捕獲並記錄（建模）。對數據有一個非常清晰的理解將會非常有幫助。
這個（即DA的位所擔心的）具體是數據的定義 - 這一點數據是什麼（不依賴於列名和表名）？它是如何使用的，它是什麼意思，它在哪裏創建的？同樣重要的是，我們不是在討論在系統中物理創建的位置 - 而是在業務流程中創建它的位置。是的，你需要擔心繫統 - 但這是爲了以後;業務流程應該驅動系統。這是所有邏輯數據模型的東西。
一旦你有了定義，你可以開始拼湊它 - 來自不同倉庫的數據是如何相關的？ （可能更多地進入這裏的物理模型）。
一旦所有這一切都明確的答案，你如何適應它應用程序應該開始變得明顯，並有記錄將有所幫助。 thsi是那些擁有良好文檔確實非常重要的實例之一。
坦白地說，我沒有看到這個問題。在單獨的圖層中爲數據分開分類意味着您可以更改一個，而無需更改其他分層。其他表示的額外費用通常非常小 - 打字速度通常不是生產力的因素。
OTOH能夠改變數據存儲方面的內容而不必改變整個堆棧，可以爲您節省時間和精力，因爲經常使用同一構造物用於多種目的會導致不可預見的副作用，做出改變。 IOW，雖然不得不通過多層傳播變化，但它可以通過適當的工具等等來幫助。另一方面，當數據層中的微不足道的變化具有不可預見的副作用時你的用戶界面，總是爛，並減緩任何改變，因爲你所做的任何事情都可能破壞整個系統中的任何東西。