2012-03-11 27 views
18

Tôi đang nghĩ đến việc sử dụng mẫu Đặc tính cho mục đích xác thực. Điều khó khăn là làm thế nào để nói cho người sử dụng tại sao một số đặc điểm kỹ thuật không hài lòng. Nếu như Specification.IsSatisfiedBy() sẽ không chỉ trả về giá trị bool, mà còn là lý do thất bại. Nó sẽ giống như thế này:DDD Sử dụng mẫu Đặc điểm kỹ thuật để xác thực

interface ISpecification<T> 
{ 
    CheckResult IsSatisfiedBy(T candidate); 
} 

nơi CheckResult là:

class CheckResult 
{ 
    public bool IsSatisfied { get; } 
    public string FailureReason { get; } 
} 

Trong Fowler & Evans việc có một khái niệm về Đặc điểm kỹ thuật một phần hài lòng mà mục đích là để cung cấp lời giải thích chính xác những gì là không hài lòng. Tuy nhiên trong tài liệu đó, nó được triển khai làm phương thức bổ sung remainderUnsatisfiedBy trả về Đặc điểm kỹ thuật không được thực hiện bởi Ứng viên.

Vì vậy, câu hỏi đặt ra là: Khi sử dụng Đặc điểm kỹ thuật cho mục đích xác thực, cách cung cấp phản hồi cho người dùng mà một Đặc điểm kỹ thuật nhất định không hài lòng? Là giải pháp tôi đã trình bày ở trên tốt?

+0

Trước hết, bạn có thực sự chắc chắn rằng Đặc điểm kỹ thuật là con đường để đi không? Ý tôi là, mỗi đặc điểm kỹ thuật có biết bối cảnh nơi một mô hình có thể có hoặc không hợp lệ không? Tôi không thể nói nhiều vì tôi không biết tên miền trông như thế nào. Đối với một số xác nhận đơn giản, tôi nghĩ rằng đó là ok, nhưng đó là những gì DataAnnotation xác nhận thuộc tính đang làm ngay bây giờ. – MikeSW

Trả lời

17

Mặc dù bạn có thể sử dụng các lớp Thông số kỹ thuật để xác thực, tôi khuyên bạn nên giữ chúng dưới dạng các khái niệm riêng trong miền của bạn. Bạn có thể thấy rằng bạn cần phải sử dụng lại các thông số cơ bản giống nhau nhưng cần phải trả về các "Lý do Thất bại" khác nhau tùy thuộc vào mục đích và ngữ cảnh. Xem this article để biết thêm chi tiết.

Tác giả của bài đăng được tham chiếu ở trên cũng đã chia sẻ mã vui vẻ với github và đăng mã như NCommon. Rà soát các khu vực này nói riêng:

Thông số kỹ thuật: https://github.com/riteshrao/ncommon/tree/v1.2/NCommon/src/Specifications

validations: https://github.com/riteshrao/ncommon/tree/v1.2/NCommon/src/Rules (đặc biệt là các lớp học cho ValidationResultValidationError)

+1

Rất đẹp. Cảm ơn câu trả lời. – Markus

+0

Vui mừng nó đã giúp, tốt nhất của may mắn –

+2

Ví dụ từ codeinsanity trông giống như FluentValidation :) – dariol

4

tôi đã cùng một vấn đề. Tôi tạo trang trí xác thực cho đặc điểm kỹ thuật (mã là JAVA).

interface Validator<T>{ 
    Respond validate(T t) 
    } 


    class abstract ValidationSpecificationDecorator<T> implements Validator<T> { 
    Specification<T> spec; 

    ValidationSpecificationDecorator(Specification<T> spec){ 
    this.spec = spec; 
    } 

    public Respond validate(T t) { 
    Respond respond = new Respond(); 
    if(!spec.IsSatisfiedBy(t){ 
     respond.add(error(t)); 
    } 
    return respond; 
) 

    public abstract Error error(T t); 

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