@LucasHaines 이것이 당신이 조사한 입력 유효성 검사 기능과 어떤 관련이 있습니까?

@jevansaks 이것은 내가 설명하는 입력 유효성 검사 작업과 직접 관련이 있습니다.

엄청난. 공유할 미리 보기 항목이 있으면 기꺼이 사용해 보고 피드백과 생각을 제공하겠습니다.

이것은 Build 2018에서 언급된 일종의 유효성 검사입니다.

`
x:Name="사용자 이름" 헤더="사용자 이름:"
Text="{x:바인드 ViewModel.Person.UserName,
UpdateSourceTrigger=속성 변경,
모드=양방향}" />

x:Name="비밀번호" 헤더="비밀번호:"
Password="{x: ViewModel.Person.Password 바인딩,
UpdateSourceTrigger=로스트포커스,
모드=양방향}"/>
`

@thomasclaudiushuber {Binding}의 일부로 이 작업을 수행하는 것이 얼마나 중요하다고 생각하십니까? 기술적인 문제가 사소하지 않고 하위 수준에서 작동할 수 없기 때문에 묻습니다. 우리의 원래 아이디어는 마크업 컴파일러 변경만 필요하고 하위 수준에서 작동할 수 있는 x:Bind를 지원하는 것이었습니다.

또한 INotifyDataErrorInfo 및 DataAnnotations 패러다임만 지원할 계획이었습니다. 우리는 Binding.ValidationRules와 유사한 것을 추가할 의도가 없었으므로 ValidatesOnNotifyDataErrors에 대한 충분한 필요성을 느끼지 못했습니다.

이 기능이 올바르게 수행될 수 있도록 계속 작업하면서 피드백을 받고 싶습니다!

@stevenbrix

짧은 대답: 예, 당신이 생각하는 것과 계획한 것이 훌륭하게 들립니다. x:Bind만 괜찮고 INotifyDataErrorInfo도 괜찮습니다.

긴:

그냥 x:바인드? 👍

모든 WPF-LOB의 경우에는 항상 컴파일 타임에 알려진 일종의 ViewModel이 있다고 생각할 수 있으며 오리 타이핑이 없으므로 x:Bind가 좋습니다. WPF에서와 동일한 구문을 얻을 수 있도록 지원할 수 있다고 생각했기 때문에 이 문제에서도 {Binding}을 작성했습니다. 그러나 이것은 매우 중요한 것보다 "있으면 좋은" 것입니다. 그리고 {Binding}과 x:Bind는 이면에서 완전히 다른 두 가지이고 {Binding}이 포함된 런타임 항목은 언급한 것처럼 중요하지 않으므로 {Binding}은 잊어버리세요. x:Bind용으로만 사용하는 것은 괜찮다고 생각합니다. 내가 생각할 수 있는 사용 사례에서 작동할 것입니다. UWP 및 x:Bind에 대한 모든 회의에서 x:Bind는 모든 XAML 개발자가 가장 좋아하는 UWP 기능 중 하나이며 "어디에서든 바인딩보다 x:Bind를 선호합니다. 할 수있다". :) Intellisense, perf, step-into-code 및 compile-time 오류가 발생하면 UWP에서 x:Bind가 새 기본값이 되므로 유효성 검사 지원을 거기에 두는 것이 좋고 좋은 결정입니다.

INotifyDataErrorInfo 및 DataAnnotations 패러다임만 있습니까? 👍

INotifyDataErrorInfo 및 DataAnnotations 패러다임을 지원하는 것만으로도 기분이 좋습니다. WPF는 데이터 주석을 자동으로 선택하지 않으므로 Validator 클래스를 사용하여 INotifyDataErrorInfo 구현에서 수동으로 연결해야 합니다. "DataAnnotations 패러다임"이라고 할 때 이것을 의미합니까? 아니면 개발자가 속성에 데이터 주석을 넣을 수 있도록 하는 기본 제공 DataAnnotation 지원을 계획하고 있습니까? ASP.NET Core MVC에서처럼? 그게 좋겠지만 필요하지 않다고 생각합니다. ValidationContext, Validator 및 ValidationResult 클래스와 System.ComponentModel.DataAnnotations의 다른 클래스가 있으면 충분합니다.

