5

Bởi đối tượng Thông minh, tôi xem xét bất kỳ đối tượng Miền nào biết giá trị thuộc tính ban đầu của nó nếu thuộc tính bị thay đổi. Các đối tượng thông minh thường có một lớp cơ sở và thực hiện các thuộc tính bằng cách sử dụng các phương thức GetPropertyValue/SetPropertyValue. Mặt khác, các đối tượng POCO thường không có lớp cơ sở và thực hiện các thuộc tính đơn giản.Đối tượng miền - "Đối tượng thông minh" so với POCO

public class SmartObject : BaseDomainObject 
{ 
    public int id 
    { 
     get { return (int)this.GetPropertyValue("Id"); } 
     set { this.SetPropertyValue("Id", value); } 
    } 
} 

public class POCO 
{ 
    public int id { get; set; } 
} 

Tôi thích đối tượng thông minh bởi vì nó làm rất nhiều công việc khó khăn cho tôi. Tôi có thể dễ dàng thêm tất cả những tính năng hữu ích để BaseDomainObject và có chúng trong tất cả các lớp miền bắt nguồn của tôi:

tính
  • chung (như Id, Status ...)
  • tượng trạng thái theo dõi (mới, sửa đổi, không thay đổi)
  • tất cả các thuộc tính nâng cao sự kiện vào những thay đổi sở hữu (thực hiện INotifyProperyChanged)
  • các lớp thừa kế có thể được tự động được serializable (mặc dù tôi hiếm khi tìm thấy điều này hữu ích)
  • tôi có thể có tất cả các hành vi này khác mà có thể hữu ích - Clone/Đồng bộ/IsPropertyDirty ...

Mặt khác, POCO rất đơn giản và không phụ thuộc vào bất kỳ lớp cơ sở nào.

Ngày nay tôi ở đây rất nhiều POCO ca ngợi vì:

  1. nó có thể được gửi qua dây (thường là trình duyệt web như JSON)
  2. nó là tinh khiết

Mặt khác tay Tôi nghĩ rằng những lý do trên là sai lầm vì:

  1. DTO là dành cho chuyển khoản và không phải là đối tượng miền. Hành vi đóng gói dữ liệu nếu bị mất khi đối tượng miền được tuần tự hóa thành JSON.
  2. điều này theo đuổi các đường nối tinh khiết như đuổi theo nhiều mô hình miền thiếu máu hơn mà không có logic hay bất kỳ thông minh nào gắn liền với nó.

Với tất cả những điều này buồn, tôi vẫn thích POCO và nó gây lỗi cho tôi. Ý kiến ​​của bạn là gì?

+2

Nếu bạn đang phấn đấu cho một mô hình tên miền phong phú, đừng gây ô nhiễm nó với các mối quan tâm về hạ tầng kỹ thuật. Tất cả những điều bạn đã đề cập - theo dõi trạng thái, tài sản đã thay đổi sự kiện, tuần tự hóa - không có thứ nào trong số này có liên quan đến miền. Họ không làm gì để mã hóa sự phức tạp của miền kinh doanh thành mô hình. – MattDavey

+0

Mặt khác, một POCO cũng không làm gì để mã hóa sự phức tạp của miền vào mô hình. Vì vậy, theo tiêu chuẩn DDD, cả hai cách tiếp cận đều rất kém. – MattDavey

+1

@MattDavey Tôi đồng ý với nhận xét đầu tiên của bạn nhưng tôi không chắc chắn về điều sau. POCO! = Thiếu máu, nếu đó là những gì bạn đang ngụ ý. Định hướng đối tượng cũ đồng bằng * * bao gồm hành vi và nếu có, Hành vi miền, ngoài dữ liệu. – guillaume31

Trả lời

4
  • tài sản chung (như Id, Status ...)

Tôi sẽ không xem xét một đối tượng là phi POCO nếu nó chỉ được thừa hưởng, một lớp cơ sở Entity định nghĩa một thuộc tính Id. Một thực thể theo định nghĩa có một danh tính, mà không phá vỡ SRP cũng không làm thay đổi "độ tinh khiết" của đối tượng của bạn bằng cách nhập hành vi của bên thứ ba.

