1

I've got a Web API project, supported by a MSSQL database containing creation and modified fields on (almost) every table. There are triggers on those fields, such that both are updated when inserting and updating a record, respectively.

Now when I'm serializing the data into JSON after a successful request, I do want to send those creation and modified fields such that the front-end making the request can do their thing with it. What I do not want, however, is that these fields can be modified when the data gets deserialized (or, POSTed back). Quite simple, you would say, just use the [JsonIgnore] attribute on the fields; put it only on the set and not on the get.

Now here is where things start to get confusing for me. All models in my project are automatically generated from an Entity Model (.edmx). As such, I cannot directly edit anything into the models themselves, but I have to generate partial models on top of them. I've seen solutions for this in other SO threads, using the [MetadataType] attribute, like this one here.

But how do I apply this (efficiently) to my case? I've been searching around, but haven't found an example on how to pull apart the auto-implemented properties in a 'higher' partial class. And even so, this would mean that I would have to create partial classes for all my models, which would be quite cumbersome. I can't imagine no-one has ever done this before, so wouldn't there be a more elegant way of pursuing this?

An example of a class would be:

public partial class Person
{
    [DataMember]
    public Nullable<System.DateTime> Created { get; set; }
    [DataMember]
    public Nullable<System.DateTime> Modified { get; set; }
}
Community
  • 1
  • 1
Kazu
  • 627
  • 6
  • 17
  • Create Dto object from Your Entity Model instead of using Enity Model directly – cuongle Mar 28 '13 at 10:05
  • Would I really need to generate DTOs for each class I have, in order to just keep the creation and modified fields out of the set operations? This would generate a lot of overhead, I would guess... – Kazu Jun 24 '13 at 13:12

1 Answers1

1

Eventually I switched from a Model-First approach to a Code-First approach so that I would have much more control over my models.

Though, after searching a lot, I came to answer my own question. The core of this question was that I wanted to be able to set the Created and Modified fields automatically, and ignore the deserialization of the front-end, whilst still being able to send those fields through serialization to the front-end.

The solution lies in overriding the SaveChanges method in the DbContext class. An excellent example of this is given in this SO thread: Entity Framework 4.1 DbContext Override SaveChanges to Audit Property Change. So all courtesy goes to James Pogran for sparking the idea in my head, and solving the problem in that way.

What he does is checking in what way the DbEntity is changed. He sets the Created and Modified fields according to whether the entry is being added or modified, and subsequently calls base.SaveChanges in order to continue normal operations.

Community
  • 1
  • 1
Kazu
  • 627
  • 6
  • 17