We Keep Coding

Call method immediately after C# object has been initialised by Entity Framework Core

Summary
I have a class that should track whether a property's value has been changed by the user and remember its original value to allow resetting or committing it. Therefore, I wrote a class Historian<T> that serves as a wrapper and will be used in the business models of my application. However, when Entity Framework Core (EFC) gets my data from the database (DB), my approach results in indicating the value as edited and having stored an incorrect original value, i.e. default(T).
Details on the Question
This is the wrapper to remember the original and current value of a property:
public class Historian<T>
{
public T OriginalValue { get; private set; }
public T CurrentValue { get; set; }
public bool IsEdited => object.Equals(OriginalValue, CurrentValue); // avoids NullPointerExceptions
// some events ValueChanged, EditsDiscarded, EditsCommitted
public void CommitChanges()
=> OriginalValue = CurrentValue;
public void DiscardChanges()
=> CurrentValue = OriginalValue;
}
For illustrative purposes, let's stick with the classic library example. This is my Book class. The property Title should remember its original value from the DB accessed via EFC and allow resetting it internally or from other classes. The idea is that users will be shown the original value when editing text boxes in an application and allow resetting individual fields.
public class Book
{
private Historian<string> _Title = new Historian<string>();
public int BookID { get; set; }
public string Title
{
get => _Title.CurrentValue;
set => _Title.CurrentValue = value;
}
public string Description { get; set; }
public bool IsPopularBook { get; set; }
// other methods, properties, ..., this is an example
}
Now the problem is that when EFC gets the data from the database, it uses the default constructor, initialising Book.Title to string.Empty (setting both Historian.OriginalValue and Historian.CurrentValue) and then, after the constructor finished, sets Book.Title, to a value, let's say "Markdown -- a Pocket Guide". This, however, makes it seem to the application that the value was changed, even though it was not.
Is there a way to distinguish whether an object was constructed by EFC or by other parts of the application? Can I intercept the constructor called by EFC to initialise my Historian.OriginalValue correctly? Or can I tell EFC to call a method after the object has been initialised to set the Historian.OriginalValue, e.g. by calling Historian.CommitChanges() (though semantically wrong, I think you get the idea).
Non-Solutions -- (Failed) Attempts
Adding a constructor with parameters for the properties did work as EFC then calls this constructor, i.e.
public Book(string title)
{
Title = title;
_Title.CommitChanges();
}
However, as soon as there is a parameterless constructor (which I need in places in the application), EFC ignores the one with the parameters.
I tried changing the getter and setter of the property, which also did work. However, now I cannot easily subscribe to the events of Historian which was null before.
private Historian<string> _Title ;
public string Title
{
get
{
if (_Title == null)
_Title = new Historian<string>();
return _Title.CurrentValue;
}
set
{
if (_Title == null)
{
_Title = new Historian<string>();
_Title.CurrentValue = value;
_Title.CommitChanges();
}
else
_Title.CurrentValue = value;
}
}
Then, my idea was to have a fixed instance of Historian where I can subscribe to the events and add an initialisation mode to it, e.g. via a bool FirstSetterInitialises. But here, I cannot distinguish whether I'm initialising from EFC or somewhere else, so also new instances of Book will indicate they are not edited for the first edit, even though they are.