Binding.ValidationRules를 추가하시겠습니까? 노우 ;-)

아니요, 확실히 추가하지 마십시오. INotifyDataErrorInfo는 충분하고 최고입니다. IDataErrorInfo 지원이 WPF에 추가된 후 더 이상 ValidationRules를 사용하지 않았다고 생각합니다. 그리고 INotifyDataErrorInfo가 .NET Framework 4.5에 추가되었을 때 저와 제 고객은 입력 유효성 검사를 위해 모든 프로젝트에서 해당 인터페이스를 사용했습니다. 이 인터페이스만 지원해도 괜찮습니다.

ValidatesOnNotifyDataErrors를 추가하시겠습니까? 아니, 하지만...

예, 이것을 추가할 필요가 없습니다. 그러나 Binding.ValidationRules와 아무 관련이 없습니다. 이 속성은 INotifyDataErrorInfo 인터페이스와 직접 관련이 있습니다. WPF의 바인딩 마크업 확장에서 ValidatesOnNotifyDataErrors는 기본적으로 true입니다. 즉, 바인딩된 개체가 해당 인터페이스를 구현하는 경우 {Binding}이 구현된 INotifyDataErrorInfo 유효성 검사를 선택합니다. Binding 태그 확장의 ValidatesOnNotifyDataErrors 속성을 false로 설정하면 Binding 태그 확장은 유효성 검사를 위해 INotifyDataErrorInfo 구현을 선택하지 않습니다. 따라서 x:Bind로 구현하는 것이 그리 어렵지 않을 수도 있지만 필요하지 않을 수도 있습니다. 그러니, 하지마. 이건 빼도 괜찮습니다. 그러나 과거에 이것이 필요했던 시나리오를 설명하겠습니다.

WPF 컨트롤은 기본적으로 Validation.ErrorTemplate을 통해 정의된 빨간색 테두리를 표시합니다. 이제 FirstName 속성이 있는 클래스로 INotifyDataErrorInfo 구현이 있다고 가정해 보겠습니다. 필수이므로 FirstName 속성이 null이거나 비어 있으면 오류를 반환합니다. 이제 TextBox를 해당 FirstName 속성에 바인딩했습니다. 사용자가 해당 이름을 제거하면 빨간색 테두리가 나타납니다. 훌륭합니다. 정확히 당신이 원하는 것입니다. 그러나 UI의 다른 위치에 FirstName 속성에도 바인딩된 다른 컨트롤이 있을 수 있습니다. 예를 들어 탭 헤더의 TextBlock. WPF는 유효성 검사 오류가 있는 경우 해당 TextBlock의 빨간색 테두리에도 표시됩니다. 그러나 이것은 당신이 원하는 것이 아닐 수도 있습니다. 사용자가 이름을 변경할 수 있는 TextBox에서만 오류를 원하지만 Tab 헤더의 TextBlock에서는 그렇지 않습니다. TextBlock의 빨간색 테두리를 제거하려면 TextBlock의 ErrorTemplate을 편집할 필요가 없습니다. 대신 ValidatesOnNotifyDataErrors 속성을 false로 설정하여 TextBlock-FirstName-Binding에 대한 INotifyDataErrorInfo 유효성 검사를 설정하면 됩니다. 이것이 내가 이 속성에 대해 가진 유일한 사용 사례입니다. :)

이게 도움이 되길 바란다.

요약

예, 전적으로 동의합니다. INotifyDataErrorInfo를 지원하는 x:Bind에서만 입력 유효성 검사를 수행하는 것이 좋은 계획입니다.

아니요, 환상적인 계획입니다. 벌써부터 매우 기대됩니다!

@thomasclaudiushuber 자세한 후속 조치에 감사드립니다! 당신이 설명하는 핵심 시나리오는 우리가 진정한 가치 동인이라고 믿는 것과 라인업을 구성하므로 좋은 소식입니다. 이 기능과 API의 전체 디자인은 대부분 WPF가 수행한 이전 작업으로 인해 유동적이었습니다. 여기에 몇 가지 중요한 사항이 있었습니다.

