遵循CQRS(命令查詢責任分離)的概念,我直接在我的MVC應用程序中引用DAL,並通過ViewModels進行所有讀取。 然而,我的一位同事問我,當讀取任何業務邏輯時,你會怎麼做。 例如如果需要計算在場景的百分比值象下面這樣:CQRS:查詢端的業務邏輯
//Employee domain object
class Employee
{
string EmpName;
Single Wages;
}
//Constant declared in some utility class. This could be stored in DB also.
const Single Tax = 15;
//View Model for the Employee Screen
class EmployeeViewModel
{
string EmpName;
Single GrossWages;
Single NetWages;
}
// Read Facade defined in the DAL
class ReadModel
{
List<EmployeeViewModel> GetEmployeeList()
{
List<EmployeeViewModel> empList = new List<EmployeeViewModel>;
string query = "SELECT EMP_NAME, WAGES FROM EMPLOYEE";
...
..
while(reader.Read())
{
empList.Add(
new EmployeeViewModel
{
EmpName = reader["EMP_NAME"],
GrossWages = reader["WAGES"],
NetWages = reader["WAGES"] - (reader["WAGES"]*Tax)/100 /*We could call a function here but since we are not using the business layer, the function will be defined in the DAL layer*/
}
);
}
}
}
在上面的例子中,存在其在DAL層存在的讀出的過程中發生的歷史測算。我們可以創建一個函數來進行計算,但是由於我們已經繞過了業務層來讀取數據,函數將位於DAL中。更糟糕的是,如果Tax的值存儲在數據庫中,則有人可能會直接在DB中的存儲過程中執行此操作。所以我們在其他層面上存在潛在的業務邏輯泄漏。
您可能會說,爲什麼不在執行命令時將計算值存儲在列中。所以讓我們稍微改變一下情況。讓我們假設您在報告中顯示員工的潛在淨工資與當前稅率並且工資尚未支付。
你將如何在CQRS中處理這個問題?
我認爲報告對於CQRS來說可能是一個糟糕的情況,正是出於這些原因。將所有可能的報告歸一化是沒有意義的;有太多,而且生產成本太高。查詢命令分離的好處在於可以自由選擇不同的讀取模型來滿足您的需求。您可以將事件轉儲爲GUI的一些簡單模型,但也可以將它們轉儲到OLAP多維數據集中以執行假設分析報告。是的,「業務邏輯」在OLAP查詢中,但這就是報告。 – 2012-07-13 15:02:03