涂料网站建设网站建设分录

张

张建站

2026/4/11 13:25:38

10分钟阅读

涂料网站建设,网站建设分录,做海外网站服务器放哪,唐山市城市建设档案馆网站C#中SetProperty的5个高级用法#xff1a;从基础到实战技巧全解析如果你在WPF、MAUI或者Avalonia这类框架里摸爬滚打过一阵子#xff0c;肯定对INotifyPropertyChanged接口又爱又恨。爱的是它让数据绑定变得如此丝滑#xff0c;恨的是每个属性后面都得跟着一堆样板代码 } // 原有的值比较逻辑 if (EqualityComparerT.Default.Equals(field, value)) return false; field value; OnPropertyChanged(propertyName); return true; }使用时验证逻辑变得非常清晰private int _age; public int Age { get _age; set SetProperty(ref _age, value, validate: v v 0 v 150); }注意验证失败时的处理策略需要根据业务决定。上述示例是静默失败你也可以选择抛出ArgumentException或者在validate委托中返回一个包含错误信息的元组让调用者能获取失败原因。1.2 变更前与变更后的回调基础的SetProperty有时会提供一个onChanged回调在值成功变更后执行。但有些业务需要在值即将改变时做一些事情比如清理旧值关联的资源或者记录变更前的状态用于撤销操作。我们可以引入一个onChanging回调。protected bool SetPropertyT( ref T field, T value, ActionT? onChanging null, // 变更前 ActionT? onChanged null, // 变更后 [CallerMemberName] string propertyName ) { if (EqualityComparerT.Default.Equals(field, value)) return false; // 触发“即将变更”回调 onChanging?.Invoke(field); // 传入旧值 T oldValue field; // 保存旧值供可能的后续使用 field value; OnPropertyChanged(propertyName); // 触发“已变更”回调 onChanged?.Invoke(value); // 传入新值 // 如果需要也可以提供一个同时包含新旧值的回调 // onChanged?.Invoke(oldValue, value); return true; }这个技巧在实现一些高级功能时非常有用例如自动保存在onChanged中启动一个防抖debounce计时器延迟几秒后保存到数据库。依赖属性计算当属性A改变时在onChanged中重新计算依赖于A的属性B和C的值。状态日志在onChanging中记录旧值在onChanged中记录新值形成一个完整的操作审计轨迹。2. 性能深潜当属性变更成为瓶颈时在UI频繁更新、数据量大的场景比如实时数据监控、金融交易看板属性变更通知可能成为性能瓶颈。SetProperty内置的等值比较已经避免了许多不必要的更新但我们还能做得更多。2.1 针对值类型的优化对于int,double,bool这类简单的值类型使用EqualityComparerT.Default.Equals会有一点微小的开销。对于性能极度敏感的场景我们可以为特定类型提供特化specialization版本。// 在ObservableObject基类中增加特化方法 protected bool SetProperty(ref int field, int value, [CallerMemberName] string propertyName ) { if (field value) return false; // 直接使用比较避免泛型开销 field value; OnPropertyChanged(propertyName); return true; } protected bool SetProperty(ref double field, double value, [CallerMemberName] string propertyName ) { // 对于double可能需要考虑浮点误差这里用简单比较示例 if (Math.Abs(field - value) 1e-9) return false; field value; OnPropertyChanged(propertyName); return true; }编译器会根据参数类型选择最匹配的重载版本。对于int这样的高频类型省去一次泛型比较器的查找和虚方法调用在循环中调用成千上万次时累积的收益是可观的。2.2 批量更新与通知抑制有时我们需要一次性更新多个关联属性。如果每个属性都单独触发PropertyChanged会导致UI被多次无效化和重绘造成闪烁或卡顿。我们需要一种“事务性”的更新机制。思路是引入一个“批量更新模式”。在开始批量更新前设置一个标志在此期间SetProperty只更新字段不触发事件。批量结束后再一次性触发所有被修改属性的通知。public class BatchObservableObject : ObservableObject { private bool _isBatching false; private HashSetstring _batchedProperties new HashSetstring(); public IDisposable BeginBatchUpdate() { _isBatching true; _batchedProperties.Clear(); // 返回一个Disposable对象方便使用using语句 return new BatchUpdateDisposer(this); } private void EndBatchUpdate() { _isBatching false; if (_batchedProperties.Count 0) { // 一次性通知所有被修改的属性 // 注意某些UI框架可能更偏好逐个通知需要测试 OnPropertyChanged(string.Empty); // 空字符串表示所有属性都变了 // 或者逐个通知 // foreach (var prop in _batchedProperties) // { // OnPropertyChanged(prop); // } _batchedProperties.Clear(); } } protected override bool SetPropertyT(ref T field, T value, [CallerMemberName] string propertyName ) { if (EqualityComparerT.Default.Equals(field, value)) return false; field value; if (_isBatching) { _batchedProperties.Add(propertyName); } else { OnPropertyChanged(propertyName); } return true; } private class BatchUpdateDisposer : IDisposable { private BatchObservableObject _parent; public BatchUpdateDisposer(BatchObservableObject parent) _parent parent; public void Dispose() _parent.EndBatchUpdate(); } }使用起来非常优雅public class MyViewModel : BatchObservableObject { private string _firstName; private string _lastName; public string FirstName { get _firstName; set SetProperty(ref _firstName, value); } public string LastName { get _lastName; set SetProperty(ref _lastName, value); } public void UpdateFullName(string first, string last) { using (BeginBatchUpdate()) { FirstName first; LastName last; } // 离开using块时自动触发一次通知 // UI只会更新一次而不是两次 } }提示OnPropertyChanged(string.Empty)会通知绑定引擎“所有属性都可能已更改”这对于一次性更新大量属性是高效的。但如果你只更新了少数几个属性且UI上只有特定控件绑定了它们逐个通知可能更精确。最佳实践需要结合具体UI框架和场景测试。3. 线程安全的属性变更MVVM模式通常与UI线程紧密耦合PropertyChanged事件的处理者通常是UI控件必须在创建它们的线程通常是UI线程上被调用。然而属性值的更新可能发生在后台线程比如从网络API获取数据、进行复杂计算时。不正确的跨线程更新会导致UI无响应甚至崩溃。3.1 自动派发到UI线程一个健壮的SetProperty应该能处理线程切换。我们可以利用SynchronizationContext或者特定框架的调度器如WPF的Dispatcher来实现。protected bool SetPropertyT( ref T field, T value, [CallerMemberName] string propertyName ) { return SetProperty(ref field, value, null, propertyName); } protected bool SetPropertyT( ref T field, T value, ActionT? onChanged, [CallerMemberName] string propertyName ) { if (EqualityComparerT.Default.Equals(field, value)) return false; // 检查是否需要在UI线程上执行更新 if (Application.Current?.Dispatcher ! null !Application.Current.Dispatcher.CheckAccess()) // WPF的检查方式 { // 如果当前不是UI线程则派发到UI线程执行 Application.Current.Dispatcher.Invoke(() { // 注意这里需要重新比较因为从派发到执行可能已经过了一段时间 if (!EqualityComparerT.Default.Equals(field, value)) { field value; onChanged?.Invoke(value); OnPropertyChanged(propertyName); } }); return true; // 假设派发了更新 } else { // 当前是UI线程直接执行 field value; onChanged?.Invoke(value); OnPropertyChanged(propertyName); return true; } }需要注意的陷阱性能频繁的Dispatcher.Invoke会带来开销。对于高速更新的数据流如传感器数据更好的模式可能是先在后台线程缓冲数据然后定时批量派发到UI线程更新。重新比较在派发的闭包内重新比较值至关重要因为从决定派发到实际执行原始字段field可能已经被其他逻辑修改。框架依赖上面的例子用了WPF的Dispatcher。在MAUI、Avalonia或Uno Platform中你需要使用对应的调度机制如MainThread.BeginInvokeOnMainThread。3.2 使用WeakReference避免内存泄漏在跨线程回调中如果SetProperty所在的ViewModel实例被持有可能导致无法被垃圾回收。更安全的做法是使用弱引用WeakReference。protected bool SetPropertyT( ref T field, T value, [CallerMemberName] string propertyName ) { if (EqualityComparerT.Default.Equals(field, value)) return false; var weakThis new WeakReferenceObservableObject(this); Action updateAction () { if (weakThis.TryGetTarget(out var target)) { // 再次获取当前实例的字段值进行比较需要通过反射或其他方式这里简化 // 实际实现更复杂此处仅为示意 if (!EqualityComparerT.Default.Equals(field, value)) { field value; target.OnPropertyChanged(propertyName); } } // 如果target已被回收则什么都不做 }; // ... 派发updateAction到UI线程 ... return true; }这种模式在涉及长时间运行的后台任务时特别有用确保了即使ViewModel不再需要后台线程也不会阻止其被释放。4. 高级模式依赖属性、计算属性与验证集成SetProperty不仅可以用于简单的后台字段还可以作为构建更复杂属性系统的基石。4.1 实现依赖属性系统类似于WPF的DependencyProperty我们可以创建一个轻量级的依赖属性系统让属性的值由其他属性计算而来并在依赖项改变时自动更新。首先定义一个依赖关系管理器public class DependencyTracker { private Dictionarystring, Liststring _dependencies new Dictionarystring, Liststring(); public void AddDependency(string targetProperty, string sourceProperty) { if (!_dependencies.ContainsKey(sourceProperty)) _dependencies[sourceProperty] new Liststring(); if (!_dependencies[sourceProperty].Contains(targetProperty)) _dependencies[sourceProperty].Add(targetProperty); } public IEnumerablestring GetDependents(string sourceProperty) { if (_dependencies.TryGetValue(sourceProperty, out var dependents)) return dependents; return Enumerable.Emptystring(); } }然后在增强的SetProperty中在触发通知后检查并更新依赖于此属性的其他属性public class AdvancedViewModel : ObservableObject { private DependencyTracker _tracker new DependencyTracker(); private string _firstName; private string _lastName; public string FirstName { get _firstName; set { if (SetProperty(ref _firstName, value)) { // 如果FirstName变了通知依赖它的FullName OnPropertyChanged(nameof(FullName)); } } } public string LastName { get _lastName; set { if (SetProperty(ref _lastName, value)) { OnPropertyChanged(nameof(FullName)); } } } // 计算属性 public string FullName ${FirstName} {LastName}; }更自动化的方式是将依赖关系注册到_tracker然后在OnPropertyChanged被调用时自动查找并触发所有依赖属性的通知。这需要更复杂的基础设施但能极大减少样板代码。4.2 与数据验证如INotifyDataErrorInfo的集成在业务应用中属性变更常常伴随着数据验证。我们可以扩展SetProperty使其在更新值的同时触发验证逻辑并收集错误信息。假设我们实现了INotifyDataErrorInfo接口public class ValidatableViewModel : ObservableObject, INotifyDataErrorInfo { private Dictionarystring, Liststring _errors new Dictionarystring, Liststring(); public event EventHandlerDataErrorsChangedEventArgs? ErrorsChanged; protected bool SetPropertyT( ref T field, T value, FuncT, (bool IsValid, string? ErrorMessage)? validator null, [CallerMemberName] string propertyName ) { if (EqualityComparerT.Default.Equals(field, value)) return false; // 执行验证 string? error null; if (validator ! null) { var result validator(value); if (!result.IsValid) { error result.ErrorMessage; } } // 更新错误集合 if (string.IsNullOrEmpty(error)) { _errors.Remove(propertyName); } else { _errors[propertyName] new Liststring { error }; } // 触发错误变更通知 ErrorsChanged?.Invoke(this, new DataErrorsChangedEventArgs(propertyName)); // 更新字段并触发属性变更通知 field value; OnPropertyChanged(propertyName); return true; } // ... INotifyDataErrorInfo 接口的其他实现 ... }使用时验证逻辑被清晰地内联在属性定义中private string _email; public string Email { get _email; set SetProperty(ref _email, value, validator: v { if (string.IsNullOrEmpty(v)) return (false, 邮箱不能为空); if (!v.Contains()) return (false, 邮箱格式不正确); return (true, null); }); }这样UI层通过绑定不仅能接收到属性值变化通知还能自动接收到验证错误信息的变化并实时在界面上展示错误提示。5. 实战技巧在复杂项目中的应用模式理论说再多不如看看在实际项目中怎么用。下面分享几个我亲身经历过的、利用增强版SetProperty解决实际问题的模式。5.1 状态机与属性联动在一个工业控制软件中设备有Idle空闲、Running运行、Fault故障等多种状态。当状态改变时界面上数十个按钮的可用性、颜色都需要跟着变。如果每个按钮的IsEnabled都去监听State属性会非常混乱。我们的解决方案是创建一个StateAwareViewModel基类其中SetProperty在更新状态字段后自动触发一系列相关的“衍生属性”更新。public abstract class StateAwareViewModel : ObservableObject { private DeviceState _state; public DeviceState State { get _state; protected set // 设置器可能是protected因为状态变更由内部逻辑驱动 { if (SetProperty(ref _state, value)) { // 状态改变触发所有依赖于状态的属性更新 OnStateDependentPropertiesChanged(); } } } // 衍生属性 public bool CanStart State DeviceState.Idle; public bool CanStop State DeviceState.Running; public bool IsFaulted State DeviceState.Fault; public string StatusColor State switch { DeviceState.Idle Gray, DeviceState.Running Green, DeviceState.Fault Red, _ Black }; protected virtual void OnStateDependentPropertiesChanged() { // 手动通知所有衍生属性 OnPropertyChanged(nameof(CanStart)); OnPropertyChanged(nameof(CanStop)); OnPropertyChanged(nameof(IsFaulted)); OnPropertyChanged(nameof(StatusColor)); // ... 其他衍生属性 } // 也可以利用反射自动查找所有具有特定Attribute的只读属性来通知但手动列出更清晰、性能更好。 }这样所有业务逻辑只需关注State的改变UI的联动由基类自动处理代码耦合度大大降低。5.2 与响应式编程Reactive Extensions结合如果你在项目中使用ReactiveUI或自己集成了System.Reactive可以将SetProperty与IObservable流结合起来实现更声明式的编程。思路是将属性变更转换为可观察的事件流。我们可以创建一个WhenPropertyChanged方法public IObservableT WhenPropertyChangedT(ExpressionFuncT propertyExpression) { // 这是一个简化的示例实际实现需要考虑更多细节 var propertyName ((MemberExpression)propertyExpression.Body).Member.Name; return Observable.FromEventPatternPropertyChangedEventHandler, PropertyChangedEventArgs( h this.PropertyChanged h, h this.PropertyChanged - h) .Where(e e.EventArgs.PropertyName propertyName) .Select(_ propertyExpression.Compile().Invoke()) // 获取当前属性值 .DistinctUntilChanged(); // 可选只在值实际变化时发出 }然后在增强的SetProperty中我们不仅可以触发事件还可以将变更推送到一个Subject主题中供其他流订阅。这为构建复杂的、基于事件的数据处理管道打开了大门。例如你可以轻松实现属性值的去抖Throttle、采样Sample、或者与其他属性流进行组合CombineLatest。5.3 调试与诊断支持最后一个容易被忽视但极其有用的高级用法为SetProperty注入诊断逻辑。在开发复杂模块时追踪属性何时、为何改变是调试的利器。我们可以创建一个带调试支持的版本只在调试模式下生效protected bool SetPropertyT( ref T field, T value, [CallerMemberName] string propertyName , [CallerFilePath] string filePath , [CallerLineNumber] int lineNumber 0) { if (EqualityComparerT.Default.Equals(field, value)) return false; T oldValue field; field value; OnPropertyChanged(propertyName); #if DEBUG // 记录详细的变更信息 Debug.WriteLine($[PropertyChanged] {propertyName} changed at {filePath}:{lineNumber}); Debug.WriteLine($ Old: {oldValue}); Debug.WriteLine($ New: {value}); // 可以在这里输出调用堆栈帮助定位是谁修改了属性 // Debug.WriteLine(new System.Diagnostics.StackTrace().ToString()); #endif return true; }通过使用[CallerFilePath]和[CallerLineNumber]我们能自动捕获属性是在哪个文件的哪一行被修改的这在追踪那些“神秘”的属性变更来源时非常有效。你还可以将这些信息记录到日志文件或者与你的应用程序遥测系统集成用于生产环境的问题诊断。