1. 위에서 논의한 바와 같이 WPF의 유효성 검사 시스템에는 가치가 추가되지 않았거나 더 나은 패턴으로 대체된 특정 측면이 있었기 때문에 UWP로 가져올 계획이 없었습니다.

2. WPF 유효성 검사 시스템의 특정 기능은 UWP에 없는 핵심 WPF 기능을 활용합니다. 가장 주목할만한 것은 WPF의 모든 UIElement가 컨트롤(일부 템플릿 부분 추가를 통해)뿐만 아니라 유효성 검사 시각적 개체를 표시할 수 있도록 하는 표시기 레이어입니다.

3. UWP Xaml에는 현재 연결된 이벤트의 개념이 없으며 Validation 클래스를 미러링하면 Validation.Error 이벤트가 추가됩니다. 그것은 거래 차단기가 아니라 복잡성을 가중시키기 때문에 일반적으로 새로운 개념을 추가하는 것을 조심하기 때문에 언급할 사항입니다. 또한 작업에는 컨트롤의 템플릿을 변경해야 하므로 특정 템플릿 변경을 제공하는 컨트롤 집합만 기본적으로 작동합니다. 일반적으로 말해서 작동하는 것처럼 보이지만 일부 시나리오에서는 작동하지 않는 API를 사용하는 것은 좋은 습관이 아니므로 해당 모델에서 분리하는 것이 더 낫다고 생각했습니다. 이는 컨트롤이 구현하는 공통 인터페이스 및/또는 속성과 같은 다른 것을 의미합니다.

우리는 여전히 새롭고 흥미로운 오픈 소스 세계에서 API 및 사양 검토를 수행하는 방법을 이해하는 과정에 있습니다. 커뮤니티의 피드백을 받고 싶기 때문에 곧 API 제안을 받아 커뮤니티가 살펴보고 모두가 열광하는 것을 만들 수 있기를 바랍니다!

@stevenbrix 유효성 검사 기능에 대한 오픈 소스 사양을 시작할 때 유효성 검사가 어떻게 보이는지에 대한 일러스트레이션과 샘플 시나리오를 제공하여 대화가 UI 측면에 대해 좀 더 광범위할 수 있도록 하시겠습니까? , 코딩보다 :)

@mdtauk 물론입니다. 우리가 공유한 현재 UI는 여전히 정확합니다. 피드백이 있는 경우 이 스레드에 자유롭게 제공하십시오.

@LucasHaines UI가 좋아 보입니다. 그러나 오류가 표시되는 방식을 어떻게 조정할 수 있는지 궁금합니다. 나는 이것에 관해 아무 것도 찾지 못했고 당신이 이미 그 분야에서 공유할 것이 있는지 모르겠습니다. WPF에서 첨부된 Validation.ErrorTemplate 속성과 유사한 것이 있습니까?

이에 대한 공식적인 사양/제안이 언제 발표될 것인지에 대한 일정이 있습니까?
제품에 더 빨리 적용하려면 어떻게 해야 합니까?

위의 @mrlacey 에 동의합니다... 이제 이것을 사용할 수 있으므로 가능한 한 도움을 드리게 되어 기쁩니다.

우리는 공개 사양을 작업 중이며 사양 리포지토리에서 사용할 수 있음을 모든 사람에게 알릴 것입니다.

질문: IDataErrorInfo도 지원하지 않는 이유는 무엇입니까? .net 표준에서 지원되는데, 지원하지 않는 것이 이상하지 않을까요? 이것은 바인딩에 사용할 인터페이스를 컴파일 타임에 확인할 수 있기 때문에 사용하지 않는 사람들의 성능에 영향을 미치지 않아야 합니다.

공개 사양 리포지토리에서 입력 유효성 검사에 대한 공개 사양 검토를 시작했습니다. https://github.com/Microsoft/microsoft-ui-xaml-specs/pull/26

안녕하세요 여러분, 우리는 이것을 어떻게 추적하고 있습니까? ETA가 있습니까?

@knightmeister 여기에 공개 사양이 생성 되었습니다 . 검토에 참여하고 기능을 형성하는 데 도움을 주세요. 우리는 이것을 WinUI 3.0의 일부로 제공할 계획입니다. WinUI 3.0 로드맵에 대한 자세한 내용은 문제 #717을 확인하십시오.

