Changed parameter inside Ensure/EnsureFor for nested objects

[GooRiOn]

Info

This Pull Request is related to issue no. #147

So, as we discussed in the issue, the IValitRulesProvider<TObject> parameter for validating nested object was replaced with IValitator<TObject> type. Code is now clearer and honestly makes more sense. For validation we provide object responsible for validation instead of rules provider. Imho, provider should be used to instantiate new IValitRules<TObject> like:

ValitRules<Model>
    .Create(_provider.GetRules())
....

But of course can be still transformed into valitator using CreateValitator() extension method (so the breaking change isn't that big).

Changes

• Replaced parameters inside Ensure and EnsureFor for nested objects to accepts IValitator<TObject> type instead
• Changed implmentation of NestedObjectValitRule and NestedObjectCollectionValitRule to accept IValitatot<TObject> in the constructor
• Changed unit tests

[codecov]

Codecov Report

Merging #151 into develop will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff           @@
##           develop   #151   +/-   ##
======================================
  Coverage      100%   100%           
======================================
  Files           39     39           
  Lines          763    763           
======================================
  Hits           763    763

Impacted Files	Coverage Δ
src/Valit/ValitRules.cs	100% <100%> (ø)	⬆️
src/Valit/Rules/NestedObjectValitRule.cs	100% <100%> (ø)	⬆️
src/Valit/Rules/NestedObjectCollectionValitRule.cs	100% <100%> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f7cac04...72da760. Read the comment docs.

[timdeschryver]

LGTM, totally agreeing with you!
Maybe we can go a step further?
What I mean by this is, we could remove the IValitRulesProvider (and making GetAllRules() private?), in favor of ValitRules if possible.

public IEnumerable<IValitRule<NestedModel>> GetRules()
                => ValitRules<NestedModel>
                        .Create()
                        .Ensure(m => m.NumericValue, _ => _
                            .IsGreaterThan(10)
                                .WithMessage("One"))
                        .Ensure(m => m.StringValue, _ => _
                            .Required()
                                .WithMessage("Two")
                            .Email()
                                .WithMessage("Three"))
                        .GetAllRules();

would become

public ValitRules<NestedModel> GetRules()
                => ValitRules<NestedModel>
                        .Create()
                        .Ensure(m => m.NumericValue, _ => _
                            .IsGreaterThan(10)
                                .WithMessage("One"))
                        .Ensure(m => m.StringValue, _ => _
                            .Required()
                                .WithMessage("Two")
                            .Email()
                                .WithMessage("Three"));

[GooRiOn]

@tdeschryver but how would you get the rules from IValitRules object having mentioned methods private?

[timdeschryver]

Oh did I say private? I meant internal 😅 , so we could access the GetRules() on validation.

[GooRiOn]

@tdeschryver but the idea behind provider was to have a structure responsible for providing ruleset. So, you can get them and create a new instance of IValitRules. Imagine situation when you have the following classes:

class A
{
     public string Value {get; set;}
}

class B : A
{
    public int ConcreteValue {get; set;}
}

With a provider you could create a rules just for the Value property for A type. Then somehere in you code, you could get these rules and create new instance of IValitRules<B> :

ValitRules<B>
    .Create(ATypeRules)
    .Ensure(m => m.ConcreteValue, ...)

So you follow DRY instead of typing same rules for the concrete type.

[GooRiOn]

Oh wait, I know what you mean now :D This may be a good decision since there would be no confusion what actually GetRules returns... IValitRules or enumerable of rule... But that's another breaking change :/

[timdeschryver]

@GooRiOn True, but we still can take advantage that we aren't in v1? 😄

[GooRiOn]

@tdeschryver I mentioned that in #145 ;)

[GooRiOn]

@tdeschryver I'll merge this and create new issue for IValitRulesProvider topic since I don't want to block this change ;)