What we have done in the past - and this might be incorrect usage of the validator classes - is using the ValidateEntityBeforeSave and ValidateEntityBeforeDelete to apply certain logic when an entity is saved or deleted. In this way, we know for sure that this logic is executed for each entity using the dependency injection mechanism, as we've set the dependency injection for types of IEntity2 (see code below)
[DependencyInjectionInfo(typeof(IEntity2), "Validator", ContextType = DependencyInjectionContextType.Singleton)]
public class GeneralValidator : ValidatorBase
{
public override void ValidateEntityBeforeSave(IEntityCore involvedEntity)
{
base.ValidateEntityBeforeSave(involvedEntity);
}
public override void ValidateEntityBeforeDelete(IEntityCore involvedEntity)
{
IEntity2 useableEntity = involvedEntity as IEntity2;
if (useableEntity != null)
{
using (DataAccessAdapter adapter = new DataAccessAdapter())
{
// Fetching other entities and doing other stuff
}
}
base.ValidateEntityBeforeDelete(involvedEntity);
}
}
In this case, we have implemented a mechanism to apply referential constraints which is executed on each entity delete using the validator code above. This might be a complete misusage of the validator classes but this has always worked for us when working with Self Servicing as we didnt had the DataAccessAdapter instances then. When we switched to adapter we did get these DataAccessAdapter instances and therefore I was wondering whether it was possible to reuse them.
Especially in this case where it felt a bit unneccessary to open different DataAccessAdapter instances in a nested way in the validator class. I was hoping for a property on the entity with a reference to the DataAccessAdapter, but couldn't find any.
So what you're saying is just keep on opening these DataAccessAdapter instances, apart from the fact tat we're incorrectly using the validators?
And what would be the better place to call this referential constraint logic from?
Thanks again.