New Features
Added an assertion api to the PropertyValidator so that the Properties<T> api can be extended by clients.
The order of operations for the Properties api is as follows: If(), Required(), Assertions().
As an example, customized support for boolean properties was added to the library using the following code:
public static class BooleanPropertyExtensions { public static PropertyValidator<TContext, bool> IsTrue<TContext>(this PropertyValidator<TContext, bool> self) { self.Assert((t, p) => p); return self; } public static PropertyValidator<TContext, bool> IsFalse<TContext>(this PropertyValidator<TContext, bool> self) { self.Assert((t, p) => !p); return self; } public static PropertyValidator<TContext, bool?> IsTrue<TContext>(this PropertyValidator<TContext, bool?> self) { self.Assert((t, p) => p.GetValueOrDefault()); return self; } public static PropertyValidator<TContext, bool?> IsFalse<TContext>(this PropertyValidator<TContext, bool?> self) { self.Assert((t, p) => p.HasValue && !p.Value); return self; } }
Breaking Changes
RangePropertyValidator has been removed. It’s functionality is still available, but it has been entirely replaced by extension methods that use the new Assert() method on the PropertyValidator.
ValidationResultTypes have been completely removed. Then intent for ValidationResult.Type is that it is custom per project.
Silverlight 4
The entire Simple.Validation library has been compiled for Silverlight and included in the NuGet package.
Conditional Property Validators
An If() method has been applied to the following property validators:
- EnumerablePropertyValidator
- RangePropertyValidator
- ReferencePropertyValidator
- StringPropertyValidator
When If() is called with the required Predicate, the validator will only apply when the condition specified by the Predicate is met.
[Test] public void If_PredicateIsFalse_ShouldNotValidate() { // Arrange var validator = Properties<Employee> .For(e => e.Age) .GreaterThanOrEqualTo(18) .If(e => e.Age != -1) ; // Act var employee = new Employee() { Age = -1 }; var results = validator.Validate(employee); // Assert Assert.That(results, Is.Empty); }
I’m trying to catalog View-ViewModel Binding Patterns so that I can compare their strengths and weaknesses. So far I can think of 2 basic ones. The names I gave them are made up. What are the others?
Name: View-Instantiation.
Description: The View directly instantiates the ViewModel and assigns it to the data context.
Sample:
<
Window.DataContext
>
<
ViewModels:MyViewModel
/>
</
Window.DataContext
>
Pros: Easy to set up and get going. Easy to add design-time data.
Cons: Requires default constructor on ViewModel. This makes Dependency Injection scenarios difficult.
Name: View Templates
Description: The View is chosen by a data template associated with the ViewModel type.
Pros: ViewModels fit easily into Dependency Injection scenarios.
Cons: Design-time data is more difficult to accommodate. Tooling cannot tell the type of the ViewModel associated to the View during View development.