DTO to Domain in WebAPI

[xavierjohn]

I was thinking about the gaps in this library when converting from DTO to Domain from a Web API point of view.
Usually, a model will have multiple parameters, and we should validate all of them and return numerous errors. When we call Create on several value objects, the errors are added to a collection. Maybe we can add a Validate chaining method.

var result = Validate(FirstName.Create(strFName))
.ContinueValidation(LastName.Create(strLName))
.ContinueValidation(EmailAddress.Create(strEmail))
if (result.IsFailure) return result.errors

I wonder if something like this will work
Validate(var firstName = FirstName.Create(strFName))
or if we have to use the out param like
Validate(FirstName.Create(strFName, out var firstName))

This errors collections should be in the default ASP.NET core format to work out of the box.

We could also add a few basic types like RequiredString & Email Address as part of the package. I find myself repeating RequiredString (string.IsNullOrWhiteSpace) in several projects.

[xavierjohn]

It gets more interesting when creation of a object depends on the previous object.

Result<Student, Errors>  CreateStudent(string strFName, string strLName, string strEmail) =>
Validate(FirstName.Create(strFName, out var firstName))
.ContinueValidation(LastName.Create(strLName, out var lastName))
.ContinueValidation(EmailAddress.Create(strEmail, , out var email))
.ContinueValidation(Student.Create(firstname, lastName, email, out var student)
.ToResult("Validation Failed")
.Bind( student => Repository.Store(student);

[vkhorikov]

I would rather not overcomplicate the library for the sake of being able to chain everything. In my experience, trying to do method chaining at all costs only complicates the code and diminishes readability (i.e even though the chain itself looks pretty, it becomes harder to read and reason about).

In your example with student creation, I would first create all the value objects, combine the results (and simultaneously gather all the errors), check the combined result and then create the student.

To your other point about multiple errors -- I agree, this probably should be supported by the library out-of-the-box, here are my thoughts on this: #239 (comment)

Finally, regarding RequiredString & EmailAddress, this brings the library into the territory of reusing domain logic, which is a huge red flag. Best to just copy those classes from project to project like you are doing now.