You could do this with Entity Framework change tracking. Consider the Historian class below that has been refactored to use Entity Framework change tracking. One caveat to this approach is that the Historians have to be instantiated with a reference to the EF context that created them, so this is an extra step that you would have to call from the layer above Entity Framework. One benefit of this approach is that it doesn't require any additional overhead to perform the change tracking - EF is already going to be doing the work anyways (unless you query with .AsNoTracking).
public class Role
{
public int Id { get; set; }
public string Name { get; set; }
public Historian<Role, string> NameHistorian;
/// <summary>
/// call this function after an EF context has returned this entity to build the historian
/// </summary>
/// <param name="context">the Entity Framework context that returned this entity</param>
public void ConfigureHistorians(DbContext context)
{
NameHistorian = new Historian<Role, string>(context, this, entity => entity.Name);
}
}
/// <summary>
/// a utility to view whether an property on a tracked entity has changed as well as the previous value
/// </summary>
/// <typeparam name="EntityType">the entity model class</typeparam>
/// <typeparam name="DataType">the type of the property to be tracked</typeparam>
public class Historian<EntityType, DataType> where EntityType : class where DataType : IEquatable<DataType>
{
private Microsoft.EntityFrameworkCore.ChangeTracking.PropertyEntry<EntityType, DataType> efEntry;
/// <summary>
/// create a historian for a specific property on a given entity
/// </summary>
/// <param name="context">the Entity Framework context from which the entity was retrieved</param>
/// <param name="entity">the instance of the entity this historian is tracking</param>
/// <param name="propertySelector">the property of the entity this historian is tracking</param>
public Historian(DbContext context, EntityType entity,
System.Linq.Expressions.Expression<Func<EntityType, DataType>> propertySelector)
{
efEntry = context.Entry<EntityType>(entity).Property<DataType>(propertySelector);
}
public DataType OriginalValue => efEntry.OriginalValue;
public DataType CurrentValue => efEntry.CurrentValue;
public bool IsEdited => !CurrentValue.Equals(OriginalValue);
public void DiscardChanges()
=> efEntry.CurrentValue = efEntry.OriginalValue;
}

Call DisplayFormatAttribute's Logic from C#

In My MVC5 application, I have this DisplayFormat attribute set on a property of my model. It ensures that my double value 'TotalPrice' is always rendered with two decimal places on the screen (in a Razor page)
[DisplayFormat(DataFormatString = "{0:N2}")]
public Double? TotalPrice { get; set; }
I'm trying to figure out how to call the same logic from within my Controller (C# code). So something like:
return DataFormatAttribute.ApplyFormattingTo(shoppingCart.TotalPrice);
That's obviously nowhere near correct but I hope it helps to clarify the question. I'm not really interested in the specific example of 2 decimal places, more how to apply an attribute's behaviour to a value by myself in C#.
I've downloaded the MVC5 source code, but it's all a bit too abstract for me to get my head around.
Thanks for any help you can give.

I'm not sure if its available OOB but it looks like you need to read the Attribute and apply your formatting. Write an extension method that will apply the formatting based on the DisplayFormatAttribute DataFormatString property.
I hope this sample gets you started, even if it's not an exact solution. This sample is tightly bound to DisplayFormatAttribute only
public static string ApplyFormattingTo(this object myObject, string propertyName)
{
var property = myObject.GetType().GetProperty(propertyName);
var attriCheck = property.GetCustomAttributes(typeof(DisplayFormatAttribute), false);
if(attriCheck.Any())
{
return string.Format(((DisplayFormatAttribute)attriCheck.First()).DataFormatString,property.GetValue(myObject, null));
}
return "";
}
Usage
Cart model= new Cart();
model.amount = 200.5099;
var formattedString = pp.ApplyFormattingTo("amount");
Actual implementation varies according to your requirement. Hope it helps.

#Searching provided the answer, so this is just my final code in case it helps others in the future. The CartExtension class provides extension methods for a class called Cart.
namespace MyApp.Models
{
public static class CartExtension
{
/// <summary>
/// Apply the formatting defined by the DisplayFormatAttribute on one of the Cart object's properties
/// programatically. Useful if the property is being rendered on screen, but not via the usual Html.DisplayFor
/// method (e.g. via Javascript or some other method)
/// </summary>
/// <param name="cart"></param>
/// <param name="propertyName"></param>
/// <returns></returns>
public static string ApplyFormattingTo(this Cart cart, string propertyName)
{
var property = cart.GetType().GetProperty(propertyName);
var attriCheck = property.GetCustomAttributes(typeof(DisplayFormatAttribute), false);
if (attriCheck.Any())
{
return string.Format(((DisplayFormatAttribute)attriCheck.First()).DataFormatString, property.GetValue(cart, null));
}
return "";
}
}
}
This can then be used to return the value preformatted for the screen e.g. in a Controller method:
return Json(cart.ApplyFormattingTo("TotalPrice"));

Automapper is not transferring my collection items

