-
Notifications
You must be signed in to change notification settings - Fork 96
Configuration options
There are two main parts of the GenericServicesConfig
class. They are a) validation b) name matching.
NOTE: By validation I mean using the Validator.TryValidateObject
method on every entity being written
to the database.
By default GenericServices does NOT validate data written to the database - it assumes that the front-end
has validated the data. But it can be useful to turn on validation, especially if you are using the SaveChangesExceptionHandler
fuction - (see below).
You have two ways to turn on validation when GenericServices calls SaveChanges
- globally via the GenericServicesConfig
class at startup (see below), or individually using the PerDtoConfig<TDto, TEntity
.
If set to true then any Create/Update/Delete that is given an entity classes will validate that entity class on save. It will also call the SaveChangesExceptionHandler
(see below) if an exception occurs. This is the ONLY way to turn on validation for direct-access writes
If set to true then any Create/Update/Delete calls with DTOs will include a validation of the data on save. It will also call the SaveChangesExceptionHandler
(see below) if an exception occurs. You can use PerDtoConfig<TDto, TEntity
to only set validation for a single DTO/entity. The PerDtoConfig
setting takes precedence, and can force validation on or off.
If you set this property to a method it will be called if there is an exception when SaveChanges/Async
are called within the SaveChangedWithValidation
(and Async) method. You method should either
- Return a IStatusGeneric if it handled the exception (either by returning a error message or a
status message if it successfully handled a
DbUpdateConcurrencyException
. - null if it didn't recognise the error and couldn't handle it. In that case the code will rethrow the exception and it will bubble up to the top.