@LucasHaines这与您一直在研究的输入验证功能有何关系？

@jevansaks这与我正在概述的输入验证工作直接相关。

伟大的。 如果您有任何预览内容要分享，我很乐意尝试并提供反馈和想法。

这是 Build 2018 中提到的那种验证

`
x:Name="用户名" 标头="用户名："
Text="{x:绑定 ViewModel.Person.UserName,
UpdateSourceTrigger=PropertyChanged,
模式=双向}" />

x:Name="密码" 标头="密码:"
Password="{x:绑定 ViewModel.Person.Password,
UpdateSourceTrigger=LostFocus,
模式=双向}"/>
`

@thomasclaudiushuber您认为将这项工作作为 {Binding} 的一部分有多重要？ 我之所以问，是因为那里的技术挑战非常重要，而且它无法在下层工作。 我们最初的想法是只支持 x:Bind，它只需要更改标记编译器，并且能够在下层工作。

此外，我们只计划支持 INotifyDataErrorInfo 和 DataAnnotations 范式。 我们不打算添加类似于 Binding.ValidationRules 的东西，因此觉得没有足够的需要 ValidatesOnNotifyDataErrors。

我们很乐意收到您的反馈，因为我们会继续开发此功能，以便正确完成！

@stevenbrix

简短回答：是的，您的想法和计划听起来很棒。 只是 x:Bind 很好，而且只是 INotifyDataErrorInfo 也很好。

长：

只是x：绑定？ 👍

在我能想到的所有 WPF-LOB 案例中，总有一种 ViewModel 在编译时是已知的，没有鸭子类型，所以 x:Bind 很好。 我在这个问题上也写了 {Binding}，因为我认为你可以支持它以获得与 WPF 中相同的语法。 但这比超级重要更“值得拥有”。 由于 {Binding} 和 x:Bind 在幕后是两个完全不同的东西，并且 {Binding} 的运行时东西就像你提到的那样不平凡，忘记 {Binding}。 我认为只为 x:Bind 使用它是完全可以的，它适用于我能想到的用例。 从我就 UWP 和 x:Bind 所做的所有会议演讲中，我可以告诉你，x:Bind 是所有 XAML 开发人员最喜欢的 UWP 功能之一，我告诉他们所有人“无论你在哪里，都更喜欢 x:Bind 而不是 Binding能够”。 :) 获取智能感知、性能、步入代码和编译时错误会使 x:Bind 成为 UWP 上的新默认值，因此在 imo 中拥有验证支持是一个很好的决定。

只是 INotifyDataErrorInfo 和 DataAnnotations 范式？ 👍

仅支持 INotifyDataErrorInfo 和 DataAnnotations 范式对我来说听起来不错。 WPF 不会自动获取数据注释，您需要使用 Validator 类在 INotifyDataErrorInfo 实现中手动连接它们。 当您说“DataAnnotations 范例”时，您的意思是这个，对吧？ 或者您是否计划内置 DataAnnotation 支持，允许开发人员在属性上放置数据注释，这样就可以了？ 就像在 ASP.NET Core MVC 中一样？ 虽然那很好，但我认为没有必要。 拥有 ValidationContext、Validator 和 ValidationResult 类以及 System.ComponentModel.DataAnnotations 中的其他类就足够了。

添加 Binding.ValidationRules？ Nooooo ;-)

不，绝对不要添加。 INotifyDataErrorInfo 就足够了，它是最好的。 在将 IDataErrorInfo 支持添加到 WPF 之后，我想我再也没有使用过 ValidationRules（如果我没记错的话，这是在 .NET Framework 3.5 中）。 当在 .NET Framework 4.5 中添加 INotifyDataErrorInfo 时，我和我的客户在所有项目中都使用该接口进行输入验证。 只支持这个接口就可以了。

添加 ValidatesOnNotifyDataErrors？ 不是，但...

是的，您不必添加这个。 但它与 Binding.ValidationRules 无关。 此属性与 INotifyDataErrorInfo 接口直接相关。 在 WPF 的 Binding Markup Extension 上，ValidatesOnNotifyDataErrors 默认为 true，这意味着如果绑定对象实现了该接口，{Binding} 将获取实现的 INotifyDataErrorInfo 验证。 如果将 Binding 标记扩展上的 ValidatesOnNotifyDataErrors 属性设置为 false，则 Binding 标记扩展将不会选择 INotifyDataErrorInfo 实现进行验证。 所以，也许这用 x:Bind 实现并不难，但也许我们不需要它。 所以，不，不要这样做。 可以忽略这个。 但是让我描述一下我过去需要这个的场景：

