Một đối tượng nên biết ID riêng của mình?

obj.idcó vẻ khá phổ biến và dường như cũng nằm trong phạm vi của một thứ mà một đối tượng có thể biết về chính nó. Tôi thấy mình hỏi tại sao đối tượng của tôi nên biết id của chính nó?

Nó dường như không có lý do để có nó? Một trong những lý do chính cho nó hiện có là lấy nó, và vì vậy các kho lưu trữ của tôi cần phải biết nó, và do đó sử dụng nó để tương tác cơ sở dữ liệu.

Tôi cũng đã từng gặp phải một vấn đề khi tôi muốn tuần tự hóa một đối tượng thành JSON cho API RESTful trong đó id dường như không vừa với tải trọng, nhưng chỉ có URI và bao gồm nó trong đối tượng khiến việc đó trở nên khó khăn hơn.

Một đối tượng có nên biết id của chính nó không? Tại sao hay tại sao không?

cập nhật : Điều khoản

1. id: Thuộc tính định danh trên một đối tượng. trong thuật ngữ cơ sở dữ liệu, khóa thay thế không phải là khóa tự nhiên.
2. Đối tượng: một thực thể hoặc đối tượng nhận dạng duy nhất trong hệ thống.

Câu trả lời ngắn: Bao gồm định danh đối tượng trong đối tượng là điều bắt buộc nếu nó sẽ được chuyển đến.

Đối với một kịch bản mà bạn đang dự định sử dụng một bộ sưu tập các đối tượng và có kế hoạch giới thiệu một đối tượng / thực thể riêng lẻ thì nên đưa vào định danh. Tuy nhiên, có thể có trường hợp khóa tự nhiên / mã định danh giống như DateTimecó thể đáp ứng nhu cầu đó một cách giả tạo.

Ngoài ra, bạn có thể có DTO của bạn như một thùng chứa nhẹ đối tượng của mình, có thể bỏ qua / bao gồm cả định danh đối tượng. Thực sự tất cả các lựa chọn này thực sự phụ thuộc vào các trường hợp và nhu cầu sử dụng kinh doanh của bạn .

Chỉnh sửa: nếu bạn muốn xác định đối tượng của mình, bạn cần phải có một định danh. Mã định danh đó có thể là Id thay thế, thời gian, hướng dẫn, v.v ... về cơ bản, bất cứ thứ gì xác định đối tượng của bạn từ người khác theo một cách riêng.

Trong nỗ lực để câu trả lời của tôi trừu tượng như câu hỏi của bạn, tôi nghĩ rằng bạn thực sự đã trả lời câu hỏi của riêng bạn.

Một đối tượng nên biết ID riêng của mình nếu cần.

Một đối tượng không nên biết ID của nó (hoặc thậm chí nó có) nếu không cần thiết.

Như bạn đã chỉ ra, có những trường hợp bất tiện hoặc không cần thiết cho đối tượng giữ lại hoặc biết nếu ID của nó. Nhưng có những trường hợp khác thuận tiện hơn cho đối tượng nhận biết ID của nó. Mã đối tượng của bạn là phù hợp với việc sử dụng của họ.

Việc bao gồm ID khá phổ biến, nhưng cũng thường sử dụng từ điển, nghĩa là các cấu trúc dữ liệu trong đó mỗi đối tượng được liên kết với ID của nó theo cách mà bạn có thể dễ dàng truy xuất đối tượng này khi biết ID tương ứng, nhưng đối tượng không biết nó

Ví dụ: nếu bạn đang tạo API bằng hai phương pháp:

• http://api.example.com/products/

  Tải danh sách ID của sản phẩm.

• http://api.example.com/product/452/

  Tải một sản phẩm của ID 452.

Sau đó, bạn không cần gửi lại ID 452 trong phản hồi JSON của yêu cầu thứ hai. Người dùng API đã biết ID.

Tôi nghĩ rằng điều này là chủ quan và phụ thuộc vào thiết kế của bạn.

Hầu hết mặc dù điều này dường như là một thiết kế đến từ một hồ sơ hoạt động . Trong một bản ghi hoạt động, thực thể của bạn có các phương thức để thực hiện các hoạt động cơ sở dữ liệu và do đó cũng phải biết định danh cơ sở dữ liệu của nó.

Khi sử dụng các mẫu khác như kho lưu trữ với trình ánh xạ dữ liệu lưu trữ dữ liệu này trong đối tượng trở nên không cần thiết và có lẽ không phù hợp.

Lấy ví dụ một Personđối tượng. Tôi được đặt một cái tên có thể hoặc không phải là duy nhất trong một gia đình. Khi dân số ngày càng tăng, những cái tên lớn hơn không còn là duy nhất và vì vậy chúng tôi đã đưa ra các định danh thay thế cho hệ thống ngày càng lớn. Ví dụ về những điều này bao gồm: giấy phép lái xe của tôi và số an sinh xã hội. Tôi không được sinh ra được chỉ định một id, tất cả các id này phải được áp dụng cho.