안녕하세요 여러분 - 사양의 최신 샘플을 살펴보십시오. @stevenbrix 는 샘플에 대한 몇 가지 훌륭한 업데이트를 수행하고 다른 피드백을 처리했습니다.

한 가지 질문: 유효성 검사 정보가 제어 계층으로 흐를까요? 예를 들어 컨테이너 컨트롤(예: TabView 또는 Pivot)이 잘못된 상태의 자식 컨트롤이 있음을 알 수 있습니까?

예를 들어 자식 컨트롤이 잘못된 상태에 있을 때 Pivot 헤더의 스타일을 변경하여 뷰의 어느 부분에 주의가 필요한지 강조 표시하려는 여러 컨테이너 컨트롤이 있는 복잡한 뷰를 생각해 보십시오.

이것은 나에게 중요한 문제입니다.
내 전체 XAML 유효성 검사 시스템은 WPF 유효성 검사 규칙을 기반으로 하며 BindingExpression 에서 필드와 엔터티 모델을 읽고 DA 유효성 검사 특성에 따라 유효성 검사 규칙을 만듭니다( this 참조).

예를 들어 컨테이너 컨트롤(예: TabView 또는 Pivot)이 잘못된 상태의 자식 컨트롤이 있음을 알 수 있습니까?

@tbolon 예, 수행할 수 있는 작업이지만 해당 컨테이너에 내장된 지원이 있을 가능성은 거의 없습니다. 우리는 이 기능이 내장된 Form 컨트롤을 만드는 것에 대해 생각해 보았지만 현재로서는 아마도 백로그에 있을 것입니다. WPF와 마찬가지로 각 컨트롤이 유효하지 않거나 유효하지 않을 때 발생하는 ValidationError (이름이 틀릴 수 있음) 이벤트가 있습니다. 이 이벤트는 라우트된 이벤트가 아니므로 듣고 싶은 각 요소를 구독해야 합니다.

내 전체 XAML 유효성 검사 시스템은 WPF 유효성 검사 규칙을 기반으로 합니다.

@weitzhandler 현재 ValidationRule 와 같은 것을 WinUI에 추가할 계획이 없습니다. 이것을 사용하면 ValidationAttributes 를 사용하고 모델이 INotifyDataErrorInfo 를 구현하도록 하는 것이 있습니까? 사용 시나리오를 더 잘 이해하기 위해 모델과 XAML이 어떻게 생겼는지 보고 싶습니다.

INDEI는 모든 엔터티와 하위 엔터티를 구현하도록 요구합니다.
규칙을 사용하면 변경할 필요가 없으며 모두 유효성 검사 속성만 사용하여 자동으로 작동합니다.

INDEI는 모든 엔터티와 하위 엔터티를 구현하도록 요구합니다.

이에 대해 더 자세히 설명해 주시겠습니까?

규칙을 사용하면 변경할 필요가 없으며 모두 유효성 검사 속성만 사용하여 자동으로 작동합니다.

대부분의 경우 ValidationAttributes 및 INotifyDataErrorInfo 를 사용할 때도 모두 자동으로 작동합니다. 사양에 있는 몇 가지 코드 스니펫을 여기에 표시하겠습니다. 그래서 우리는 (바라건대) 같은 페이지에 있습니다.

FWIW, 우리는 이 ValidationBase 클래스를 Toolkit에 포함할 계획이므로 이 상용구 코드를 직접 작성할 필요가 없습니다.

public class ValidationBase : INotifyPropertyChanged, INotifyDataErrorInfo
{
   public event PropertyChangedEventHandler PropertyChanged;
   public event EventHandler<DataErrorsChangedEventArgs> ErrorsChanged;

   protected void SetValue<T>(ref T currentValue, T newValue, [CallerMemberName] string propertyName = "")
   {
       if (!EqualityComparer<T>.Default.Equals(currentValue, newValue))
       {
           currentValue = newValue;
           OnPropertyChanged(propertyName, newValue);
       }
   }

