胡亂說一下我對於 BO VO PO DTO 的理解

引言

 

 

本文中將向你們介紹我對因而使用實體的一些體驗，歡迎你們拍磚。更歡迎提出不一樣或者相同的意見。

正文

 

 

 

剛開始學會使用實體的時候就是創建一個Entity類庫，而後裏面的實體被其餘各層引用。你們傳遞和使用的都是這一個類庫中的實體，包括前端和後臺的項目都是引用這個類庫，傳遞和操做這個類庫中的實體。

 

 

就像上面的這幅圖同樣。每一個都要添加對Entity的引用。每一個項目都是這麼作的，也沒有發現什麼很差的地方。

 

之前都是作一些小項目，或者是本身Demo一下。上面的作法也沒有什麼問題，並且看到別人的文章也都是相似這樣的結構。後來在學習DDD(Domain Driven Design）的時候，看到了不少的概念。有DTO,VO,PO,BO,DAO，才發現怎麼須要這麼多的實體類庫（有的不是類庫，例如DAO）呢？以爲難以想象，這麼多維護起來不是很麻煩嗎？一會兒尚未想到分開這麼多類庫的好處。

 

從今年年初開始接觸一個大項目，到目前爲止才搞完一半。主要的結構也是BLL,DAL，因爲前端採用了純Silverlight展現，因此訪問數據庫必需要藉助服務類的項目（開始的時候咱們仍是用silverlight3，後來silverlight4可使用tcp了，可是端口有限制，不適宜在互聯網環境使用，容易被防火牆阻斷，內網應用可使用tcp），例如：webservice，wcf，最終咱們使用的是WCF。我主要負責後臺代碼的編寫，因爲人少，後臺我全負責了，包括dal，bll，wcf，一我的搞定。

 

wcf和silverlight之間傳遞數據使用強類型的實體和實體集合，可是silverlight不能添加普通類庫的應用，它有本身的silverlight類庫項目。固然了，silverlight也能夠不添加類庫，在添加服務引用的時候，會自動在silverlight項目生成wcf所須要的實體，在reference.cs文件（這個文件就是wcf在客戶端的代理類，裏面包括了服務的定義，也就是下圖中紅框框中的文件，想看這個文件，須要點擊Solution Explorer的Show All Files按鈕，就是解決方案管理器的左上角）中有。

 

因而我就創建了兩個項目，一個是普通的類庫，給後臺的BAL,DAL,SERVICE引用；一個是silverlight的類庫，給silverlight引用，他們的文件內容是同樣的。固然了，須要在類和屬性上添加序列化attribute。類上添加DataContract，屬相上添加DataMember。

 

時間長了，在數據訪問層就會有相似不少下面的代碼。

 

 

 

 
       public List<Person> GetAll() { List<Person> list = null; using (IDbConnection conn = new System.Data.SqlClient.SqlConnection()) { conn.Open(); IDbCommand comm = conn.CreateCommand(); comm.CommandText = "select id,name from person"; IDataReader reader = comm.ExecuteReader(CommandBehavior.CloseConnection); list = new List<Person>(); while (reader.Read()) { list.Add(new Person() { ID = (Guid)reader["ID"], Name = reader["Name"].ToString() }); } } return list; }  

 

 

 

　　

就想着可否簡化一些呢？由於每次查詢都要寫while。。。reader[「」]，好像都很重複，想要少些一些這樣的代碼。就想到了好像有ORM這種工具能夠幫助實現映射和持久化，找了幾個，NH，微軟的EF。發現學習起來不是很順利，之前沒有項目使用過，對於他們的內部不是很瞭解，拋出的一些異常也不是很好解決，若是這時候引入項目的話，確定有風險，搞很差還會拖慢進度，決定放棄引入這些ORM工具，等待詳細學習瞭解以後再作決定。

 

可是上面的代碼仍是要簡化啊，至少在從數據庫的reader到entity這一層面能夠想辦法簡化賦值過程。想到了反射，利用反射給每一個屬性賦值，再加上attribute，給屬性打上標記，方便屬性和數據庫查詢結果列的對應。因而就寫了一個EntityMapper的小工具，來輔助實現reader到enttiy和entitycolleciton的映射。詳見：利用attribute實現簡單的ORM

 

實際上沒有ORM那麼強大，就是一個reader到enttiy和entitycolleciton的映射的工具，之後想着要基於這個逐步完善成一個本身的ORM，這是後話了，暫且不提。

 

這時候發現減小了不少的工做量，並且代碼也簡單多了，沒有了大量的reader[「」]到屬性的賦值。

 

咱們系統的業務是常常變化的，後期有添加的需求，有修改前期的需求。致使了，實體類庫須要修改，增長屬性，減小屬性之類的。減小還好辦，頂多就是數據庫查詢的多了，沒有屬性和它對應了，我不賦值就是了。增長屬性就暴露了各層公用一個實體類庫的問題，仍是一個不小的問題。

 

例如我在一個類添加一個屬性，因爲reader到entity的映射是採用我寫的這個工具，因而添加屬性，添加attribute。新方法，新存儲過程，測試，沒有問題。可是，這個實體的其餘方法就報錯了，由於其餘方法對應的存儲過程沒有查詢新添加的字段，可是在映射的時候是根據屬性映射的，就報錯「沒有找到新屬性對應的列」。好吧，那就打開老方法的存儲過程，添加對於新屬性的查詢。問題就出來了，原本是添加方法，卻還要修改之前的存儲過程，少的還好，多的狀況的話，就須要修改大量的存儲過程，我碰到最多的一個是牽連了10個存儲過程。這也能夠歸結爲緊耦合，依賴太強了，須要解耦。

 

固然，改也是copy，由於字段同樣，可是這個問題應該有更好的辦法，這樣下去，維護量會愈來愈大。

 

因而想起學習DDD的過程當中遇到的那些概念了，什麼BO,PO,DAO,DTO，VO的。首先給你們說一下這些概念，而後講解我對他們的使用方案。這些概念好像在Java中很是流行，使用java進行開發的人應該更加熟悉他們。

BO：Business Object，業務對象。主要是承載業務數據的實體。處理業務邏輯的時候使用，數據結構也是針對業務邏輯創建的。

PO：persistence Object，持久化對象。數據最終要存儲，不管以何種形式存儲，都必需要持久化。加入使用關係數據庫存儲，一個PO對應一條數據庫的記錄，或者是對象從數據庫查詢出來的結果集的一條記錄。

DAO：Data Access Object，數據訪問對象。包含一些數據庫的基本操做，CRUD，和數據庫打交道。負責將PO持久化到數據庫，也負責將從數據庫查詢的結果集映射爲PO。

DTO：Data Transfer Object，數據傳輸對象。通常用來在前段和後臺的數據傳輸，數據結構的簡歷是基於網絡傳輸的，減小傳輸的數據量，避免傳輸過多無用的數據。

VO：Value Object，值對象。主要用在前段數據和控件的綁定操做中，以鍵值對的形式存在。能夠從DTO轉化而來，這麼作的好處就是減小對於DTO的依賴，進一步減小對應後端的依賴。還能夠增長前段的可測試性，也就是沒有DTO，也能夠對前段邏輯進行自動化的單元測試，能夠經過MockDTO來達到測試的目的。

 
 

 

 

我想經過上面的這幅圖來表達個人想法。web，winform，silverlight，console表明不一樣的前端類型。Domain表明領域對象，也能夠是BLL。

獲取數據的過程：首先DAO從數據庫獲取結果集，轉換爲PO。Domain接受到DAO傳遞過來的PO以後，負責將PO轉換爲BO，再進行業務邏輯的處理。處理完畢，傳遞BO給service，service負責轉換爲DTO，傳輸給前端接收到DTO以後，首先轉換爲VO，而後再進行前端的業務處理。

提交數據的過程： 前端將數據整理爲DTO，傳輸給service，service轉換爲BO傳輸給Domain，Domain轉換爲PO，調用DAO提供的數據持久化方法，持久化PO，DAO負責將PO持久化爲數據庫的數據。

 

 

 

 

好像還有一個概念叫作：POJO，這是java中的概念。POCO是.NET的概念。我的理解好像就是一類實體的統稱，指的是實體沒有操做，只要屬性，簡單實體，沒有繼承或者實現任何抽象的實體。凡是知足這個標準的實體均可以叫作POCO或者POJO。