I am using AutoMapper 4.x.
I have a couple of classes as follows:
/// <summary>
/// All service outputs need to descend from this class.
/// </summary>
public class OzCpAppServiceOutputBase : IOzCpAppServiceOutputBase
{
private readonly OzCpResultErrors _OzCpResultErrors;
public OzCpAppServiceOutputBase()
{
_OzCpResultErrors = new OzCpResultErrors();
}
public OzCpResultErrors ResultErrors
{
get { return _OzCpResultErrors; }
}
public bool ResultSuccess
{
get { return _OzCpResultErrors.Messages.Count == 0; }
}
}
/// <summary>
/// Return from the booking service when a simple booking is made.
/// </summary>
public class OzCpSimpleManualCruiseBookingOutput : OzCpAppServiceOutputBase
{
public int OzBookingId { get; set; }
}
}
public class SimpleManualCruiseBookingOutput : OzCpSimpleManualCruiseBookingOutput
{
}
My issue comes in when I call AutoMapper to translate between OzCpSimpleManualCruiseBookingOutput and SimpleManualCruiseBookingOutput is that the ResultErrors is cleared.
public SimpleManualCruiseBookingOutput SimpleManualCruiseBooking(SimpleManualCruiseBookingInput aParams)
{
OzCpSimpleManualCruiseBookingOutput result = _PlatformBookingService.SimpleManualBooking(Mapper.Map<OzCpSimpleManualCruiseBookingInput>(aParams));
//**TESTING
result.ResultErrors.AddFatalError(1, "Oh Dear!!!!");
//**As soon as I perform the mapping the ResultErrros collection loses the item I have added above
return Mapper.Map<SimpleManualCruiseBookingOutput>(result);
}
I am guessing it is because it is a read only property, but I cannot figure out how to make it transfer the collection.
Any help greatly appreciated.
EDIT
I have also tried adding the items in the collection myself so changing my mapping from:
Mapper.CreateMap<OzCpSimpleManualCruiseBookingOutput, SimpleManualCruiseBookingOutput>();
to using the after map function as follows:
Mapper.CreateMap<OzCpSimpleManualCruiseBookingOutput, SimpleManualCruiseBookingOutput>()
.AfterMap((src, dst) => dst.ResultErrors.Messages.AddRange(src.ResultErrors.Messages));
but this then results in the destination having TWO items in the list instead of 1 viz:
which are both the same entry of "Oh Dear!!!!"
SOLUTION
Using the private setter approach suggested by DavidL (and an upgrade to Automapper 4.x) meant I got the required behaviour. So this is what I ended up with:
/// <summary>
/// Defines the contract for all output DTO's to platform
/// application services.
/// </summary>
/// <seealso cref="OzCpAppServiceOutputBase" />
public interface IOzCpAppServiceOutputBase : IOutputDto
{
/// <summary>
/// Contains a list of errors should a call to an application service fail.
/// </summary>
OzCpResultErrors ResultErrors{ get; }
/// <summary>
/// When TRUE the underlying call to the application service was successful, FALSE
/// otherwise. When FALSE see ResultErrors for more information on the error condition.
/// </summary>
bool ResultSuccess { get; }
}
public class OzCpAppServiceOutputBase : IOzCpAppServiceOutputBase
{
public OzCpAppServiceOutputBase()
{
ResultErrors = new OzCpResultErrors();
}
/// <remarks>The private setter is here so that AutoMapper works.</remarks>
public OzCpResultErrors ResultErrors { get; private set; }
public bool ResultSuccess
{
get { return ResultErrors.Messages.Count == 0; }
}
}
So while needing to add a private setter "just for" AutoMapper that is a small price to pay to have this work and not use complicated mappings to deal with the issue.

With the current inheritance structure, AutoMapper will NOT be able to do what you want it to do. Since your destination structure has the same properties as your source structure, the properties are also readonly. AutoMapper will not map to readonly properties that do not have a setter declared.
You have a few options:
Make the property setter explicitly private. This answer suggests that later versions of AutoMapper support this functionality. In this case it works for 4.x.
Make the property setter internal, so that only members of this assembly can set it. Since latest versions of AutoMapper will map to private setters, they should also map to internal setters.
Make the property settable.
Downcast the object instead of mapping (you've mentioned you don't want to do this because your object structures will eventually diverge).
Shadow the property on the destination object with a public setter. Ugly and a good source of strange bugs.
public class SimpleManualCruiseBookingOutput : OzCpSimpleManualCruiseBookingOutput
{
public new OzCpResultErrors ResultErrors { get; set; }
}
Create a helper that maps your read-only properties via reflection. DO NOT DO THIS!
PropertyInfo nameProperty = aParams.GetType().GetProperty ("ResultErrors");
FieldInfo nameField = nameProperty.GetBackingField ();
nameField.SetValue (person, aParams.ResultErrors);