WPF 控件默认显示通过 Validation.ErrorTemplate 定义的红色边框。 现在让我们假设您有一个 INotifyDataErrorInfo 实现，其类具有 FirstName 属性。 它是必需的，因此如果 FirstName 属性为 null 或为空，您将返回错误。 现在您将一个 TextBox 绑定到该 FirstName 属性。 当用户删除该名字时，会出现一个红色边框。 太好了，正是你想要的。 但也许您在 UI 的另一个位置也有另一个绑定到 FirstName 属性的控件。 例如 Tab-Header 中的 TextBlock。 当出现验证错误时，WPF 也会在该 TextBlock 上显示一个红色边框。 但这可能不是您想要的。 您希望仅在用户可以更改名字的 TextBox 上出现错误，而不是在 Tab 标题中的 TextBlock 中出现错误。 要消除 TextBlock 上的红色边框，您不必编辑 TextBlock 的 ErrorTemplate，而只需通过将 ValidatesOnNotifyDataErrors 属性设置为 false 来打开 TextBlock-FirstName-Binding 上的 INotifyDataErrorInfo 验证。 这是我曾经有过的这个属性的唯一一个用例。 :)

我希望这有帮助。

概括

是的，我完全同意，仅在 x:Bind 上进行输入验证并支持 INotifyDataErrorInfo 是一个不错的计划。

不，这是一个很棒的计划，我已经超级兴奋了！

@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我们目前不打算向 WinUI 添加类似ValidationRule的东西。 有没有什么东西可以让你放弃使用ValidationAttributes并让你的模型实现INotifyDataErrorInfo ？ 我很想看看您的模型和 XAML 是什么样的，以便更好地了解您的使用场景。

INDEI 要求您实现所有实体和子实体。
使用规则，不需要更改，它只使用验证属性自动工作。

INDEI 要求您实现所有实体和子实体。

你能详细说明一下吗？

使用规则，不需要更改，它只使用验证属性自动工作。

在大多数情况下，当使用ValidationAttributes和INotifyDataErrorInfo时，这一切都会自动运行。 我将在此处展示规范中的一些代码片段，以便我们（希望）在同一页面上。

FWIW，我们计划在 Toolkit 中使用这个ValidationBase类，因此您不必自己编写这个样板代码。

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 上的Page ViewModel属性，然后绑定到该属性，验证会自动发生：

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

我知道这可能与您今天所做的有所不同，但如果我们不需要，我们会尽量不支持两种不同的方式来做同一件事。 让我知道这是否有意义，或者如果您认为我们仍然缺少某些东西！

你是对的，但这要求你的实体是非 POCO。
我应该试一试。 在 LoB 应用程序中使用EntityBase类可能不会那么糟糕。 我只是习惯使用 POCO。

UWP 没有*HAVE Validation* !!!!!!! 我刚开始一个项目。 回到 WPF 直到几年时间。

@rufw91我知道，对吧？！

你的时间限制是什么？ 这个的第一个实现是在 WinUI3 alpha 中，我们应该在 //Build 时间范围内很快就会有 WinUI 桌面的预览。 我们计划在年底前进行 RTM

UWP 没有*HAVE Validation* !!!!!!! 我刚开始一个项目。 回到 WPF 直到几年时间。

我决定在接下来的几年里也坚持使用 WPF。 我已经完成了所有工作（WPF、SL、WP、UWP 等），最后只有一项技术看起来很可靠，那就是 WPF。 也许几年后看看 WinUI 在哪里可能会很有趣，但我厌倦了切换到新技术并在黑暗中独自一人。 WPF 很成熟，效果很好。 也许几年后，Windows 作为一个操作系统根本就无关紧要了，所以让我们在对该平台进行更多投资之前等待它。

也许几年后，Windows 作为一个操作系统根本就无关紧要了，所以让我们在对该平台进行更多投资之前等待它。

