Hello,

We're using v2.6/Adapter.

When our WCF services create a new instance of an entity with information we receive from the Client, we need to store the field's original value, along with the updated (possibly) updated value for later business logic use before the entity is eventually saved to the DB.

We tried using the following to set the field's DBValue:

UserEntity userEntity = new UserEntity();
userEntity.Fields["UserLoginName"].ForcedCurrentValueWrite("UpdatedLogin", "OriginalLogin");

But we discovered that we also had to set the field's .IsChanged property so that the field would ultimately be saved to the DB.

Not only does this method feel kludgy; there's a warning in the documentation not to do this.

Is there a better way to do this, possibly modifying the templates?

Thanks,

William

Hi William,

The better way (besides the normal property assignation) to set the new value is

UserEntity userEntity = new UserEntity();
userEntity.SetNewFieldVale("UserLoginName", "UpdatedValue");

Now, as you want to force the original (DBValue) value, you have to do that similiar to your code. The thing is that is not natural to force the DBValue (you are not fetching it), that's why you feel this method kludgy, because it's indeed not a good practice.

If possible, you could pass the serialized entity or DTO's trough your WFC endpoints.

Unfortunately we're not allowed access to the DTO's at the point where the business rules need to check the original and updated value.

I like your words, that forcing the DBValue 'is not natural', but I don't know of a better way.

Is it kosher to add a property to the field's base class that we could use to store the original value as it's passed around?

Wm

The warning not to do that is there to discourage people to go that route to set entity field values in normal code.

I don't consider migration code from one object paradigm (DTO) to another (Entity/business objects) every day code: it's special code to get a given specialistic task done.

If you keep the DBValue around in your DTO as well, you have to fill the entity as if it was read from the DB, and then set the values. You can make this easier, by doing this: - create new entity instance - set entity.IsNew to false - use field.ForcedCurrentValueWrite(DBValue, DBValue); This will make the entity look like as if it's fetched from the db. - use entity.SetNewFieldValue(fieldName, newCurrentvalue);

this will make a field which changed indeed be marked changed and an entity dirty. If not, nothing will change. So you don't have to check whether DBValue or CurrentValue are different to set IsChanged, that's been taken care of.

I think this will solve your concern. Indeed it is a bit low-level to go this route, but as you want to re-build an entity instance in memory without going to the db, you actually have to, the only code which does the same thing is the fetch logic which fetches data from the db

It's good to know we were on the right track and that this is a 'sanctioned' way of doing things.

Thanks!