Force XML serialization to serialize readonly property

In C#, I have a class which has a derived property that should be serialized via XML. However, XML serialization (by default) doesn't serialize read=only properties. I can work around this by defining an empty setter like so:
public virtual string IdString
{
get { return Id.ToString("000000"); }
set { /* required for xml serialization */ }
}
But is there a cleaner more semantically correct way, short of writing my own ISerializable implementation?

Honestly this doesn't seem too bad to me as long as it is documented
You should probably throw an exception if the setter is actually called:
/// <summary>
/// Blah blah blah.
/// </summary>
/// <exception cref="NotSupportedException">Any use of the setter for this property.</exception>
/// <remarks>
/// This property is read only and should not be set.
/// The setter is provided for XML serialisation.
/// </remarks>
public virtual string IdString
{
get
{
return Id.ToString("000000");
}
set
{
throw new NotSupportedException("Setting the IdString property is not supported");
}
}

In short, no. With XmlSerializer you can either implement IXmlSerializable (which is non-trivial), or write a basic DTO (that is fully read-write) and then translate from the DTO model to your main model.
Note that in some cases DataContractSerializer is a viable option, but it doesn't offer the same control over the XML. However, with DCS you can do:
[DataMember]
public int Id { get; private set; }

With C# 8, obsoleting set is allowed, so you can do this:
public virtual string IdString
{
get { return Id.ToString("000000"); }
[Obsolete("Only used for xml serialization", error: true)]
set { throw new NotSupportedException(); }
}
This will error if anyone uses the setter accidentally.

To take the solution a little further to allow deserialization to work as well...
public class A
{
private int _id = -1;
public int Id
{
get { return _id; }
set
{
if (_id < 0)
throw new InvalidOperationException("...");
if (value < 0)
throw new ArgumentException("...");
_id = value;
}
}
}
This will allow Id to be set exactly one time to a value greater than or equal to 0. Any attempts to set it after will result in InvalidOperationException. This means that XmlSerializer will be able to set Id during deserialization, but it will never be able to be changed after. Note that if the property is a reference type then you can just check for null.
This may not be the best solution if you have a lot of read-only properties to serialize/deserialize as it would require a lot of boilerplate code. However, I've found this to be acceptable for classes with 1-2 read-only properties.
Still a hack, but this is at least a little more robust.

WCF service proxy not setting "FieldSpecified" property

