Làm cách nào để xử lý xác thực đối tượng miền trước khi nó tiếp tục tồn tại?

Question

Một thực thể (giả sử UserEntity) có quy tắc cứng nhắc cho thuộc tính của nó và có thể tồn tại ở 2 trạng thái - vẫn tồn tại (có nghĩa là có id) và được giữ nguyên trước (nghĩa là chưa có số id).

Theo câu trả lời cho this question about how to handle required properties, UserEntity "thực" chỉ được tạo bằng một id được truyền vào hàm khởi tạo của nó.

Tuy nhiên, khi tôi cần tạo một new UserEntity từ thông tin do trình duyệt gửi, tôi cần có khả năng xác thực thông tin trước khi lưu vào db.

Trước đây, tôi chỉ cần tạo UserEntity trống (không có id), đặt thuộc tính mới và xác thực thuộc tính - nhưng, theo cách nghĩ mới, an toàn hơn về thực thể này, tôi không bao giờ nên tạo UserEntity mới mà không cần id.

Tôi không muốn tạo HAI địa điểm biết cách xác thực các thuộc tính của UserEntity, bởi vì nếu chúng thay đổi (và chúng sẽ) sẽ tăng gấp đôi mã để cập nhật và tăng gấp đôi khả năng lỗi.

Làm cách nào để tập trung hiệu quả kiến ​​thức xác thực của các thuộc tính của đối tượng của tôi?

Note

Một ý tưởng tôi đã được phản ánh in this question, trong đó tôi xem xét lưu trữ các thuộc tính ngoài quốc doanh như email, mật khẩu và tên trong một đối tượng giá trị tiêu chuẩn đó sẽ biết về các quy tắc cho thuộc tính của nó mà các dịch vụ khác nhau, như Controller, Validator và Repo hoặc Mapper có thể sử dụng.

Answer 1

đó là những gì các nhà máy dành cho. đối với phương thức nhà máy, bạn chỉ truyền dữ liệu cần thiết để thực thi các bất biến thực của UserEntity (dành một chút thời gian để tìm ra những bất biến thực sự của UserEntity của bạn và bạn nên làm điều đó với các chuyên gia tên miền của mình).

trong phương pháp nhà máy bạn tạo Id mới và chuyển nó tới hàm tạo UserEntity.

Trong giai đoạn này tôi không nghĩ rằng đó là xấu để loại bỏ các trường hợp nếu xác nhận bên trong các nhà xây dựng thất bại. trong trường hợp xấu nhất - bạn đã mất một id ... nó không phải là một trường hợp mà giả sử xảy ra khá thường xuyên - hầu hết thời gian dữ liệu phải được xác nhận trong máy khách.

Tất nhiên, một tùy chọn khác là trong phương pháp nhà máy, trước tiên bạn xác thực tham số và chỉ tạo Id mới và chuyển nó tới hàm tạo UserEntity.

itzik saban

Answer 2

Theo tôi, tiết kiệm(), và load() phương pháp này cần được làm cả hai xác nhận và thiết lập thuộc tính ID. Và theo cách mà một thực thể không có thuộc tính Identity không phải là một thực thể.

Theo quan điểm nhận dạng thuộc tính của tôi nên được xác nhận và đảm bảo khi thực thể là trên đường vận chuyển ví dụ

tải từ db, tải từ tập tin hoặc (sau) tiết kiệm để db mà

nếu tải từ db không loại bỏ thực thể lưu vào db/file không loại bỏ thực thể.

Kể từ khi xác nhận là log kinh doanh/hành vi vv và một mô hình tốt hơn cho rằng sẽ là