   readonly Dictionary<string, List<ValidationResult>> _errors = new Dictionary<string, List<ValidationResult>>();
   public bool HasErrors
   {
       get
       {
           return _errors.Any();
       }
   }
   public IEnumerable GetErrors(string propertyName)
   {
       return _errors[propertyName];
   }

   private void OnPropertyChanged(string propertyName, object value)
   {
       PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
       Validate(propertyName, value);
   }

   private void AddErrors(string propertyName, IEnumerable<ValidationResult> results)
   {
       if (!_errors.TryGetValue(propertyName, out List<ValidationResult> errors))
       {
           errors = new List<ValidationResult>();
           _errors.Add(propertyName, errors);
       }

       errors.AddRange(results);
       ErrorsChanged?.Invoke(this, new DataErrorsChangedEventArgs(propertyName));
   }

   private void ClearErrors(string propertyName)
   {
       if (_errors.TryGetValue(propertyName, out List<ValidationResult> errors))
       {
           errors.Clear();
           ErrorsChanged?.Invoke(this, new DataErrorsChangedEventArgs(propertyName));
       }
   }

   public void Validate(string memberName, object value)
   {
       ClearErrors(memberName);
       List<ValidationResult> results = new List<ValidationResult>();
       bool result = Validator.TryValidateProperty(
            value,
            new ValidationContext(this, null, null)
            {
                MemberName = memberName
            },
            results
            );

        if (!result)
        {
            AddErrors(memberName, results);
        }
    }
}

그러면 모델이 해당 클래스에서 파생되고 다음과 같이 표시됩니다.

public class Person : ValidationBase
{
    private string name;
    [MinLength(4)]
    [MaxLength(6)]
    public string Name
    {   
        get { return name; }
        set { SetValue(ref name, value); }
    }
}

이 Person 클래스가 Page 의 ViewModel 속성으로 설정되어 있다고 가정하면 이에 바인딩하고 유효성 검사가 자동으로 발생합니다.

<TextBox Text="{x:Bind ViewModel.Name, Mode=TwoWay}" />

이것이 오늘날 여러분이 하고 있는 것과 약간 다를 수 있다는 것을 이해하지만, 필요하지 않은 경우 동일한 작업을 수행하는 두 가지 다른 방법을 지원하지 않으려고 합니다. 이것이 말이 되는지, 아니면 아직 우리가 놓치고 있는 것이 있다고 생각한다면 알려주세요!

당신 말이 맞아요. 하지만 당신의 엔티티는 POCO가 아니어야 합니다.
한번 해봐야겠네요. LoB 앱에서 EntityBase 클래스를 사용하는 것은 그리 나쁘지 않을 수 있습니다. 나는 단지 POCO를 사용하는 데 익숙합니다.

UWP에는 *HAVE Validation* 이 없습니다!!!!!!! 방금 프로젝트를 시작했습니다. 몇 년 전까지 WPF로 돌아가십시오.

@rufw91 알죠?!

당신의 시간 제약은 무엇입니까? 이것의 첫 번째 구현은 WinUI3 알파에 있으며 //Build 시간 프레임에 곧 제공될 WinUI 데스크톱에 대한 미리 보기가 있어야 합니다. 우리는 올해 말까지 RTM'을 할 계획입니다.

UWP에는 *HAVE Validation* 이 없습니다!!!!!!! 방금 프로젝트를 시작했습니다. 몇 년 전까지 WPF로 돌아가십시오.

앞으로 몇 년 동안 WPF도 계속 사용하기로 결정했습니다. 나는 모든 일(WPF, SL, WP, UWP 등)을 수행했지만 결국 WPF인 단 1개의 기술만 견고해 보입니다. 몇 년 안에 WinUI가 어디에 있는지 확인하는 것이 흥미로울 수 있지만 새로운 기술로 전환하고 어둠 속에 홀로 남겨지는 데 지쳤습니다. WPF는 성숙하고 훌륭하게 작동합니다. 아마도 몇 년 안에 OS로서의 Windows는 전혀 관련이 없을 것이므로 플랫폼에 더 많은 투자를 하기 전에 기다려 봅시다.

아마도 몇 년 안에 OS로서의 Windows는 전혀 관련이 없을 것이므로 플랫폼에 더 많은 투자를 하기 전에 기다려 봅시다.

