Custom data validation approach for store items and prices
You are close to a standard validation implementation of Entity Framework, which is using IValidatableObject. It may be worth the effort to replace your validation by this readily available validation framework.

The advantage of using IValidatableObject is that it works together with validations applied by data annotations or fluent mappings. If, for example, you have ...

[Required]
public string UPCCode { get; set; }


... or ...

modelBuilder.Entity&lt;Item&gt;().Property(i =&gt; i.UPCCode).IsRequired();


... EF will carry out the validation when SaveChanges is executed. If validation fails, a DbEntityValidationException is thrown that contains a property EntityValidationErrors showing the validation errors.

All this happens without even implementing IValidatableObject. If however you also implement this interface, you can add custom validations that blend seamlessly with the ones from data annotations/mappings. Here's how to do that, reducing it to the essentials:

public class Item : IValidatableObject
{
    public int ID { get; set; }
    [Required]
    public string StoreCode { get; set; }

    public IEnumerable&lt;ValidationResult&gt; Validate(ValidationContext validationContext)
    {
        var context = (DbContext)validationContext.Items["Context"];
        var item = (Item)validationContext.ObjectInstance;
        if (context.Set&lt;Item&gt;().Any(c =&gt; c.StoreCode == item.StoreCode &amp;&amp; c.ID != item.ID))
        {
            var error = string.Format("StoreCode '{0}' exists", item.StoreCode);
            yield return new ValidationResult(error, new[] { "StoreCode" });
        }
        yield return ValidationResult.Success;
    }
}


Now if this validation is violated, it will also throw a DbEntityValidationException with the custom message in EntityValidationErrors.

Notice that the context responsible for saving the item is wrapped in the validationContext. This is not so by default. You must override the context's DbEntityValidationResult method to add the context to validationContext.Items:

protected override DbEntityValidationResult ValidateEntity(DbEntityEntry entityEntry, IDictionary&lt;object, object&gt; items)
{
    items.Add("Context", this);
    return base.ValidateEntity(entityEntry, items);
}


You may have noticed another big advantage, compared to your approach: the Validate method returns meaningful information rather than just a boolean. I'm not even sure how you would supply feedback from your Validate method.

As you see, this is close enough to consider refactoring your own architecture, but also different enough to make this more than a trivial operation. It's more at the ground level, while your validation is in an abstraction layer.

Another difference is that the EF validation is holistic: it validates an entire object graph, while your validation validates individual entities. Both have their pros and cons. With EF's validation it's harder to get validation errors for one specific entity, with your validation it's hard to validate a mixed collection of objects.