I've got a WCF DataContract that looks like the following:
namespace MyCompanyName.Services.Wcf
{
[DataContract(Namespace = "http://mycompanyname/services/wcf")]
[Serializable]
public class DataContractBase
{
[DataMember]
public DateTime EditDate { get; set; }
// code omitted for brevity...
}
}
When I add a reference to this service in Visual Studio, this proxy code is generated:
/// <remarks/>
[System.CodeDom.Compiler.GeneratedCodeAttribute("System.Xml", "2.0.50727.3082")]
[System.SerializableAttribute()]
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.ComponentModel.DesignerCategoryAttribute("code")]
[System.Xml.Serialization.XmlTypeAttribute(Namespace="http://mycompanyname/services/wcf")]
public partial class DataContractBase : object, System.ComponentModel.INotifyPropertyChanged {
private System.DateTime editDateField;
private bool editDateFieldSpecified;
/// <remarks/>
[System.Xml.Serialization.XmlElementAttribute(Order=0)]
public System.DateTime EditDate {
get {
return this.editDateField;
}
set {
this.editDateField = value;
this.RaisePropertyChanged("EditDate");
}
}
/// <remarks/>
[System.Xml.Serialization.XmlIgnoreAttribute()]
public bool EditDateSpecified {
get {
return this.editDateFieldSpecified;
}
set {
this.editDateFieldSpecified = value;
this.RaisePropertyChanged("EditDateSpecified");
}
}
// code omitted for brevity...
}
As you can see, besides generating a backing property for EditDate, an additional <propertyname>Specified property is generated. All good, except that when I do the following:
DataContractBase myDataContract = new DataContractBase();
myDataContract.EditDate = DateTime.Now;
new MyServiceClient.Update(new UpdateRequest(myDataContract));
the EditDate was not getting picked up by the endpoint of the service (does not appear in the transmitted XML).
I debugged the code and found that, although I was setting EditDate, the EditDateSpecified property wasn't being set to true as I would expect; hence, the XML serializer was ignoring the value of EditDate, even though it's set to a valid value.
As a quick hack I modified the EditDate property to look like the following:
/// <remarks/>
[System.Xml.Serialization.XmlElementAttribute(Order=0)]
public System.DateTime EditDate {
get {
return this.editDateField;
}
set {
this.editDateField = value;
// hackhackhack
if (value != default(System.DateTime))
{
this.EditDateSpecified = true;
}
// end hackhackhack
this.RaisePropertyChanged("EditDate");
}
}
Now the code works as expected, but of course every time I re-generate the proxy, my modifications are lost. I could change the calling code to the following:
DataContractBase myDataContract = new DataContractBase();
myDataContract.EditDate = DateTime.Now;
myDataContract.EditDateSpecified = true;
new MyServiceClient.Update(new UpdateRequest(myDataContract));
but that also seems like a hack-ish waste of time.
So finally, my question: does anyone have a suggestion on how to get past this unintuitive (and IMO broken) behavior of the Visual Studio service proxy generator, or am I simply missing something?

It might be a bit unintuitive (and caught me off guard and reeling, too!) - but it's the only proper way to handle elements that might or might not be specified in your XML schema.
And it also might seem counter-intuitive that you have to set the xyzSpecified flag yourself - but ultimately, this gives you more control, and WCF is all about the Four Tenets of SOA of being very explicit and clear about your intentions.
So basically - that's the way it is, get used to it :-) There's no way "past" this behavior - it's the way the WCF system was designed, and for good reason, too.
What you always can do is catch and handle the this.RaisePropertyChanged("EditDate"); event and set the EditDateSpecified flag in an event handler for that event.

try this
[DataMember(IsRequired=true)]
public DateTime EditDate { get; set; }
This should omit the EditDateSpecified property since the field is specified as required

