Ok, that is how we are doing it. If the related keys are not valid do you typically throw a BusinessException or a AbpValidationException? We originally implemented custom BusinessException classes but are thinking of swapping to an AbpValidationException for consistency with the other errors.
Thank you. I have one more follow-up related to this. In our Domain Managers we confirm that key references to other entities are valid. In some cases these are loose relationships to entities defined in other modules. For example, a Customer may have a SalesRepId. Currently we verify these are valid Ids in our domain manager CreateAsync and UpdateAsync using repositories for entities in the same module and app services for those in other modules and throw an exception if they are not. Is there a recommended approach to this?
We specifically used this method of implementation because the Validation documentation recommends not to add this type of validation on the Dto. https://docs.abp.io/en/abp/latest/Validation#resolving-a-service
Ok, I thought we might be overlooking a more automatic way to take care of it. If our fluent validation rules were also on the Dto and not just the domain object would the app service automatic validation also apply those rules? Is duplicating the rules from the domain in that way recommended so we don't have to explicitly call await _objectValidator.ValidateAsync(entity);?
Thank you for the confirmation. I made this change and it is working as expected now.
Thank you for the ideas. After making the post, I saw some documentation about ICurrentPrincipalAccessor.Change
https://docs.abp.io/en/abp/latest/CurrentUser#changing-the-current-principal
Could this also be used in my case and allow the entities to have a proper audit history of the user that created the entity?