Walidacja FluentValidation + Autofac

Mam w projekcie dotnet core 2.1 coś takiego w uproszczonej wersji:

public class CreateVehicle
{
	public string Brand { get; set; }
	public string Model { get; set; }
	...
}

public class CreateVehicleValidator : AbstractValidator<CreateVehicle>
{
	public CreateVehicleValidator()
	{
		RuleFor(vehicle => vehicle.Brand).NotNull();
		RuleFor(vehicle => vehicle.Model).NotNull();
		...
	}
}

1. Chcę zamiast domyślnego DI użyć Autofac'a. Czy wersja 1 działa dokładnie tak jak wersja 2? Jeśli tak to, która jest "lepsza" czy może jeszcze inaczej powinno się to zrobić?

public class ValidationsModule : Module
	{
		protected override void Load(ContainerBuilder builder)
		{
			// wersja 1
			builder.RegisterAssemblyTypes(ThisAssembly)
				.AsClosedTypesOf(typeof(IValidator<>))
				.AsImplementedInterfaces()
				.InstancePerLifetimeScope();

			// wersja 2
			builder.RegisterAssemblyTypes(ThisAssembly)
				.Where(t => t.Name.EndsWith("Validator"))
				.AsImplementedInterfaces()
				.InstancePerLifetimeScope();
		}
	}

1. Podobne pytanie do pierwszego czy jest różnica pomiędzy (Autofac)
   .Where(t => t.IsAssignableTo<IService>()) a .AssignableTo<IService>()

2. Szukałem w internecie jak połączyć Autofac'a z FluentValidator i w każdym przypadku było coś a'la ValidationFactory. Rejestrując typy jak wyżej wszystko działało czy jest sens pisać fabrykę do walidacji?

3. ApiController wygląda mniej więcej tak:

[HttpPost]
public async Task<IActionResult> Post([FromBody] CreateVehicle request)
{
        if (!ModelState.IsValid)
	        return BadRequest();
	
        await _vehicleService.CreateVehicle(request);
        return Created(...);
}

Czy w controllerze, może/powinno się sprawdzać ModelState czy lepiej przenieść to do serwisu? Tylko w serwisie jak uzyskać dostęp do ModelState?

1. CreateVehicle przechowuję w Core czy CreateVehicleValidator też powinien być w Core czy może przenieść do Infrastructure, żeby nie dodawać zależności od FluentValidator do Core?

2. Już ściśle nie związane z tematem mam Controller i ApiController i chcę w zależności od klienta żeby serwis zwrócił albo ViewModel - RazorView albo Dto - Api. Jest jakiś dobry sposób, żeby to zaimplementować bo mapowanie w Controllerze jest chyba złe i powoduje wyciek z domeny. Jakiś pośredni serwis generyczny który w zależności od klienta będzie mappował wynik na odpowiedni typ?

Dlaczego chcesz rejestrować FluentValidation w Autofacu, zamiast bezpośrednio zarejestrować go w pipeline jako usługę, która automatycznie przeskanuje twoje assembly pod kątem występujących w nim validatorów?

            mvcCoreBuilder.AddFluentValidation(fv =>
                fv.RegisterValidatorsFromAssemblyContaining<Startup>());

Dodatkowo nie musisz sprawdzać w kontrolerze czy !ModelState.IsValid, bo FV powinien to robić za ciebie bo framework zrobi to za Ciebie jeśli dodasz atrybut [ApiController]

Dodatkowo nie musisz sprawdzać w kontrolerze czy !ModelState.IsValid, bo FV powinien to robić za ciebie.

No a jak inaczej sprawdzić czy podaliśmy prawidłowe dane ? Bo sumie to jestem ciekawy , też korzystam z FV

https://docs.microsoft.com/pl-pl/aspnet/core/web-api/?view=aspnetcore-2.1#annotate-class-with-apicontrollerattribute
OK. Moja poprzednia odpowiedź wymaga doprecyzowania, atrybut [ApiController] powoduje, że błędy z kodem 400 są handlowane automatycznie.

Tylko jak zwrócić komunikaty co jest nie tak ? Własny Atrybut dziedziczący po Apicontroller ?

W celeu przetestowania o czym piszecie zrobiłem na szybko nowy projekt.

Startup.cs

services.AddMvc().AddFluentValidation(o => o.RegisterValidatorsFromAssemblyContaining<CreateUserValidator>());

UsersController.cs

[Route("api/[controller]")]
[ApiController]
public class UsersController : ControllerBase
{
	private readonly UserService _userService;
	public UsersController(UserService userService)
	{
		_userService = userService;
	}
	
	[HttpPost]
	public async Task<IActionResult> Post([FromBody] CreateUser request)
	{
		await _userService.CreateUser(request);
		return Created($"api/users/{request.Email}", null);
	}
}

CreateUserValidator.cs

public class CreateUserValidator : AbstractValidator<CreateUser>
{
	public CreateUserValidator()
	{
		RuleFor(user => user.Email).NotNull().EmailAddress();
	}
}