Windows 10 설치 수가 10억 개를 막 넘었다는 점을 고려할 때 그것이 사실이 될지 믿기 어렵습니다. 그러나 나는 확실히 당신의 좌절감을 느끼고 WPF에 머무르는 것에 대해 당신을 비난하지 않습니다. FWIW, 우리 팀은 지금 WPF의 소유권을 가지고 있으므로 우리가 거기에서 하는 것을 보고 싶은 것이 있으면 알려주십시오.

INDEI는 모든 엔터티와 하위 엔터티를 구현하도록 요구합니다.

이에 대해 더 자세히 설명해 주시겠습니까?

내 코드를 사용하면 모든 POCO 엔터티가 해당 인터페이스를 구현하지 않고 기본 클래스 없이 유지될 수 있습니다. INPC는 Fody를 사용하여 자동으로 구현됩니다. 더 세련된 유효성 검사가 필요할 때 IValidatableObject 를 구현하는 것이 가장 좋습니다. 그리고 하위 유형에서도 작동합니다.

FWIW, 우리는 이 ValidationBase 클래스를 Toolkit에 포함할 계획이므로 이 상용구 코드를 직접 작성할 필요가 없습니다.

그건 좋지 않아. 내 엔터티에 이미 기본 클래스가 있는 경우 어떻게 합니까? 이것이 내가 INotifyDataErrorInfo 의 열렬한 팬이 아닌 이유이기도 합니다. INPC 속성은 특히 수많은 엔터티가 있는 대규모 데이터 앱을 처리할 때 이미 골칫거리입니다.

UWP에 아직 적절한 유효성 검사가 없다는 것은 매우 충격적입니다. 이는 거의 모든 앱에서 가장 중요한 기본 기능이며 최우선 순위를 두어야 합니다.

UWP에 아직 적절한 유효성 검사가 없다는 것은 매우 충격적입니다. 이는 거의 모든 앱에서 가장 중요한 기본 기능이며 최우선 순위를 두어야 합니다.

네, 그래서 저희가 노력하고 있습니다 :)

그건 좋지 않아. 내 엔터티에 이미 기본 클래스가 있는 경우 어떻게 합니까?

나는 여기에서 당신의 사용법을 이해하려고 노력하고 있습니다. 기본 클래스는 무엇이며 이 클래스에서 파생될 수 있습니까?

네, 그래서 저희가 노력하고 있습니다 :)

감사합니다. 감사합니다. 이것과 나머지 작업.
Needs-winui-3 레이블은 무엇을 의미합니까?

나는 여기에서 당신의 사용법을 이해하려고 노력하고 있습니다. 기본 클래스는 무엇이며 이 클래스에서 파생될 수 있습니까?

내 클라이언트에서 생성된 엔터티를 가져오기 위해 OData Connected Service 를 사용하고 있습니다.
생성된 객체는 다음 패턴입니다.

c# public abstract partial class ContactBase : Microsoft.OData.Client.BaseEntityType, INotifyPropertyChanged

Needs-winui-3 레이블은 무엇을 의미합니까?

@weitzhandler
이는 입력 유효성 검사가 WinUI 3과 함께 제공될 것임을 의미합니다. (현재 계획된 대로 3.0). 지금까지 유지 관리 모드에 있는 OS XAML 코드를 변경해야 하므로 WinUI 2에는 나오지 않을 것입니다.

Uno Platform 앱에서 UWP를 사용하고 있습니다. WinUI가 출시되면 다룰 것입니다.
업데이트 주셔서 감사합니다!

나는 여기에서 당신의 사용법을 이해하려고 노력하고 있습니다. 기본 클래스는 무엇이며 이 클래스에서 파생될 수 있습니까?

기본 클래스를 갖는 것은 제3자에 의해 요구되는 경우가 많습니다(예: 사용하는 지속성 프레임워크). UWP/WinUI도 유효성 검사를 위한 기본 클래스를 요구하는 것도 옵션이 아닙니다. 유용하려면 인터페이스가 필요하며, 우리의 어떤 애플리케이션도 기본 클래스를 사용할 수 없습니다. (즉, 사용하려는 사람들을 위한 기본 클래스를 가질 수 없다는 의미는 아닙니다. 유효성 검사를 수행하는 유일한 방법이 아니라 선택 사항일 필요가 있습니다.)

