Suppose I have 2 classes, Collateral and CollateralStatus. Each collateral has a collateral Status, so I can say:

Collateral.CollateralStatus = [some Collateral Status Instance] --or-- Collateral.CollateralStatusID = 10;

I can validate this: Collateral.CollateralStatusID = 10; using the validation logic framework

I can't validate this: Collateral.CollateralStatus = [some Collateral Status Instance] because the validators work on field indices, and even though the field index must be kept in sync, the validation for CollateralStatusID is never fired when a CollateralStatus is set.

What I need is a way to intercept a set call to Collateral.CollateralStatus, do some validation processing, and either allow, or cancel the set operation.

Is explicitly validate the entity an option?

In v2.0, a validator always gets the entity to work on passed in, so you can test whatever you want, including related entities etc.

Hey guys, I understand that the validator has I need, but ValidateFieldValue is never fired, nor is ValidateEntity, when you set a related entity, only when you set it by ID.

This triggers all the validation I could possibly want: Collateral.CollateralStatusID = 10

This doesn't: Collateral.CollateralStatus = new CollateralStatus(10);

I think I can get what I need by piecing together PreProcessValue and OnRelatedEntitySet, (use the PreProcessValue to get the current value, and OnRelatedEntitySet to get the new one), I was just hoping I was missing a more straightforward strategy.

A validator works on the entity it's assigned to, and only on the field data, not on related entities.

jeffdeville wrote:

This triggers all the validation I could possibly want: Collateral.CollateralStatusID = 10
This doesn't: Collateral.CollateralStatus = new CollateralStatus(10);

Hi,

how would I please implement a check via the validator when this is called: Collateral.CollateralStatus = new CollateralStatus(10) As I need to reject certain related entities from being set.

Thanks, Patrick

You could do that on the _ValidateEntityBeforeSave _method override.

P.S. Next time please don't open old threads (ref).

daelmo wrote:

You could do that on the _ValidateEntityBeforeSave _method override.

This doesn't allow me to do it in the moment the code / user is trying to add the wrong related entity but only during the save operation.

daelmo wrote:

P.S. Next time please don't open old threads

ok

Thanks, Patrick

Validators work solely for the entities they're located in, and related entities aren't owned by the entities referencing them (e.g. Customer doesn't own its Order entities, so by design it's not Customer's validator's job to validate Orders added. )

You can build this in yourself pretty easily. Every entity has two methods you can override OnRelatedEntitySet and OnRelatedEntityUnset. In your entity, override these in a partial class and for example call your custom method in your validator in the entity the methods are overriden to do further validation.

Otis wrote:

Validators work solely for the entities they're located in, and related entities aren't owned by the entities referencing them (e.g. Customer doesn't own its Order entities, so by design it's not Customer's validator's job to validate Orders added. )

I agree it's not the customer's validators job to validate if an order is correct but I would say that it's the customer's validators job to verify if this particular order is allowed to be added to this customer. Imagine there is inheritance and we have: Order > VipOrder Order > TopSecretOrder

Why shouldn't the customer validator be able to throw an exception if a TopSecretOrder is added to an ordinary customer?

Or think of it the other way around. A customer has a flag "customer status" related to another lookup table.

Customer.StatusTypeID = 5; I can check it Customer.StatusType = PriorityStatusTypeEnity; I can't check it

Which is inconsistent. So I would think it would be helpful if the solution you suggested would be part of the overall framework. People don't have to use it but it's good if the option is there.

Thanks for considering it, Patrick

pat wrote:

Otis wrote:

Validators work solely for the entities they're located in, and related entities aren't owned by the entities referencing them (e.g. Customer doesn't own its Order entities, so by design it's not Customer's validator's job to validate Orders added. )

I agree it's not the customer's validators job to validate if an order is correct but I would say that it's the customer's validators job to verify if this particular order is allowed to be added to this customer.

That's subjective, for example I don't think it's the customer's validator's job to validate that. The main reason is: if you associate an order to a customer, you also associate a customer to an order, so you could also argue that the ORDER validator should validate the assignment. As a matter of fact, it's more of a direct assignment than the order addition to the Orders collection of the customer.

That's why there are the methods to override so you can tap into these events and do whatever you like, e.g. call into the validator if you want to. It's not build in for the reason above.