This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hi all, I'm running into a strange problem with encrypting/decrypting data. We have an organisation, each organisation can have multiple invoices. I have the following methods on my Organisation.
// <summary>
This works great, but I'm having the following problem with cascading saves. I have 1 organisation with 2 invoices pointing to it. After adding the 2 invoices, I call Repository.Save(). Here is what I see happening in my code.
thanks, Todd |
|
|
When an object such as an invoice is validated, all its associated objects are validated too. It does sound like re-validating the organisation because we're about to save the invoice is a bit redundant; however, I think the problem you're seeing is better addressed through your underlying model rather than through changing our validation strategy. Basically the issue is that having encrypted data shouldn't make your entity invalid. Encryption is an aspect of storage, not an aspect of business validity. So what I'd suggest is that you have something like this in your Organisation class: private string _encryptedSecretData; // this is always the encrypted (storage) version public string SecretData // this surfaces the decrypted (usable) version Now if decryption is expensive, as it often is, you may not want to do this on every get. And if you want declarative validation of the plaintext version then you're out of luck because there's no field to apply the validation attribute to. So you may want to cache the decrypted version in a [Transient] field which you populate in AfterLoad and validate: private string _encryptedSecretData; protected override AfterLoad() { public string SecretData { (I'm assuming users don't change their SecretData many many times in the course of a single unit of work, so there's no significant overhead of encrypting every time the setter is called.) Now the validation markup accurately reflects that it's the plaintext data that has to be valid, while the storage markup reflects that it's the encrypted data that has to be persisted. I think this is a better approach than trying to modify the Organisation entity into an "invalid" state during the save pipeline; is it viable for you? |
|
|
Just an update. Here is my exact structure.
Org -1 - * > Invoice -1 * - > SpiderSummary -1-* -> TrackLineItem
Here is what is happening.
|
|