Chiến lược Pattern (http://en.wikipedia.org/wiki/Strategy_pattern)

Answer 3

Tôi nghĩ rằng bạn có một vài tùy chọn để xem xét:

(1) xem xét nhận xét đầu tiên của bạn:

một Entity (giả sử một UserEntity) có quy tắc cứng nhắc cho nó properti es, và nó có thể tồn tại ở 2 trạng thái - vẫn tồn tại (có nghĩa là nó có id) và được lưu giữ trước (có nghĩa là nó chưa có id).

Ở đây, bạn đã đề cập rằng xác thực thực sự phụ thuộc vào việc thực thể đã được duy trì hay chưa. Nói cách khác, nếu thực thể không được duy trì, thì phải hợp lệ nếu không có ID. Nếu bạn tiếp tục với đặc điểm kỹ thuật tên miền này, tôi cảm thấy xác thực sẽ hành động tương ứng (ví dụ: return isValid ngay cả khi không có ID nếu đối tượng không được duy trì)

(2) Nếu bạn giả sử "có giá trị" có nghĩa là đối tượng có ID, sau đó bạn sẽ cần tạo ID khi tạo. Tùy thuộc vào cách ID của bạn được tạo, điều này có thể phức tạp (ví dụ: lưu vào cơ sở dữ liệu và trả lại ID đã tạo hoặc tạo số nhận dạng duy nhất bằng cách nào đó hoặc ...)

Sử dụng phương pháp tiếp cận này) cho đối tượng của bạn (ví dụ: với ID) để giúp giảm thiểu việc sao chép xác thực trên các trạng thái khác nhau. Hy vọng rằng, điều này bảo vệ các thực thể có nguồn gốc từ việc xác nhận chung là tốt.

Answer 4

Chủ đề về cách xác thực chính xác là phần nào của khu vực màu xám.

Xác thực thường được coi là Xác thực bất biến và Xác thực theo ngữ cảnh. Xác nhận bất biến liên quan đến những điều mà, theo miền vấn đề của bạn, phải có mặt để mô hình của bạn hoạt động đúng trong vai trò dự định của nó. Việc xác thực theo ngữ cảnh liên quan đến trạng thái hợp lệ trong một ngữ cảnh sử dụng cụ thể (ví dụ: Liên hệ được sử dụng để gửi email cần địa chỉ email, nhưng không cần số điện thoại, Liên hệ được sử dụng cho thư mục cần địa chỉ gửi thư, nhưng không cần email , v.v.)

Nếu bạn muốn có kiến ​​trúc thuần túy, thì về mặt kỹ thuật, những lo ngại về xác thực đầu vào (những gì khách hàng của bạn đang nhập vào giao diện người dùng) và trạng thái của một thực thể nhất định là hai mối quan tâm khác nhau. Lý tưởng nhất, tên miền của bạn không có kiến ​​thức về loại ứng dụng cụ thể mà nó được viết và do đó không nên gánh nặng khi cung cấp thông báo lỗi phù hợp để sử dụng trực tiếp hoặc gián tiếp, hiển thị thông báo lỗi cho người dùng. Điều này trình bày một chút vấn đề, vì nó có thể dẫn đến kiểm tra lỗi trùng lặp hoặc ba lần (phía máy khách, phía dịch vụ, cấp miền), do đó, nhiều lựa chọn cho một cách tiếp cận thực dụng hơn để đối phó với hầu hết xác thực bên ngoài đối tượng (ví dụ: xác thực một mô hình đầu vào trước khi tạo đối tượng).

Answer 5

Tôi không thấy sự cố với việc lưu trữ dữ liệu không hợp lệ. Điều gì là hợp lệ hay không là một mối quan tâm kinh doanh và đôi khi có thể phụ thuộc vào tình hình. Cơ sở dữ liệu không quan tâm đến các quy tắc kinh doanh này.

Nếu tôi phải điền vào biểu mẫu lớn trực tuyến và bước cuối cùng yêu cầu tôi nhập thông tin thẻ tín dụng và tôi không có thẻ, tôi sẽ phải loại bỏ tất cả thông tin đó và lần sau nhập lại tất cả (điều này sẽ không xảy ra vì tôi thích đi đâu đó khác).Tôi muốn ứng dụng đó lưu trữ thông tin tôi đã cung cấp và sau này tôi có thể làm cho nó có giá trị về mặt chức năng. Miễn là nó không hợp lệ, tôi không thể đặt hàng trực tuyến.