domain model,又稱為領域模型,是Java企業應用討論的一個熱門話題,JavaEye也曾經多次圍繞這個話題討論,我們來看個簡單的例子:
一個簡單的公司工時管理系統,記錄員工的個人信息,每個員工的工作任務分配,以及工作所屬類別(例如開發,還是測試,還是培訓等等),其中每個員工有n個任務,員工和任務是一對多關系,每個員工也分別隸屬于多個不同的工作類別,員工和類型是多對多關聯關系,而每個任務也分別隸屬于唯一的工作類別,任務和類別是多對一關系。另外系統不要求對部門信息進行維護,不需要department表。因此,在這個系統中使用四張數據庫表:
users表保存員工信息,有name, password, gender, department, salary
tasks表保存工作任務信息,有name,start_time, end_time
kinds表保存工作所屬類別,有name
kinds_users表是一張關聯表,保存users表和kinds表的多對多關聯外鍵的
系統的功能需求如下:
1、某部門錄用一名新員工
2、某部門員工總薪水總和
3、某員工已經開始但尚未結束的任務
4、給某員工分配一項任務
5、所有用戶當前已經開始但尚未結束的任務
6、對某一類別,給所有和此一類別相關的員工,批量新增一批任務
7、針對任務的統計功能,給定某類別,統計當月總的任務數,已完成任務數,未完成任務數
我們先看看用ruby如何實現系統的領域模型:
1、某部門錄用一名新員工
2、某部門員工總薪水總和
3、某員工已經開始但尚未結束的任務
4、給某員工分配一項任務
5、所有用戶當前已經開始但尚未結束的任務
6、對某一類別,給所有和此一類別相關的員工,批量新增一批任務
7、針對任務的統計功能,給定某類別,統計當月總的任務數,已完成任務數,未完成任務數
這里值得注意的是,RoR可以很方便的采用充血的領域模型,所有的業務邏輯都可以放在相關的domain model里面。這里的user,task和kind都是對應于數據庫表的領域模型,而department是不對應數據庫的純業務邏輯的domain model。總共4個ruby文件,4個domain model,55行代碼,所有要寫的代碼都在這里了,代碼量確實非常少,每個domain model的顆粒度都比較大。
然后我們再看看如何用Java:
Java版本的實現代碼大家都比較熟悉,因此絕大部分代碼都省略了。Java版本需要3個持久對象,3個映射XML文件,3個DAO接口和實現類,4個Service和實現類,和一個IoC的bean組裝文件,總共21個文件,全部邏輯寫完整,代碼行數至少上千行。
通過對比,我們可以看到Java比較流行的實現是貧血的模型,按照面向對象的基本原則,對象的狀態應該和它的行為封裝在一起,因此Java多出來的這些XXXService是一些從純理論角度而言應該放入其相應的持久對象中去。但是Java實現充血模型從技術上有一定的難度,如何Service方法挪入到持久對象中呢?如何解決Dao的注入問題?如何解決domain logic方法的事務封裝問題?前者可以通過AspectJ的靜態織入來解決,后者也許可以通過織入或者annotation聲明來解決。但不管怎么說,Java從技術上很難實現充血模型,而且即使實現充血模型,也會導致一個Java類好幾百行代碼的狀況,其代碼的可閱讀性,模塊解藕能力都會變得很差,因此我們認為Java不適合充血模型,在表達復雜的業務邏輯的能力上,Java要比ruby差很多:
結論:
對于Java來說,更加適合采用貧血的模型,Java比較適合于把一個復雜的業務邏輯分離到n個小對象中去,每個小對象描述單一的職責,n個對象互相協作來表達一個復雜的業務邏輯,這n個對象之間的依賴和協作需要通過外部的容器例如IoC來顯式的管理。但對于每個具體的對象來說,他們毫無疑問是貧血的。
這種貧血的模型好處是:
1、每個貧血對象職責單一,所以模塊解藕程度很高,有利于錯誤的隔離。
2、非常重要的是,這種模型非常適合于軟件外包和大規模軟件團隊的協作。每個編程個體只需要負責單一職責的小對象模塊編寫,不會互相影響。
貧血模型的壞處是:
1、由于對象狀態和行為分離,所以一個完整的業務邏輯的描述不能夠在一個類當中完成,而是一組互相協作的類共同完成的。因此可復用的顆粒度比較小,代碼量膨脹的很厲害,最重要的是業務邏輯的描述能力比較差,一個稍微復雜的業務邏輯,就需要太多類和太多代碼去表達(針對我們假定的這個簡單的工時管理系統的業務邏輯實現,ruby使用了50行代碼,但Java至少要上千行代碼)。
2、對象協作依賴于外部容器的組裝,因此裸寫代碼是不可能的了,必須借助于外部的IoC容器。
對于Ruby來說,更加適合充血模型。因為ruby語言的表達能力非常強大,現在用ruby做企業應用的DSL是一個很熱門的領域,DSL說白了就是用來描述某個行業業務邏輯的專用語言。
充血模型的好處是:
1、對象自洽程度很高,表達能力很強,因此非常適合于復雜的企業業務邏輯的實現,以及可復用程度比較高。
2、不必依賴外部容器的組裝,所以RoR沒有IoC的概念。
充血模型的壞處是:
1、對象高度自洽的結果是不利于大規模團隊分工協作。一個編程個體至少要完成一個完整業務邏輯的功能。對于單個完整業務邏輯,無法再細分下去了。
2、隨著業務邏輯的變動,領域模型可能會處于比較頻繁的變動狀態中,領域模型不夠穩定也會帶來web層代碼頻繁變動。
附件是完整的RoR版本的項目示例代碼。要運行它,需要安裝MySQL數據庫(InnoDB表類型),Ruby和Ruby on rails環境。在MySQL數據庫中分別創建demo數據庫和demo_test數據庫,修改demo\config\database.yml中的MySQL數據庫配置,改成你的數據庫密碼。然后在項目跟目錄下面執行:
rake db:migrate
rake db:test:clone_structure
rake test
即創建開發環境數據庫,創建測試環境數據庫,和執行所有的單元測試。領域模型代碼位于demo\app\models目錄下面;單元測試代碼位于demo\test\units目錄下面
引用
一個簡單的公司工時管理系統,記錄員工的個人信息,每個員工的工作任務分配,以及工作所屬類別(例如開發,還是測試,還是培訓等等),其中每個員工有n個任務,員工和任務是一對多關系,每個員工也分別隸屬于多個不同的工作類別,員工和類型是多對多關聯關系,而每個任務也分別隸屬于唯一的工作類別,任務和類別是多對一關系。另外系統不要求對部門信息進行維護,不需要department表。因此,在這個系統中使用四張數據庫表:
users表保存員工信息,有name, password, gender, department, salary
tasks表保存工作任務信息,有name,start_time, end_time
kinds表保存工作所屬類別,有name
kinds_users表是一張關聯表,保存users表和kinds表的多對多關聯外鍵的
系統的功能需求如下:
1、某部門錄用一名新員工
2、某部門員工總薪水總和
3、某員工已經開始但尚未結束的任務
4、給某員工分配一項任務
5、所有用戶當前已經開始但尚未結束的任務
6、對某一類別,給所有和此一類別相關的員工,批量新增一批任務
7、針對任務的統計功能,給定某類別,統計當月總的任務數,已完成任務數,未完成任務數
我們先看看用ruby如何實現系統的領域模型:
- class User < ActiveRecord::Base
- has_and_belongs_to_many :kinds
- has_many :tasks, :dependent => :destroy do
- def processing_tasks
- find :all, :conditions => ["start_time <= ? AND end_time is null", Time.now]
- end
- end
- def apply_task(task_name)
- self.tasks << Task.new(:name => task_name, :start_time => Date.today)
- end
- def self.all_processing_tasks
- Task.find :all, :conditions => ["start_time <= ? AND end_time is null AND user_id is not null",Time.now]
- end
- end
- class Task < ActiveRecord::Base
- belongs_to : owner, :class_name => 'User', :foreign_key => 'user_id'
- belongs_to :kind
- def self.current_month_tasks(kind)
- kind.tasks.current_month_tasks
- end
- end
- class Kind < ActiveRecord::Base
- has_and_belongs_to_many :users
- has_many :tasks do
- def current_month_tasks
- month_begin = Date.today - Date.today.mday + 1
- month_end = Date.today - Date.today.mday + 30
- processing_tasks = find :all, :conditions => ["start_time <= ? AND end_time is null ", month_begin]
- processed_tasks = find :all, :conditions => ["end_time >= ? AND end_time <= ? ", month_begin, month_end]
- all_tasks = processing_tasks.clone
- all_tasks << processed_tasks unless processed_tasks.size == 0
- return all_tasks, processed_tasks, processing_tasks
- end
- end
- def add_batch_task_to_users(task_name)
- self.users.each do |user|
- task = Task.new(:name => task_name, :start_time => Date.today)
- user.tasks << task
- self.tasks << task
- end
- end
- end
- class Department
- def self.employee(username, department)
- User.create(:name => username, :department => department)
- end
- def self.total_salary(department)
- User.sum :salary, :conditions => ["department = ?", department]
- end
- end
1、某部門錄用一名新員工
- Department.employee("robbin","開發部")
2、某部門員工總薪水總和
- Department.total_salary("開發部")
3、某員工已經開始但尚未結束的任務
- user.tasks.processing_tasks
4、給某員工分配一項任務
- user.apply_task("學習Java")
5、所有用戶當前已經開始但尚未結束的任務
- User.all_processing_tasks
6、對某一類別,給所有和此一類別相關的員工,批量新增一批任務
- kind.add_batch_task_to_users("學習單元測試")
7、針對任務的統計功能,給定某類別,統計當月總的任務數,已完成任務數,未完成任務數
- Task.current_month_tasks(kind)
這里值得注意的是,RoR可以很方便的采用充血的領域模型,所有的業務邏輯都可以放在相關的domain model里面。這里的user,task和kind都是對應于數據庫表的領域模型,而department是不對應數據庫的純業務邏輯的domain model。總共4個ruby文件,4個domain model,55行代碼,所有要寫的代碼都在這里了,代碼量確實非常少,每個domain model的顆粒度都比較大。
然后我們再看看如何用Java:
- public class User {
- private Long id;
- private String name;
- private String password;
- private String gender;
- private String department;
- private int salary = 0;
- private List<Task> tasks = new ArrayList<Task>();
- # omit getter/setter methods ......
- }
- # omit User's ORM Mapping file
- public class Task {
- private Long id;
- private String name;
- private int duration = 0;
- private User owner;
- # omit getter/setter methods ......
- }
- # omit Task's ORM Mapping file
- public class Kind {
- ......
- }
- # omit Kind's ORM Mapping file
- public interface UserDao {
- public void addUser(User user);
- public loadUserById(Long id);
- # omit CRUD and other persistent methods ......
- public List<User> findByDeparment(String department);
- }
- public interface TaskDao {
- # omit CRUD and other persistent methods ......
- }
- public class UserDaoImpl {
- # omit implementations ......
- }
- public class TaskDaoImpl {
- # omit implementations ......
- }
- public class UserService {
- private UserDao userDao;
- public setUserDao(UserDao userDao) { this.userDao = userDao; }
- public int workload(User user) {
- int totalDuration = 0;
- for (Task task : user.getTasks()) {
- totalDuration += task.duration;
- }
- return totalDuration;
- }
- public employee(String username, String department) {
- User user = new User();
- user.setName(username);
- user.setDepartment(department);
- userDao.addUser(user);
- }
- }
- public class TaskService {
- private TaskDao taskDao;
- public void setTaskDao(TaskDao taskDao) { this.taskDao = taskDao }
- public applyTask(String taskName, User user) {
- Task task = new Task();
- task.setName(taskName);
- task.setUser(user);
- taskDao.addTask(task);
- }
- }
- public class DepartmentService {
- private UserDao userDao;
- public void setUserDao(UserDao userDao) { this.userDao = userDao; }
- private UserService userService;
- public void setUserService(UserService userService) { this.userService = userService; }
- public int totalSalary(String department) {
- ......
- }
- ......
- }
- # omit IoC Container weaving configuration's file
Java版本的實現代碼大家都比較熟悉,因此絕大部分代碼都省略了。Java版本需要3個持久對象,3個映射XML文件,3個DAO接口和實現類,4個Service和實現類,和一個IoC的bean組裝文件,總共21個文件,全部邏輯寫完整,代碼行數至少上千行。
通過對比,我們可以看到Java比較流行的實現是貧血的模型,按照面向對象的基本原則,對象的狀態應該和它的行為封裝在一起,因此Java多出來的這些XXXService是一些從純理論角度而言應該放入其相應的持久對象中去。但是Java實現充血模型從技術上有一定的難度,如何Service方法挪入到持久對象中呢?如何解決Dao的注入問題?如何解決domain logic方法的事務封裝問題?前者可以通過AspectJ的靜態織入來解決,后者也許可以通過織入或者annotation聲明來解決。但不管怎么說,Java從技術上很難實現充血模型,而且即使實現充血模型,也會導致一個Java類好幾百行代碼的狀況,其代碼的可閱讀性,模塊解藕能力都會變得很差,因此我們認為Java不適合充血模型,在表達復雜的業務邏輯的能力上,Java要比ruby差很多:
結論:
對于Java來說,更加適合采用貧血的模型,Java比較適合于把一個復雜的業務邏輯分離到n個小對象中去,每個小對象描述單一的職責,n個對象互相協作來表達一個復雜的業務邏輯,這n個對象之間的依賴和協作需要通過外部的容器例如IoC來顯式的管理。但對于每個具體的對象來說,他們毫無疑問是貧血的。
這種貧血的模型好處是:
1、每個貧血對象職責單一,所以模塊解藕程度很高,有利于錯誤的隔離。
2、非常重要的是,這種模型非常適合于軟件外包和大規模軟件團隊的協作。每個編程個體只需要負責單一職責的小對象模塊編寫,不會互相影響。
貧血模型的壞處是:
1、由于對象狀態和行為分離,所以一個完整的業務邏輯的描述不能夠在一個類當中完成,而是一組互相協作的類共同完成的。因此可復用的顆粒度比較小,代碼量膨脹的很厲害,最重要的是業務邏輯的描述能力比較差,一個稍微復雜的業務邏輯,就需要太多類和太多代碼去表達(針對我們假定的這個簡單的工時管理系統的業務邏輯實現,ruby使用了50行代碼,但Java至少要上千行代碼)。
2、對象協作依賴于外部容器的組裝,因此裸寫代碼是不可能的了,必須借助于外部的IoC容器。
對于Ruby來說,更加適合充血模型。因為ruby語言的表達能力非常強大,現在用ruby做企業應用的DSL是一個很熱門的領域,DSL說白了就是用來描述某個行業業務邏輯的專用語言。
充血模型的好處是:
1、對象自洽程度很高,表達能力很強,因此非常適合于復雜的企業業務邏輯的實現,以及可復用程度比較高。
2、不必依賴外部容器的組裝,所以RoR沒有IoC的概念。
充血模型的壞處是:
1、對象高度自洽的結果是不利于大規模團隊分工協作。一個編程個體至少要完成一個完整業務邏輯的功能。對于單個完整業務邏輯,無法再細分下去了。
2、隨著業務邏輯的變動,領域模型可能會處于比較頻繁的變動狀態中,領域模型不夠穩定也會帶來web層代碼頻繁變動。
附件是完整的RoR版本的項目示例代碼。要運行它,需要安裝MySQL數據庫(InnoDB表類型),Ruby和Ruby on rails環境。在MySQL數據庫中分別創建demo數據庫和demo_test數據庫,修改demo\config\database.yml中的MySQL數據庫配置,改成你的數據庫密碼。然后在項目跟目錄下面執行:
rake db:migrate
rake db:test:clone_structure
rake test
即創建開發環境數據庫,創建測試環境數據庫,和執行所有的單元測試。領域模型代碼位于demo\app\models目錄下面;單元測試代碼位于demo\test\units目錄下面
安徽新華電腦學校專業職業規劃師為你提供更多幫助【在線咨詢】