Wysłałem dwa requesty za pomocą postmana z poniższymi danymi

{
    "email": null
}
{
    "email": test%email.com
}

W odpowiedzi statusCode 400 Bad Request a w body

{
    "Email": [
        "Pole 'Email' nie może być puste."
    ]
}
{
    "Email": [
        "Pole 'Email' nie zawiera poprawnego adresu email."
    ]
}

Wszystko działa bez sprawdzania za każdym razem ModelState.IsValid.
Dzięki @Młodszy Programista

Aenyatia napisał(a):

1. Chcę zamiast domyślnego DI użyć Autofac'a. Czy wersja 1 działa dokładnie tak jak wersja 2? Jeśli tak to, która jest "lepsza" czy może jeszcze inaczej powinno się to zrobić?

Druga zawiera magiczny string, pierwsza nie. Wybór jest prosty.

1. Podobne pytanie do pierwszego czy jest różnica pomiędzy (Autofac)
   .Where(t => t.IsAssignableTo<IService>()) a .AssignableTo<IService>()

Pierwsze to rozserzenie dla Type, drugie dla IRegistrationBuilder, to jakby pytać czy jest różnica między pralką a lodówką.

1. Szukałem w internecie jak połączyć Autofac'a z FluentValidator i w każdym przypadku było coś a'la ValidationFactory. Rejestrując typy jak wyżej wszystko działało czy jest sens pisać fabrykę do walidacji?

ValidationFactory w ogóle nie jest związana z jakimś DI, tylko z tworzeniem walidatorów dla określonych typów w sposób nieobsługiwany przez twórców FluentValidation. Dodaj sobie parametryzowany konstruktor do walidatora, i zobacz jak to wszystko pięknie przestaje działać. ;)

1. Czy w controllerze, może/powinno się sprawdzać ModelState czy lepiej przenieść to do serwisu? Tylko w serwisie jak uzyskać dostęp do ModelState?

Ja bym to zrobił w jakimś swoim ActionFilter, aby uniknąć duplikacji (sprawdzania IsValid) w każdym kontrolerze.
Możesz też mieć walidację uruchamianą na poziomie serwisów, wtedy cała integracja Fluent z warstwą webową jest Ci niepotrzebna. To ogólnie duża architektoniczna decyzja i trzeba się bardzo dobrze zastanowić.

1. CreateVehicle przechowuję w Core czy CreateVehicleValidator też powinien być w Core czy może przenieść do Infrastructure, żeby nie dodawać zależności od FluentValidator do Core?

No ja np. walidatory mam najczęściej w warstwie biznesowej.

1. Już ściśle nie związane z tematem mam Controller i ApiController i chcę w zależności od klienta żeby serwis zwrócił albo ViewModel - RazorView albo Dto - Api. Jest jakiś dobry sposób, żeby to zaimplementować bo mapowanie w Controllerze jest chyba złe i powoduje wyciek z domeny. Jakiś pośredni serwis generyczny który w zależności od klienta będzie mappował wynik na odpowiedni typ?

Ogólnie to brzmi jak zadanie dla warstwy webowej, więc pewnie znowu jakiś filtr albo handler jest potrzebny. Ale nie rozumiem o co chodzi, co rozumiesz przez "zależność od klienta"?

Dziękuję @somekind za wyjaśnienie.

1. Już ściśle nie związane z tematem mam Controller i ApiController i chcę w zależności od klienta żeby serwis zwrócił albo ViewModel - RazorView albo Dto - Api. Jest jakiś dobry sposób, żeby to zaimplementować bo mapowanie w Controllerze jest chyba złe i powoduje wyciek z domeny. Jakiś pośredni serwis generyczny który w zależności od klienta będzie mappował wynik na odpowiedni typ?

Ogólnie to brzmi jak zadanie dla warstwy webowej, więc pewnie znowu jakiś filtr albo handler jest potrzebny. Ale nie rozumiem o co chodzi, co rozumiesz przez "zależność od klienta"?

Chodziło mi o to, że jeśli piszę własny projekt to robię na szybko np. korzystając z RazorView i przekazuje mu ViewModel, ktoś z zewnątrz będzie pisał aplikację na telefon do mojego projektu, więc powinienem mu udostępnić API. Przez klienta rozumiem z czego pochodzi request: przeglądarka, mobile app, itp.

Chcę, żeby serwis dla zwykłego kontrolera zwrócił ViewModel a jeśli zostanie on wywołany przez API kontroler to Dto. Najłatwiejsza sposób jaki widzę to zwrócić do kontrolera obiekt domenowy i go mapować ale chyba nie tędy droga.

Serwis powinien wystawiać operacje tak, żebyś mógł ich użyć nawet z aplikacji konsolowej, czyli niech operują na jakichś DTO. API kontroler może bezpośrednio przekazać takie DTO, a kontroler MVC niech je sobie dodatkowo przetworzy w ViewModel.