Rather than change the setters of the autogenerated code, you can use an extension class to 'autospecify' (bind the change handler event). This could have two implementations -- a "lazy" one (Autospecify) using reflection to look for fieldSpecified based on the property name, rather than listing them all out for each class in some sort of switch statement like Autonotify:
Lazy
public static class PropertySpecifiedExtensions
{
private const string SPECIFIED_SUFFIX = "Specified";
/// <summary>
/// Bind the <see cref="INotifyPropertyChanged.PropertyChanged"/> handler to automatically set any xxxSpecified fields when a property is changed. "Lazy" via reflection.
/// </summary>
/// <param name="entity">the entity to bind the autospecify event to</param>
/// <param name="specifiedSuffix">optionally specify a suffix for the Specified property to set as true on changes</param>
/// <param name="specifiedPrefix">optionally specify a prefix for the Specified property to set as true on changes</param>
public static void Autospecify(this INotifyPropertyChanged entity, string specifiedSuffix = SPECIFIED_SUFFIX, string specifiedPrefix = null)
{
entity.PropertyChanged += (me, e) =>
{
foreach (var pi in me.GetType().GetProperties().Where(o => o.Name == specifiedPrefix + e.PropertyName + specifiedSuffix))
{
pi.SetValue(me, true, BindingFlags.SetField | BindingFlags.SetProperty, null, null, null);
}
};
}
/// <summary>
/// Create a new entity and <see cref="Autospecify"/> its properties when changed
/// </summary>
/// <typeparam name="T"></typeparam>
/// <param name="specifiedSuffix"></param>
/// <param name="specifiedPrefix"></param>
/// <returns></returns>
public static T Create<T>(string specifiedSuffix = SPECIFIED_SUFFIX, string specifiedPrefix = null) where T : INotifyPropertyChanged, new()
{
var ret = new T();
ret.Autospecify(specifiedSuffix, specifiedPrefix);
return ret;
}
}
This simplifies writing convenience factory methods like:
public partial class MyRandomClass
{
/// <summary>
/// Create a new empty instance and <see cref="PropertySpecifiedExtensions.Autospecify"/> its properties when changed
/// </summary>
/// <returns></returns>
public static MyRandomClass Create()
{
return PropertySpecifiedExtensions.Create<MyRandomClass>();
}
}
A downside (other than reflection, meh) is that you have to use the factory method to instantiate your classes or use .Autospecify before (?) you make any changes to properties with specifiers.
No Reflection
If you don't like reflection, you could define another extension class + interface:
public static class PropertySpecifiedExtensions2
{
/// <summary>
/// Bind the <see cref="INotifyPropertyChanged.PropertyChanged"/> handler to automatically call each class's <see cref="IAutoNotifyPropertyChanged.Autonotify"/> method on the property name.
/// </summary>
/// <param name="entity">the entity to bind the autospecify event to</param>
public static void Autonotify(this IAutoNotifyPropertyChanged entity)
{
entity.PropertyChanged += (me, e) => ((IAutoNotifyPropertyChanged)me).WhenPropertyChanges(e.PropertyName);
}
/// <summary>
/// Create a new entity and <see cref="Autonotify"/> it's properties when changed
/// </summary>
/// <typeparam name="T"></typeparam>
/// <returns></returns>
public static T Create<T>() where T : IAutoNotifyPropertyChanged, new()
{
var ret = new T();
ret.Autonotify();
return ret;
}
}
/// <summary>
/// Used by <see cref="PropertySpecifiedExtensions.Autonotify"/> to standardize implementation behavior
/// </summary>
public interface IAutoNotifyPropertyChanged : INotifyPropertyChanged
{
void WhenPropertyChanges(string propertyName);
}
And then each class themselves defines the behavior:
public partial class MyRandomClass: IAutoNotifyPropertyChanged
{
public void WhenPropertyChanges(string propertyName)
{
switch (propertyName)
{
case "field1": this.field1Specified = true; return;
// etc
}
}
}
The downside to this is, of course, magic strings for property names making refactoring difficult, which you could get around with Expression parsing?

Further information
On the MSDN here
In her answer, Shreesha explains that:
"Specified" fields are only generated on optional parameters that are structs. (int, datetime, decimal etc). All such variables will have additional variable generated with the name Specified.
This is a way of knowing if a parameter is really passed between the client and the server.
To elaborate, an optional integer, if not passed, would still have the dafault value of 0. How do you differentiate between this and the one that was actually passed with a value 0 ? The "specified" field lets you know if the optional integer is passed or not. If the "specified" field is false, the value is not passed across. If it true, the integer is passed.
so essentially, the only way to have these fields set is to set them manually, and if they aren't set to true for a field that has been set, then that field will be missed out in the SOAP message of the web-service call.
What I did in the end was build a method to loop through all the members of the object, and if the property has been set, and if there is a property called name _Specified then set that to true.

Ian,
Please ignore my previous answers, was explaining how to suck eggs. I've voted to delete them.
Could you tell me which version of Visual Studio you're using, please?
In VS2005 client - in the generated code, I get the <property>Specified flags, but no event raised on change of values. To pass data I have to set the <property>Specified flag.
In Visual Web Developer 2008 Express client - in the generated code, I get no <property>Specified flags, but I do get the event on change of value.
Seems to me that this functionality has evolved and the Web Dev 2008 is closer to what you're after and is more intuitive, in that you don't need to set flags once you've set a value.
Bowthy

Here's a simple project that can modify the setters in generated WCF code for optional properties to automatically set the *Specified flags to true when setting the related value.
https://github.com/b9chris/WcfClean
Obviously there are situations where you want manual control over the *Specified flag so I'm not recommending it to everyone, but in most simple use cases the *Specified flags are just an extra nuisance and automatically setting them saves time, and is often more intuitive.
Note that Mustafa Magdy's comment on another answer here will solve this for you IF you control the Web Service publication point. However, I usually don't control the Web Service publication and am just consuming one, and have to cope with the *Specified flags in some simple software where I'd like this automated. Thus this tool.

Change proxy class properties to nullable type
ex :
bool? confirmed
DateTime? checkDate