기본 클래스를 갖는 것은 제3자에 의해 요구되는 경우가 많습니다(예: 사용하는 지속성 프레임워크). UWP/WinUI도 유효성 검사를 위한 기본 클래스를 요구하는 것도 옵션이 아닙니다. 유용하려면 인터페이스가 필요하며, 우리의 어떤 애플리케이션도 기본 클래스를 사용할 수 없습니다.

조금 백업합시다. 내가 만든 마지막 몇 개의 댓글이 약간의 혼란을 일으켰다고 생각합니다. 이는 제 잘못입니다.

모델에 필요한 모든 것은 System.ComponentModel.INotifyDataErrorInfo (또는 C++의 경우 Windows.UI.Xaml.Data.INotifyDataErrorInfo )를 구현하는 것입니다. 컴파일러는 {x:Bind} 를 사용할 때 뷰와 연결하는 코드를 적절하게 생성합니다.

위에서 언급한 ValidationBase 클래스는 INotifyPropertyChanged 와 함께 이것을 구현하는 커뮤니티 툴킷에 제공할 계획이었던 도우미 클래스입니다. 사용 사례에서 허용하지 않는 경우 파생할 필요가 없습니다.

@stevenbrix의 설명에 감사드립니다.

유효성 검사 특성 및 IValidatableObject 는 어떻습니까? UWP 런타임에서 이를 존중합니까?

앞서 언급한 MaxLength 속성과 같은 다른 속성은 ASP.NET에서와 같이 TextBox 최대 길이가 자동으로 설정됩니까?
DataTypeAttribute , EditableAttribute 와 동일합니다.
또한 필드 헤더를 생성하기 위한 DisplayAttribute 입니다.
내가 기억하는 한 그것들은 모두 Silverlight에서 지원되었습니다.

( 이 참조).

유효성 검사 특성과 IValidatableObject는 어떻습니까? UWP 런타임에서 이를 존중합니까?

따라서 현재 Required 속성을 지원할 예정입니다. 일부 컨트롤은 이것이 사용될 때 헤더 텍스트 옆에 자동으로 작은 별표를 표시합니다. 당신이 원한다면 우리는 앞으로 더 많은 것을 지원할 준비가 되어 있습니다. 더 많은 것을 보고 싶으시다면 별도의 문제를 여십시오. 기대치를 설정하기 위해 추가 속성 지원은 초기 WinUI3 릴리스를 만들 가능성이 거의 없습니다.

IValidatableObject 에 관해서는 그것이 어떻게 작동하는지 잘 모르겠습니다. 일반화하면, 우리 엔진은 단순히 INotifyDataErrorInfo.ErrorsChanged 이벤트를 수신하여 작동합니다. 모델의 실제 유효성 검사는 앱 개발자에게 달려 있으며 일반적으로 대상에서 소스로 값을 전송할 때 수행됩니다.

제안한 ValidationBase 에 대한 대안으로 Validator.TryValidateObject 를 사용하여 유효성 검사 프로세스를 실행하고 유효성 검사 결과를 엔터티에 삽입하여 변경 사항을 알리는 확장 메서드 집합이 있어야 합니다. ?
이런 식으로 INotifyDataErrorInfo 를 구현하면 쉽게 달성할 수 있습니다. 또한 오류 컬렉션을 보유하는 속성을 추가하는 INotifyDataErrorInfo 에서 상속하는 인터페이스를 가질 수 있으므로 UWP 런타임 또는 도구 키트가 대신 자동화된 유효성 검사 가능한 엔터티로 인식하고 구현된 경우 속성을 자동으로 설정할 수 있습니다.

아마도 당신이 제안한 ValidationBase에 대한 대안으로 Validator.TryValidateObject를 사용하여 유효성 검사 프로세스를 실행하고 유효성 검사 결과를 엔터티에 주입하여 변경 사항을 알리는 확장 메서드 집합이 있어야 합니다.

이것은 좋은 아이디어입니다 :)

