In ASP.NET the following is used for handling Validation, how would the same be done using LLBLGenPro ? Taken from the article http://nerddinnerbook.s3.amazonaws.com/Part5.htm

// 03.// POST: /Dinners/Edit/2 04. 05.[AcceptVerbs(HttpVerbs.Post)] 06.public ActionResult Edit(int id, FormCollection formValues) { 07. 08. Dinner dinner = dinnerRepository.GetDinner(id); 09. 10. try { 11. 12. UpdateModel(dinner); 13. 14. dinnerRepository.Save(); 15. 16. return RedirectToAction("Details", new { id=dinner.DinnerID }); 17. } 18. catch { 19. 20. foreach (var issue in dinner.GetRuleViolations()) { 21. ModelState.AddModelError(issue.PropertyName, issue.ErrorMessage); 22. } 23. 24. return View(dinner); 25. } 26.}

public IEnumerable<RuleViolation> GetRuleViolations() is a method implemented in the project you mention. You easily could use IDataErrorInfo if you want, or you can use those RuleViolation classes. Please take a look at the Validation Example at download section of LLBLGen site.

daelmo wrote:

public IEnumerable<RuleViolation> GetRuleViolations() is a method implemented in the project you mention. You easily could use IDataErrorInfo if you want, or you can use those RuleViolation classes. Please take a look at the Validation Example at download section of LLBLGen site.

I am not sure how I'd use "those RuleViolation" classes. Now I did read about LLBL's Validation classes, and a reference to the IDataErrorInfo as well. I'll take a boo at the Validation Example shortly, but I am curious how one would maintain using the same RuleViolation as built into ASP.NET for a different model...

Thanks for the help! Quentin

Another semi-related question:

In LLBL help it talks about Validation via DependencyInjection, how does this compare to the Dynamic data approach?

See http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=14078&HighLight=1

And how do I take advanage of the Dynamic Data approach for validation? in my above example, as I shouldn't need to create Validation classes or use IDataErrorInfo I believe.

For example the Dynamic Data approach is to use partial classes, with meta data such as:

    [Required(ErrorMessage = "Name is required.")]  
    [StringLength(20, ErrorMessage = "Name must be 20 characters or less.")]
    public object Name { get; set; }

Now this is great that in theory the view can use this to present the fields as required, etc. But with it, how would LLBL know of its existance and use it, and how will the validation routines see it as well in LLBL ?

_Personal opinion: if LLBL can fully leverage Dynamic data, then its a great benefit to LLBL as theoretically its less code they need to manage, and they get the benefits :-) Now this is assuming that Dynamic Data is the cats-ass. _

This was discussed here: http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=14305

It was mentioned there, but nothing technical was discussed. Nothing on the HOW to do it or references to any examples. Nothing on the pro's or con's either.

I did revive the thread though.

validation in dynamic data is done via 'buddy classes' with attributes. Validation in llblgen pro is done via validation objects.

Adding validation attributes at the moment is a bit of a pain. We've solved that in the upcoming v3.

I'm not sure what you're after, as in: what exactly do you want to achieve, that's not doable with the IValidator implementations used in llblgen pro?

One of the big benefits of using "Dynamic Data" is the generation and display benefits.

This is not possible from with the validation class concept and I don't see how IValidator is going to resolve this either.

Perhaps I should pose this as a question.

Using IValidator, I want to have my MVC project able to generate the view and show the required elements as can be done currently.

Constraints: * I do not want to have to do the validation twice, only once. * Should snap into existing technologies with minimal re-work.

Can you demonstrate how this could be achieved in 2.6 or in 3.0 ?

A smarter thing would be to use the already built in validation DI framework. If there is a validation exception, throw it from the dependency injected class. Make this a custom exception object that stores the errors for each of the fields (a la NerdDinner). On line 18 of your code, catch the custom exception and then loop through the fields in the custom exception object (lines 20-21) instead of doing it directly on the domain object. Let me know if this helps. I feel this approach is better than theirs as it clearly allows for a better separation of concerns.

Hi Seth,

I will try that out tonight.

Let us know how you get on.

Matt