如何使多層次的架構在.net MVC更乾燥（實體框架）

Question

我目前正在建設一個大型的Web項目，試圖做所有正確的事，分裂成東西立面，服務，DAO的（資料庫），傭工等

而且使用DI與Ninject

現在，也許這只是監守它的項目開始不久，但感覺像它採取一個永恆的只是設置簡單的調用在分貝？每次我想做一個新的調用或者做一些事情時，都需要通過每個服務層最少寫4種方法，將所有事情都傳回去等等。每次你在db層中改變某些東西時，您必須通過域對象手動複製更改，以及更新手動將DAO對象轉換爲域對象的方法（使用分部類接受DaoObject的構造函數中的DomainObjects以及每個DaoObject上的ToDomainObject方法）

通過每個循環DaoObject將其轉換成一個域對象在每次讀數DAO方法結束感覺混亂。

我們正在使用實體框架，DBfirst。有沒有什麼聰明的做法可以讓這個過程變得更加乾爽，或者我們只需要等到我們的應用程序的基礎建立完成後，事情就會開始變得更容易，因爲大部分管道已經被鋪設了。尤其當你想通過結合現有服務來提供新服務時，情況會更好。

Partiuclarly在業務邏輯層手動重新創建DAO對象感覺臃腫，但我可以理解，實際的想法是DAO層實際上映射到業務層，它只是感覺緩慢與使用Context Designer相比。 IE的業務層規定了它需要的數據，而不關心它實際來自哪裏。

任何幫助將不勝感激。

Answer 1

一兩件事，肯定會加快它需要你增加新的功能時，使用AutoMapper自動將您的DAO轉換成域對象。沒有更無聊的手動屬性映射！

有很好地分離所有層確實會帶來你必須做一些額外的管道，但你每一個邏輯組件分離乾淨，容易測試，容易被取代。作爲一個大型項目，我認爲從長遠來看，管理費用肯定會得到支付。

Answer 2

看T4模板生成功能。它可用於根據對DAO的更改生成\ regenerate實體。

看http://www.blogfor.net/2009/09/03/generating-business-layer-code-t4-against-a-linq-to-sql-dal/

和

http://imaginarydevelopment.blogspot.in/2010/01/t4-generates-my-business-objects-for-me.html

得到一些想法。