Trạng thái gây tranh cãi nhiều hơn, tùy thuộc vào ý bạn là nó có thể thực sự đưa thêm trách nhiệm vào đối tượng của bạn khiến nó không phải là POCO.

Hầu hết các thuộc tính khác mà bạn đề cập đến, tôi cho rằng nên được xử lý bởi các đối tượng bên ngoài, chứ không phải đối tượng miền.

  • tượng trạng thái theo dõi (mới, sửa đổi, không thay đổi)

Nó sẽ là tốt hơn để có proxy thay đổi theo dõi chuyên ngành của các đối tượng tên miền của bạn xử lý này (đây là điển hình mà các ORMs làm).

  • tất cả các thuộc tính nâng cao sự kiện vào những thay đổi sở hữu (thực hiện INotifyProperyChanged)

Tôi thấy rằng là chủ yếu giao diện người dùng liên quan đến những thứ mà đi vào đối tượng trình bày của bạn nhưng không phải đối tượng tên miền của bạn. Có thể bạn sẽ không muốn mọi thuộc tính trong thực thể của mình có thể quan sát được - để báo hiệu thay đổi trong Tổng hợp, hãy sử dụng Sự kiện miền thay thế.

  • tôi có thể có tất cả các hành vi này khác mà có thể hữu ích - Clone/Sync/IsPropertyDirty ...

Clone thường có thể là một hành vi cơ bản của đối tượng giá trị gia tăng mà không có họ đang được xem xét không phải POCO. Nhân bản nhân bản dường như ít hữu ích đối với tôi, ngoại trừ nhu cầu cụ thể về miền của bạn. Đồng bộ/IsPropertyDirty một lần nữa có vẻ giống như phiên bản/thay đổi theo dõi và nên được giao cho một đối tượng chuyên ngành.

điều này cho các đường may tinh khiết như đuổi theo nhiều hơn nữa dạng thiếu máu cục bộ mô hình không có logic hay bất kỳ thông minh nào gắn liền với nó.

Vấn đề ở đây là tất cả về "được đính kèm". Không phải là các đối tượng tuân thủ SRP không thông minh, thay vì chúng không bao gồm bất kỳ thông minh nào là không phải là trách nhiệm tự nhiên của chúng. Tương tự như vậy, POCO không câm, chúng chỉ là các đối tượng không được cấy với hành vi từ các nguồn bên ngoài (thư viện của bên thứ ba, mở rộng khung ...)

+1

+1 cho "Có thể bạn sẽ không muốn mọi thuộc tính trong thực thể của mình có thể quan sát được - để báo hiệu thay đổi trong Tổng hợp, hãy sử dụng Sự kiện miền thay thế". – MattDavey

+0

Tôi đặc biệt thích cách thuật ngữ ** "đính kèm" ** tiết lộ vấn đề. – Vukoje

+0

Ngoài ra tôi nghĩ rằng với MSIL thế hệ, những thứ như nhân bản có thể dễ dàng được giao cho các thành phần khác mà không cần phải thay đổi cách dữ liệu được lưu trữ trên đối tượng. Ví dụ: [EmitMapper] (http://emitmapper.codeplex.com/). Tôi cũng đồng ý rằng theo dõi trạng thái bên trong đối tượng có xu hướng gây khó khăn nhưng tôi cũng không thích phụ thuộc hoàn toàn vào theo dõi trạng thái ORM vì nó thường đòi hỏi một số kỹ thuật cực đoan. Nhưng may mắn thay Id tài sản đó là 0 cho các đối tượng mới đi một cách đăng nhập. – Vukoje

1

Tôi sẽ gắn bó với mô hình bên trong POCO vì những "đối tượng thông minh" này giới thiệu rất nhiều phức tạp. Mô hình phải đơn giản như vậy, chỉ mang theo logic nghiệp vụ, không bị ô nhiễm với các tính năng mà có thể hữu ích. Đặc biệt là một kỹ thuật ...

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