Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

make defaultable values validatable #51

Open
dzmitry-lahoda opened this issue Jan 23, 2022 · 5 comments
Open

make defaultable values validatable #51

dzmitry-lahoda opened this issue Jan 23, 2022 · 5 comments

Comments

@dzmitry-lahoda
Copy link

https://docs.microsoft.com/en-us/dotnet/api/system.componentmodel.dataannotations.ivalidatableobject.validate .

@SteveDunn
Copy link
Owner

Hi @dzmitry-lahoda - visiting some old comments now that I've got a bit of time free. Do you mean to make the generated code IValidatableObject?

@dzmitry-lahoda
Copy link
Author

yes, so it will depend on componentmodel. and may be using validation attributes support on ctor parameters us enough. so that when error is raised it looks noce in xaml or api.

@SteveDunn
Copy link
Owner

SteveDunn commented Nov 1, 2024

Hi @dzmitry-lahoda , I'm taking a quick look at this one again.

may be using validation attributes support on ctor parameters

Vogen deliberately doesn't have constructors.

Do you expect it to look something like this:

[ValueObject<int>]
public partial class CustomerId : IValidatableObject
{
    public IEnumerable<ValidationResult> Validate(ValidationContext validationContext)
    {
        if(Value is < 1 or > 100)
            yield return new ValidationResult("Value must be between 1 and 100.", new[] { "Value" });
    }
}

With this, Vogen still won't know whether it's valid. So do you propose that when creating an instance, e.g:

var id = CustomerId.From(123);

That Vogen generates the code to call your Validate method and throws a ValueObjectValidationException containing the errors return from it?

... or, are you proposing that Validate(ValidationContext validationContext) is generated based on the results of your user provided Validate method, e.g.

[ValueObject<int>]
public partial class Whatever : IValidatableObject
{
    private static Validation Validate(int v)
    {
        if (v is < 1 or > 100) return Validation.Invalid("Value must be between 1 and 100");
        return Validation.Ok;
    }

   // THIS METHOD IS AUTO GENERATED BY VOGEN
    public IEnumerable<ValidationResult> Validate(ValidationContext validationContext)
    {
        Validation result = Validate(Value);
        
        if(result == Validation.Ok) yield break;
        
        yield return new ValidationResult(result.ErrorMessage);
    }
}

@dzmitry-lahoda
Copy link
Author

Yes.
As developer I expect that if I have strongly typed id, ans I have instance of type, it is valid up to its type(so instances do not violate type).
For example, each user may have up to 32 accounts. So account id can be u8 backed storage storing 5 bits of data. Neither deserialization nor instantiation via some well know method(constructor/new/from) should violate that.
In understant problems in csharp(not clr afaik) to allow structs without default constructor and activation via reflection so. In Rust these do exist and they market unsafe so.

Parse do not validate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants