Những nhược điểm để ánh xạ định danh tích phân vào enums là gì?

Tôi đã suy nghĩ về việc tạo các loại tùy chỉnh cho các định danh như thế này:

public enum CustomerId : int { /* intentionally empty */ }
public enum OrderId : int { }
public enum ProductId : int { }

Động lực chính của tôi cho việc này là để ngăn chặn loại lỗi mà bạn vô tình truyền một orderItemId cho một chức năng đang mong đợi một orderItemDetailId.

Dường như enums hoạt động trơn tru với mọi thứ tôi muốn sử dụng trong một ứng dụng web .NET thông thường:

• Định tuyến MVC hoạt động tốt
• Tuần tự hóa JSON hoạt động tốt
• Mỗi ORM tôi có thể nghĩ là hoạt động tốt

Vì vậy, bây giờ tôi tự hỏi, "tại sao tôi không nên làm điều này?" Đây là những nhược điểm duy nhất tôi có thể nghĩ đến:

• Nó có thể gây nhầm lẫn cho các nhà phát triển khác
• Nó giới thiệu sự không nhất quán trong hệ thống của bạn nếu bạn có bất kỳ định danh không tách rời nào.
• Nó có thể yêu cầu đúc thêm, như (CustomerId)42. Nhưng tôi không nghĩ rằng đây sẽ là một vấn đề, vì định tuyến ORM và MVC thường sẽ trao trực tiếp cho bạn các giá trị của loại enum.

Vì vậy, câu hỏi của tôi là, tôi đang thiếu gì? Đây có lẽ là một ý tưởng tồi, nhưng tại sao?

Đó là một ý tưởng tuyệt vời để tạo loại cho mọi loại định danh, chủ yếu là vì những lý do bạn đã nêu. Tôi sẽ không làm điều đó bằng cách triển khai kiểu như enum bởi vì làm cho nó trở thành một cấu trúc hoặc lớp thích hợp cung cấp cho bạn nhiều tùy chọn hơn:

• Bạn có thể thêm chuyển đổi ngầm định vào int. Khi bạn nghĩ về nó, đó là một hướng khác, int -> CustomerId, đó là một vấn đề đáng được xác nhận rõ ràng từ người tiêu dùng.
• Bạn có thể thêm các quy tắc kinh doanh xác định những định danh nào được chấp nhận và những gì không. Đây không chỉ là về việc kiểm tra yếu xem liệu int có tích cực hay không: đôi khi, danh sách tất cả các ID có thể được lưu trong cơ sở dữ liệu, nhưng chỉ thay đổi trong quá trình triển khai. Sau đó, bạn có thể dễ dàng kiểm tra xem ID đã cho có tồn tại so với kết quả được lưu trong bộ nhớ cache của truy vấn phù hợp không. Bằng cách này, bạn có thể đảm bảo rằng ứng dụng của bạn sẽ thất bại nhanh chóng khi có dữ liệu không hợp lệ.
• Các phương thức trên mã định danh có thể giúp bạn thực hiện kiểm tra tồn tại DB đắt tiền hoặc có được đối tượng thực thể / miền tương ứng.

Bạn có thể đọc về việc thực hiện điều này trong bài viết Chức năng C #: Nỗi ám ảnh nguyên thủy .

Đó là một hack thông minh, nhưng vẫn là một hack trong đó lạm dụng một tính năng cho một cái gì đó không phải là mục đích dự định. Hacks có chi phí bảo trì, do đó, bạn không thể tìm thấy bất kỳ nhược điểm nào khác, nó cũng cần có lợi ích đáng kể so với cách thức thành ngữ hơn để giải quyết vấn đề tương tự.

Cách thành ngữ sẽ là tạo kiểu trình bao bọc hoặc cấu trúc với một trường duy nhất. Điều này sẽ cung cấp cho bạn sự an toàn cùng loại theo cách rõ ràng và thành ngữ hơn. Mặc dù đề xuất của bạn được thừa nhận thông minh, tôi không thấy bất kỳ lợi thế đáng kể nào khi sử dụng các loại trình bao bọc.

Từ POV của tôi, ý tưởng là tốt. Ý định đưa ra các loại khác nhau cho các lớp định danh không liên quan, và mặt khác thể hiện ngữ nghĩa thông qua các loại và để trình biên dịch kiểm tra nó, là một cách tốt.

Tôi không biết làm thế nào nó hoạt động trong .NET Performance-khôn ngoan, ví dụ như các giá trị enum nhất thiết phải được đóng hộp. Mã OTOH hoạt động với cơ sở dữ liệu có khả năng bị ràng buộc I / O và các mã định danh được đóng hộp sẽ không bị tắc nghẽn.

Trong một thế giới hoàn hảo, các định danh sẽ là bất biến và chỉ có thể so sánh cho sự bình đẳng; byte thực tế sẽ là một chi tiết thực hiện. Các mã định danh không liên quan sẽ có các loại không tương thích, do đó bạn không thể sử dụng loại này cho loại khác. Giải pháp của bạn thực tế phù hợp với hóa đơn.

Bạn không thể làm điều này, enums phải được xác định trước. Vì vậy, trừ khi bạn sẵn sàng xác định trước toàn bộ phổ các giá trị có thể có của id khách hàng, loại của bạn sẽ vô dụng.

Nếu bạn sử dụng, bạn sẽ bất chấp mục tiêu chính của mình là ngăn chặn việc vô tình gán id loại A cho id loại B. Vì vậy, enums không hữu ích cho mục đích của bạn.

Điều này sẽ đưa ra câu hỏi mặc dù nó sẽ hữu ích để tạo các loại của bạn cho id khách hàng, id đơn hàng và id sản phẩm bằng cách giảm dần từ Int32 (hoặc Guid). Tôi có thể nghĩ ra một lý do tại sao điều này sẽ sai.

Mục đích của một id là nhận dạng. Các kiểu tích phân đã hoàn hảo cho việc này, chúng không nhận được bất kỳ nhận dạng nào nữa bằng cách giảm dần từ chúng. Không có chuyên môn cần thiết cũng không mong muốn, thế giới của bạn sẽ không được thể hiện tốt hơn bằng cách có các loại khác nhau cho định danh. Vì vậy, từ góc độ OO, nó sẽ là xấu.

Với đề xuất của bạn, bạn muốn nhiều hơn an toàn kiểu, bạn muốn an toàn giá trị và đó là ngoài phạm vi mô hình, đó là một vấn đề hoạt động.