🦙 새로운 소스 생성기 패러다임이 여기에서도 도움이 될 수 있는지 궁금하십니까?

예 @michael-hawker, 나는 당신의 생각을 좋아합니다!

얼마 전에 새로운 소스 생성기 가능성에 대해 처음 읽었을 때도 같은 생각을 했습니다.

새로운 소스 생성기 패러다임을 사용하면 INotifyDataErrorInfo 및 INotifyPropertyChanged에 대한 배후에서 많은 것을 빌드/생성할 수 있다고 생각합니다.

유효성 검사를 위한 데이터 주석을 포함하여 T4, INotifyPropertyChanged 및 INotifyDataErrorInfo로 정확히 이 작업을 수행하는 Pluralsight에 대한 WPF 과정이 있습니다. https://www.pluralsight.com/courses/wpf-mvvm-advanced-model-treatment
이 과정은 또한 사용자 지정 연결된 속성을 사용하여 항목을 연결합니다.
이 과정의 목표는 모든 입력 필드가 변경되고 원래 값이 무엇인지 표시하는 MVVM WPF 앱을 빌드하는 방법을 보여주는 것입니다.

따라서 확실히 무언가를 생성하고 라이브러리로 끝나는 것(WCT의 일부로)은 굉장할 것입니다. 그리고 나는 WinUI를 위해 그 과정을 다시 하고 싶습니다. :)

@rufw91 알죠?!

당신의 시간 제약은 무엇입니까? 이것의 첫 번째 구현은 WinUI3 알파에 있으며 //Build 시간 프레임에 곧 제공될 WinUI 데스크톱에 대한 미리 보기가 있어야 합니다. 우리는 올해 말까지 RTM'을 할 계획입니다.

@stevenbrix 희망합니다. WPF로 다시 전환해야 했습니다. 이제 거의 완료되었습니다.

나는 이것을 열었습니다.

이에 대한 후속 조치로 Twitter에서 @stevenbrix 와 대화한 후 그가 여기 에 제공한 기본 INotifyDataErrorInfo 구현을 새로운 MVVM 툴킷에 포함되는 새로운 ObservableValidator 클래스에 통합했습니다. Microsoft.Toolkit.Mvvm 라이브러리), INotifyPropertyChanged 및 INotifyPropertyChanging 도 구현합니다. 😄

이번 호 에서 관련 코드와 해당 라이브러리와 관련된 모든 내용의 요약을 볼 수 있습니다.
또한 MVVM Toolkit의 원래 문제에 대한 링크와 새로운 개발자를 위한 추가 문서도 포함했습니다.

이에 대한 최신 정보를 제공해 주시겠습니까? UWP 10.0 18362가 INotifyDataErrorInfo 를 지원하는지 궁금합니다. 다음 문서 페이지에 따르면 https://docs.microsoft.com/en-us/dotnet/api/system.componentmodel.inotifydataerrorinfo?view=netcore-3.1 INotifyDataErrorInfo UWP 10.0에 "적용"됩니다. 그러나 UWP 10.0 18362를 설치하고 대상으로 지정하면 텍스트 상자에 INotifyDataErrorInfo 유효성 검사가 표시되지 않습니다. 텍스트 상자는 XAML에서 다음과 같이 설명됩니다.

<TextBox Text="{x:Bind ViewModel.Username, Mode=TwoWay, UpdateSourceTrigger=PropertyChanged}" />

그리고 여기서 ReactiveValidationObject 를 INotifyDataErrorInfo 구현으로 사용합니다.

@worldbeater 이것은 WinUI3의 최신 미리 보기에서만 사용할 수 있습니다. 사용 중이신가요?

@stevenbrix 감사합니다! WinUI3를 사용하려고 합니다. INotifyDataErrorInfo 와 UWP가 드디어 친구가 되어 기쁩니다 ✨

@worldbeater , 아직 미리 보기 단계이므로 이에 대한 피드백을 받고 싶습니다! 💪

그건 그렇고 @worldbeater 는 문서에 UWP 10.0에서 사용할 수 있다고 나와 있지만 UWP 10.0에서 지원한다는 의미는 아닙니다. 문서가 충분히 명확하지 않습니다.