Hầu hết trong số này không tạo ra các khóa / id chính tốt cho phần mềm, vì chúng không phổ biến. Ít nhất không nằm ngoài hệ thống cụ thể của họ, rõ ràng SSN là duy nhất và nhất quán đối với Cơ quan An sinh Xã hội. Vì chúng tôi thường không phải là nhà cung cấp thông tin này, bạn sẽ không gọi cho họ idmà là dữ liệu họ đại diện, vd SSN. Đôi khi, thậm chí chứa toàn bộ đối tượng được cấu thành, chẳng hạn như DriversLicensecó thể chứa tất cả thông tin mà bằng lái xe thực hiện.

Do đó, tất cả các id chung đều thay thế các khóa trong hệ thống và có thể được thay thế bằng các tham chiếu bộ nhớ, chỉ chứa id để giúp tìm kiếm và lưu giữ các bản ghi dễ dàng hơn.

Vì an idkhông phải là một phần của dữ liệu khái niệm, tôi nghi ngờ rằng nó (nói chung) thuộc về đối tượng, vì nó không đến từ miền. Thay vào đó, nó nên được giữ lại cho mục đích của nó là xác định một đối tượng không có cách nào khác để thể hiện một danh tính duy nhất. Điều này có thể được thực hiện trong một kho lưu trữ / bộ sưu tập dễ dàng.

Trong phần mềm nếu bạn cần biểu diễn đối tượng dưới dạng danh sách hoặc duy trì nó, bạn có thể chỉ cần làm như vậy từ đối tượng kho lưu trữ / bộ sưu tập hoặc một số đối tượng khác được liên kết với điều đó. Khi chuyển sang Trình ánh xạ dữ liệu (nếu tách riêng), bạn có thể chỉ cần vượt qua .update( id, obj ).

Tuyên bố miễn trừ trách nhiệm : Tôi chưa cố gắng xây dựng một hệ thống không chứa id trong thực thể và do đó có thể chứng minh rằng tôi đã sai.

Như GlenH7 đã lưu ý trong một bình luận, đó là một câu hỏi hay, bởi vì nó thách thức những gì nhiều người cho là điều hiển nhiên. Tuy nhiên, tôi nghĩ rằng ngay cả khi bỏ id ra có vẻ thuần túy về mặt khái niệm, điều thực tế cần làm là giữ id với đối tượng trên càng nhiều lớp của hệ thống càng tốt. Nó ít tốn kém, nhưng có thể có ích khi mọi thứ bắt đầu đổ vỡ.

Một thực thể có thể không cần biết id đó, giống như một người không cần biết số nhận dạng cá nhân, số bằng lái xe cũng như bất kỳ số nhận dạng nào khác có thể được sử dụng ở vị trí của bạn. Bạn chắc chắn có thể làm mà không cần nó hầu hết thời gian. Tuy nhiên, thật khôn ngoan khi mang theo một số loại nhận dạng cho bạn, chỉ trong trường hợp.

Điều tương tự có thể được nói về một đối tượng. Bất kể sự phức tạp của lớp truy cập dữ liệu, đối tượng cuối cùng sẽ ánh xạ tới một mục cơ sở dữ liệu nhất định. Mục này chỉ có thể được nhận dạng duy nhất bởi id của đối tượng. Nếu vậy, tôi muốn có sẵn thông tin này cho tôi bất cứ lúc nào, bất kể tôi có gỡ lỗi một số mã UI, số bị bẻ khóa trong lớp nghiệp vụ, chính kho lưu trữ hoặc hệ thống phụ thuộc trên dịch vụ web. Hoặc cho dù tôi đang duyệt nhật ký lỗi cho vấn đề đó.

Trong trường hợp của bạn, nếu bạn chỉ tìm nạp dữ liệu từ db và đẩy nó qua dịch vụ web, việc bỏ id ra có thể là điều nên làm. Tôi chỉ không tin rằng nó có ý nghĩa hơn là giữ nó trong trường hợp chung.

Bạn đã đúng, bạn không cần lưu trữ id trong đối tượng, miễn là bạn chỉ cần biết nó trong ngữ cảnh kho lưu trữ của bạn.

Tình huống thay đổi khi bạn chuyển đối tượng sang mã bên ngoài bối cảnh đó, mã không yêu cầu đối tượng theo id (và do đó chưa biết nó), nhưng cần id cho bất kỳ mục đích nào (ví dụ: để đặt nó vào danh sách của các id sẽ được yêu cầu từ kho lưu trữ sau đó, bằng một mã khác).

Trong tình huống đó, bạn có hai lựa chọn:

• giới thiệu một đối số chức năng mới 'id' trong toàn bộ chuỗi chức năng giữa bối cảnh kho lưu trữ và chức năng cần id

• bao gồm id trong đối tượng

Trong hầu hết các trường hợp này, lưu trữ id bên trong đối tượng sẽ là giải pháp tốt hơn. Nó cũng sẽ giảm các thay đổi mã khi cần id ở những nơi không lường trước được, cộng với việc đôi khi có thể hữu ích với việc gỡ lỗi.

Đó là lý do tại sao tôi làm điều đó khi tôi làm điều đó.