考虑到我们刚刚超过 10 亿次 Windows 10 安装，我很难相信这会成为现实。 但我绝对能感受到你的挫败感，不要责怪你继续使用 WPF。 FWIW，我们的团队现在正在获得 WPF 的所有权，所以如果您想看到我们在那里做任何事情，请告诉我。

INDEI 要求您实现所有实体和子实体。

你能详细说明一下吗？

使用我的代码，所有 POCO 实体都可以不用实现这些接口，也可以不用基类。 INPC 使用 Fody 自动实现。 当需要更精细的验证时，我最想做的就是实施IValidatableObject 。 它也适用于子类型。

FWIW，我们计划在 Toolkit 中使用这个ValidationBase类，因此您不必自己编写这个样板代码。

那不好。 如果我的实体已经有一个基类怎么办？ 这也是为什么我不是INotifyDataErrorInfo的忠实粉丝。 INPC 属性已经让他们自己头疼，尤其是在处理包含大量实体的海量数据应用程序时。

令人震惊的是，UWP 还没有适当的验证。 这是几乎所有应用程序中的一个关键基本功能，应该放在首位。

令人震惊的是，UWP 还没有适当的验证。 这是几乎所有应用程序中的一个关键基本功能，应该放在首位。

是的，这就是我们正在努力的原因:)

那不好。 如果我的实体已经有一个基类怎么办？

我只是想了解您在这里的用法。 什么是基类，它可以从这个类派生吗？

是的，这就是我们正在努力的原因:)

谢谢，非常感谢。 这个，还有你的其他工作。
标签需要-winui-3意味着什么？

我只是想了解您在这里的用法。 什么是基类，它可以从这个类派生吗？

我正在使用OData Connected Service来获取在我的客户端上生成的实体。
生成的对象是这种模式：

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

标签需要-winui-3 意味着什么？

@weitzhandler
这意味着输入验证将随 WinUI 3 一起提供。（目前计划为 3.0）。 它可能不会出现在 WinUI 2 中，因为这需要更改目前处于维护模式的 OS XAML 代码。

我在 Uno 平台应用程序中使用 UWP。 希望 WinUI 将在其发布时被覆盖。
感谢您的更新！

我只是想了解您在这里的用法。 什么是基类，它可以从这个类派生吗？

拥有一个基类通常是由第三方强制要求的，例如您使用的持久性框架。 UWP/WinUI 也要求基类仅用于验证不是一种选择。 它必须是一个有用的接口，我们的应用程序都不能使用基类。 （这并不意味着您不能为想要使用它的人提供基类，它只需要是可选的，而不是进行验证的唯一方法。）

拥有一个基类通常是由第三方强制要求的，例如您使用的持久性框架。 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 构建/生成很多东西。

我有一个关于 Pluralsight 的 WPF 课程，它与 T4、INotifyPropertyChanged 和 INotifyDataErrorInfo 完全一样，包括用于验证的数据注释： https ://www.pluralsight.com/courses/wpf-mvvm-advanced-model-treatment
该课程还使用自定义附加属性来连接事物。
本课程的目标是展示如何构建一个 MVVM WPF 应用程序，该应用程序在每个输入字段上显示是否已更改以及原始值是多少。

所以，毫无疑问，生成东西并最终得到一个库（可能是 WCT 的一部分）会很棒。 我很想为 WinUI 重做那门课程。 :)

@rufw91我知道，对吧？！

你的时间限制是什么？ 这个的第一个实现是在 WinUI3 alpha 中，我们应该在 //Build 时间范围内很快就会有 WinUI 桌面的预览。 我们计划在年底前进行 RTM

@stevenbrix我希望如此，我不得不切换回 WPF，实际上我现在差不多完成了。

我打开了这个。

为了跟进这一点，在与 Twitter 上的@stevenbrix交谈后，我将他在此处提供的基本INotifyDataErrorInfo实现集成到新的ObservableValidator类中，该类包含在新的 MVVM 工具包中（ Microsoft.Toolkit.Mvvm库），它还实现INotifyPropertyChanged和INotifyPropertyChanging 😄

您可以在本期中查看相关代码以及与该库相关的所有内容的回顾。
我还在那里包含了指向 MVVM 工具包的原始问题的链接，以及针对新开发人员的更多文档。

你能告诉我们这方面的最新情况吗？ 好奇 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 上可用，但这并不意味着它受它的支持。 文档不够清楚。