2009-06-19 34 views
8

Tôi đã cố tách riêng DAL khỏi Lớp kinh doanh của mình và khi làm như vậy, tôi quyết định tránh bất kỳ phương pháp ActiveRecord nào và thực hiện phương pháp tiếp cận DataMapper. Nói cách khác, các đối tượng miền của tôi sẽ không tự chăm sóc bản thân. Khi làm như vậy, tôi dường như đang lấn chiếm mô hình chống "mô hình miền thiếu máu". Ví dụ, một trong những thực thể trong chương trình của tôi là một tổ chức.Xử lý mô hình miền thiếu máu

Một tổ chức được thể hiện dưới dạng một cái gì đó như thế này:

class Organization { 
    private $orgId; 
    private $orgName; 

    // getters and setters 
} 

Vì vậy, về cơ bản tổ chức này không có gì khác hơn là đóng vai trò như "túi" (như Martin Fowler nói) đối với một số dữ liệu. Trong thế giới PHP nó không là gì hơn một mảng được tôn vinh. Không có hành vi nào được liên kết với nó.

Và hành vi trong chương trình, tôi đã gắn bó trong lớp "cấp dịch vụ" như một OrganizationService, chủ yếu phục vụ như một trung gian giữa các đối tượng này và DAL.

Khác với các vấn đề mở rộng quy mô với PHP (Tôi có lý do khác khiến tôi nhấn mạnh "đóng gói" dữ liệu của tôi trong các đối tượng này), cách tiếp cận này có hoàn toàn không?

Làm cách nào để bạn xử lý các mô hình miền của mình trong các trường hợp này? Có lẽ một tổ chức không phải là một phần của miền của tôi ngay từ đầu?

Trả lời

6

tốt, nó có vẻ như này ngay từ đầu, nhưng khi bạn sẽ cấu trúc lại mã của bạn nhiều hơn, bạn sẽ nhận được một số hành vi cho lớp tổ chức của bạn ...

một ví dụ mà tôi có thể nghĩ bây giờ là nếu bạn có người (nhân viên), bạn có thể muốn liên kết họ với tổ chức. vì vậy, bạn có thể có một phương thức AssociateEmployee(User employee) có thể tìm thấy vị trí của nó trong lớp tổ chức của bạn.

Hoặc bạn có thể thay đổi vị trí của công ty, thay vì thiết lập các thông số như địa chỉ, thành phố, tiểu bang trong ba bước, bạn có thể thêm ChangeLocation(Street, City, State) phương pháp ..

Chỉ cần đi từng bước một, khi bạn gặp phải một số mã trong bạn BL/lớp dịch vụ có vẻ như nó phải thuộc về miền, di chuyển nó xuống miền. Nếu bạn đọc Fowler, bạn sẽ nhận được nó rất sớm khi bạn nhìn thấy nó trong mã của bạn.

+0

Làm thế nào bạn có thể có phương thức AssociateEmployee trong mô hình miền, nếu mô hình miền không có quyền truy cập vào một DataMapper? – bestattendance

2

Nó có thể chỉ là thiếu máu bây giờ?

Ví dụ: một lần tôi đang phát triển trang web đăng ký cuộc họp/hội nghị. Nó bắt đầu chỉ với một cuộc họp.

Vẫn còn một lớp họp và chỉ một trường hợp, nhưng năm tiếp theo chúng tôi tổ chức hội thảo, nó được mở rộng và các thuộc tính mới được thêm vào (để tổ chức hai cuộc họp liên tiếp), vì vậy rõ ràng là không đã phát triển đầy đủ, khi chúng tôi đã thêm các nhóm cuộc họp có thể chứa nhiều cuộc họp. Vì vậy, tôi nghĩ rằng điều quan trọng cần lưu ý là các tên miền thay đổi theo thời gian và mô hình của bạn có thể sẽ được tái cấu trúc, vì vậy ngay cả khi bạn cho rằng nó thiếu máu, nó có thể chỉ hơi tiến về phía trước (như tổ chức của bạn) lớp học sẽ bắt đầu để có được một số cài đặt, quy tắc hoặc sở thích hoặc một cái gì đó).

1

Thực thể của bạn không bị thiếu máu do bạn đang sử dụng trách nhiệm reposnsibility không nên ở đó để bắt đầu. Các thực thể bền vững và tìm nạp là sự lặp lại của Repositories. Thực sự hành vi của bạn phải ở trong thực thể của bạn không phải trong một lớp dịch vụ. Nhưng giải thích điều gì xảy ra ở đâu ngoài cách trả lời đơn giản. DDD của Eric Evans là một điểm khởi đầu tốt.

2

Bạn cũng có thể xem xét rằng nếu bạn không có nhiều quy tắc kinh doanh hoặc miền không phức tạp, DDD có thể là quá nhiều chi phí cho bạn. DDD là một giải pháp tuyệt vời cho các miền lớn, phức tạp, nhưng rất nhiều chi phí và sự phức tạp nếu bạn chỉ đơn giản là làm dữ liệu trong, dữ liệu. DDD khó thiết kế và vốn đã thêm tính phức tạp, do đó, để biện minh cho nó, sự phức tạp của miền vấn đề sẽ lớn hơn.

Đó là tất cả những gì tôi sẽ thêm vào zappan và epitka.

+0

Tôi tình cờ có các quy tắc kinh doanh phức tạp hơn ở các phần khác trong miền của mình. Ứng dụng cụ thể này là một hệ thống cho các tổ chức để thiết lập đấu giá Trung Quốc (http://en.wikipedia.org/wiki/Chinese_auction). Các khía cạnh khác của ứng dụng, như sự lặp lại với các giải đấu đấu giá và giỏ mua hàng thực sự chứa đựng một lượng logic hợp lý. Tất cả trong tất cả, mục tiêu chính của tôi là không nhất thiết phải DDD, nhưng tách mối quan tâm. – blockhead

Các vấn đề liên quan