Good Morning,

The following is taken from the user manual:

You've three options:

1) Setting the Validator property of an entity object manually. This is straight forward, but error prone: if you forget to set a validator, validation using this validator object isn't performed. Also, entities fetched in bulk into a collection are created using the factories so you have to alter these as well. You could opt for overriding OnInitializing in an entity to add the creation of the Validator class.

2) By overriding the Entity method CreateValidator. This is a protected virtual (Protected Overridable) method which by default returns null / Nothing. You can override this method in a partial class or user code region of the Entity class to create the Validator to use for the entity. The LLBLGen Pro runtime framework will take care of calling the method. One way to create an override for most entities is by using a template. Please see the LLBLGen Pro SDK documentation for details about how to write templates to generate additional code into entities and in separate files. Also please see Adding Adding your own code to the generated classes for details.

3) Dependency Injection ...

I was just wondering what differernce there is between the two: overriding OnInitialization or overriding CreateValidator?

The other question I have is I fetch a lot of my entities in collections with

Adapter.FetchEntityCollection

Which of the two would be better suited for this and set the validator even if an entity is created using a factory?

Thanks,

Mike

I don't think there is a difference between both of them. I recommend using the CreateValidator() approach, since this is only called to create the Validator object.

Both of the approaches will work with entityCollections and Factories.

Thanks again for your quick help - much appreciated!

I've managed to get this working and the overridden "ValidateFieldValue" method is fired fine. However I am unsure how I can trap this error and display to the user?

I've set the "involvedEntity.SetEntityFieldError" and return false from the method. Unfortunately all that happens is that the new value gets rejected and replaced by the old one. How do I display to the user?

I am sure I am missing something here.

Sorry I think I just found the answer in another forum post. But just to confirm (in this example the error should be raised straight after setting the field incorrectly):

In the Validator Method I throw an ORMEntityValidationException straight away:

public override bool ValidateFieldValue(IEntityCore involvedEntity, int fieldIndex, object value)
        {
            // Value to return
            bool fieldIsValid = true;

            if (value != null)
            {
                // Inspect filedIndex to determine if they are in the correct format
                switch ((MissionFieldIndex)fieldIndex)
                {
                    case MissionFieldIndex.BaseId:
                        if ((int)value <= 6)
                        {
                            involvedEntity.SetEntityFieldError(MissionFieldIndex.BaseId.ToString(), "Must be greater than 6!", false);
                            fieldIsValid = false;
                            throw new ORMEntityValidationException("Test",involvedEntity);
                        }
                        break;
                }
            }
            return fieldIsValid;
        }

In the UI I catch the error:

            try
            {
                mission.BaseId = 2;
            }
            catch (ORMEntityValidationException eve)
            {
                IDataErrorInfo dataError = (IDataErrorInfo)eve.EntityValidated;
                MessageBox.Show(dataError["BaseId"].ToString());
            }

Does this seem right?

Maybe I should do the thinking BEFORE the posting. Anyway to put this into a more practical context:

Even though the above sample code works I now realize that there is no need to throw an exception as this logic can be handled in one of the GUI controls events (e.g. before the control has lost focus but after the validation has taken place). I guess this is the way to go?

Field & Entity Validations should be used to prevent improper values inside an entity. This should be used as a base or one of the last lines of defense.

The problem comes when people try to use it to solve GUI issues, speaking about this any form (web or windows), should have its own input validations.

Which in most cases might be a redundant work, but it's inevitable IMHO. So when I build a web form, I put a validator control to check that Fright is greated than Zero, and another one to check that the OrderDate is before the ShipDate, otherwise the page is not validated and a post back will be stopped. This is most helpful in databinding situations. I don't like to start the back path of a 2-way databinding if the inputs are invalid.

So why using Field Validations & Entity Validations in the first place if it would be taken care of in the GUI ? Ans: Since an entity can be updated in code.

IMHO Validations should exist in all layers (DAL, BL, and PL).

Base line: You can use FieldValidation to prevent wrong data (according to the requirements) being set in a filed.

Always use UI input validations.

Also if you want, instead of validating each field's set action you can use the ValidateEntityBeforeSave to validate the entire entity before the save action, this way you can return error messages to the user where the wrong data is being kept in the fields. (nothing prevented them from being set inside the fields, but they won't be persisted).

Also, there's a validation example in the v2.5 download section of the LLBLGen webpage that uses the three approaches and various some suggestions for populate the error to the GUI