4. Tóm tắt cấu trúc của luận văn
1.3.8. Mẫu Mô hình lĩnh vực
1.3.8.1. Ý nghĩa
Một mô hình ựối tượng của một lĩnh vực nào ựó là sự kết hợp chặt chẽ giữa hành vi và dữ liệu.
Trong rất nhiều trường hợp logic nghiệp vụ là rất phức tạp. Các logic và các quy tắc mô tả rất nhiều tình huống và hành vi. Mẫu Mô hình lĩnh vực (DomainModel) tạo ra một mạng lưới các ựối tượng liên kết với nhau trong ựó mỗi ựối tượng thể hiện một vài cá thể có ắch, nó có thể lớn như là một doanh nghiệp hoặc có thể nhỏ như một danh mục trên mẫu ựơn ựặt hàng.
1.3.8.3. Mô tả
Khi ựưa mẫu Domain Model vào một ứng dụng dẫn ựến việc phải ựưa cả một lớp các ựối tượng vào ựể mô hình hóa nghiệp vụ mà chúng ta ựang làm. Chúng ta sẽ phải tìm ra các ựối tượng mà chúng bắt chước dữ liệu nghiệp vụ và các ựối tượng mô tả các quy tắc nghiệp vụ ựược sử dụng. Phần lớn các dữ liệu và quy trình ựược kết hợp lại trong một cluster mà quy trình liên quan mật thiết với dữ liệu mà chúng cần ựể làm việc. Domain Model trộn dữ liệu với quy trình, có nhiều các thuộc tắnh ựa trị và một mạng phức tạp các liên kết và sử dụng tắnh kế thừa.
Hình 1.12: Cấu trúc mẫu Domain Model sử dụng mẫu Strategy
Vì các hành vi của nghiệp vụ là thay ựổi thường xuyên, vì vậy việc yếu tố quan trọng là làm sao ựể các ựối tượng trong tầng nghiệp vụ này có khả năng chỉnh sửa, tạo lập và kiểm thử một các dễ dàng. Thông thường ta sẽ hay làm là giảm ựến mức tối ựa sự phụ thuộc của Domain Model vào các tầng khác của ứng dụng hay ựể các mẫu phân tầng khác có ắt sự phụ thuộc nhất có thể giữa Domain Model và các phần khác của hệ thống.
1.3.8.3. Các tình huống áp dụng
Với một Domain Model, có khá nhiều phạm vi khác nhau mà ta có thể sử dụng. Tình huống ựơn giản nhất là ứng dụng ựơn người dùng trong ựó ựồ thị của ựối tượng ựược ựọc vào từ file và ựưa lên bộ nhớ. Các ứng dụng cho desktop có thể làm theo cách như thế này. Tuy nhiên ựây không phải là trường hợp phổ biến cho các ứng dụng
quản lý thông tin ựa tầng bởi vì nó có quá nhiều ựối tượng, việc ựưa tất cả các ựối tượng vào bộ nhớ sẽ tiêu tốn quá nhiều bộ nhớ và mất nhiều thời gian.
Một ựiều cần quan tâm ựối với Domain Model là sự phình lên của các ựối tượng. Vắ dụ khi ta xây dựng một màn hình ựể xử lý các ựơn hàng (Order), chúng ta phải chú ý rằng một số hành vi ựặt hàng chỉ cần cho chắnh nó. Nếu ta ựưa tất cả các phương thức này vào lớp Order thì khi ựó lớp Order sẽ trở lên quá lớn bởi vì nó chứa nhiều các phương thức mà chúng chỉ ựược dùng trong một vài tình huống riêng lẻ. điều này làm chúng ta phải cần xem các phương thức nào là chung, khi ựó ra sẽ ựưa vào lớp Order, hoặc nếu nó là chuyên biệt thì ta sẽ tạo ra các lớp ựể sử dụng với mục ựắch chuyên biệt ựó, khi ựó ta có thể dùng mẫu TransactionScript.
Tuy nhiên việc tách biệt các hành vi cho các mục ựắch chuyên biệt có thể ựưa ựến việc trùng lặp các lớp. Việc tìm ra các hành vi ựược tách ra từ lớp Order là khá khó khăn, vì thế chúng ta cố gắng ựể không nhìn thấy nó thay vì ựó là trùng lặp nó. Việc trùng lặp nhanh chóng dẫn ựến việc hệ thống sẽ phức tạp hơn và không toàn vẹn. Tuy nhiên, ta thấy rằng việc các ựối tượng phình lên không thường gặp nhiều như dự ựoán, nếu gặp thì nó thường dễ nhìn thấy và không khó ựể chỉnh lại. Lời khuyên là: không nên tách biệt các hành vi với mục ựắch sử dụng chuyên biệt, hãy ựưa tất cả các hành vi của ựối tượng vào trong các lớp một cách tự nhiên ựể tránh việc phình lên của ựối tượng.
Nếu ta có một hệ thống mà ở ựó các quy tắc nghiệp vụ là phức tạp và luôn thay ựổi, liên quan nhiều ựến các phép tắnh xác nhận tắnh hợp lệ, ựến tắnh toán, ựạo hàm, khả năngẦ thì sẽ cần ựến một mô hình ựối tượng ựể quản lý chúng (tức là dùng ựến
Domain Model). Ngược lại nếu chỉ có các ứng dụng liên quan ựến các phép phép tắnh
ựơn giản như kiểm tra giá trị NULL, tắnh toán tổng, Ầ thì TransactionScript là một sự lựa chọn tốt hơn.