.NET業務框架開發實戰之四 后篇
核心提示:首先,業務類和數據實體類不是一 一對應的關系,換句話說,不是一個業務類就一定對應數據庫中的一張表。業務類是用只是使用數據實體中的數據而已,所以一個業務類中的數據往往來自多個數據實體。
.NET業務框架開發實戰之四 中篇—— 業務層初步構想
前言:
本篇主要講述如何把DAL和BLL銜接起來。
本篇議題如下:
1).DAL和BLL之前的Mapping
2)。如何Mapping
3)。再次構思
1.DAL和BLL之前的Mapping
首先,業務類和數據實體類不是一 一對應的關系,換句話說,不是一個業務類就一定對應數據庫中的一張表。業務類是用只是使用數據實體中的數據而已,所以一個業務類中的數據往往來自多個數據實體。
每個業務類都是有自己的一些屬性的,把數據以數據實體或者DataTable的形式從DAL獲取之后,BLL類就使用這些數據,BLL不會把這些原生的數據實體暴露給UI。BLL類會把UI中要是用的數據裝入到自己的屬性中。
所以在這個過程中就有一個賦值的過程,或者稱為mapping映射。當Richard提出這個想法后,項目組的同事就問他:為什么要做的這么復雜,還要一 一 的賦值,為什么不直接把數據實體給UI使用,為什么一定要在中間這么轉一下呢?
Richard分析了一些原因:
1. 如果直接把數據實體給了UI,那么UI那端就很清楚DAL了,以后數據訪問方式從ADO.NET 到了EF,那么UI 就動了,又回到以前了。
2.在BLL中可以對從DAL取出來的數據進行一些處理,如轉換格式,計算,組合等。
Richard想到把BLL和DAL徹底的解耦:業務類中不存在數據實體類的引用。這樣設計之后靈活性就很大了。最后達到的效果就是:通過配置,配置業務類每個屬性的數據的來源。而這個業務類完全不知道這些數據到底來源于哪個或者哪些數據實體。
這樣確實很靈活,Richard興奮不已。
2. 如何Mapping
初步想法通過配置文件。如現在有一個Product的業務類,定義如下:
代碼
| public class ProductBL public string ProductName { get; set; } public decimal Price { get; set; } public string Description { get; set; } } |
那么如何給這些屬性賦值,同時也不引用數據實體。Richard用配置文件來實現的,這里Richard就約定了:配置文件的名字就是“業務類的名字”+“Mapping.xml”。所以Product的配置文件就是ProductBLMapping.xml
代碼
然后再運行的時候就通過反射來賦值。
現在問題又來了:
1).每次都是通過反射來賦值,性能很成問題。
2).如果配置文件出錯,調試很不方便。
3).如何處理一個業務類對應對個數據實體的情況,如:
代碼
| public class ProductBL //來自CustomDAL } |
但是好處很明顯:
1).DAL和BLL解耦
2).很便于查詢對象的實現。例如:在UI代碼寫:
ICriteria condition=CriteriaFactory.Create.Where;
當然ProductName是業務類ProductBL的屬性,在查詢對象最后解析為SQL語句的時候就可以利用ProductBLMapping.xml來生成SQL。
對于性能方面,Richard嘗試這樣解決:
在第一次Mapping的時候,就把這些mapping的信息保存在靜態字典中,下次在mapping的時候,就不用再讀配置文件了,而且讀內存中的字典。
但是這樣,隨著業務類的增加,內存使用也加大,而且賦值方式還是反射。
3. 再次構思
Richard接著考慮:如何處理一個業務類對應對個數據實體的情況?于是配置文件就改為了:
代碼
基本的問題算是解決了,但是性能的問題依然存在。
Richard又開始考慮更加好的方式。
本篇就寫到這里,謝謝各位。
下篇: .NET 業務框架開發實戰之八 業務層Mapping的選擇策略版權為小洋和博客園所有,轉載請標明出處給作者。
http://www.cnblogs.com/yanyangtian
轉載:http://www.cnblogs.com/yanyangtian/archive/2010/06/07/1752921.html
没有评论:
发表评论