Updating table fields not included in model Linq to Entities

Question

So, I wanted to call this something like "Auditing Linq to Entities" or similar, but realize that doesn't quite encapsulate what I wanted to do. Simply put, our data modeler is required to put 4 columns on every single table within our aplication, even our cross-reference tables (the tables that represent the middle of a many-to-many relationship)

Anyhow, I've read a ton of articles that are about change tracking, which is close to what I want to do, but not exact. What I'm looking to do is to override the TSQL generation to append the column(s) that I need to update that are not included within the model.

Edit

Thinking more about this question, I realized that my example wasn't quite complete... imagine the User <---> Roles relationship and how that works. You typically create 3 tables: [Users], [Roles], and [UserRoles] which has 2 columns for referencing many users to many roles.

Now, imagine for all three tables, your loving DBA added 4 columns: CreatedBy, CreatedOn, UpdatedBy, UpdatedOn.

In Code, you'd probably have a Collection (list, collection, stack, etc.) of roles against each user, as in this C# code:

public class User
{
    public int Id { get; set;}
    public string Username { get; set;}
    public string Firstname { get; set; }
    public string Lastname { get; set; }
    public string Password { get; set; }
    public List<Role> Roles { get; set; }
}

public class Role
{
    public int Id {get; set; }
    public string Code { get; set; }
    public string Description { get; set; }
}

---

Has anyone successfully been able to update all the update and created columns without adding those fields to their model utilizing Entity Framework, and if so, can they provide examples of this?

Same question, but for NHibernate. If NHibernate will support this, but Entity Framework won't, I'm comfortable to persuade the powers-that-be to allow us to utilize NHibernate over Entity Framework, as I'll have a valid reason for this.

Answer 1

I have a very similar structure. The only ways to update the fields is to add them as properties to the objects (I encapsulate them in a AuditInfo class) or to use triggers. Users are shown the audit fields in my application so I have to have them available as properties anyway. NHibernate is so extensible that you can accomplish what you propose but it would be ugly.

In my case the triggers aren't sufficient because our application has its own user management so I have to set the xBy properties in the application. We also have the triggers in place as a backup and to record changes made outside of the application (data scrubs).

The many-to-many tables present a big problem because I would have to include them in the domain model in order to set the audit fields. I don't do that, so for those tables I only have the audit info available in the trigger (ie everything but the actual user name).

AuditInfo class:

[Serializable]
public sealed class AuditInfo
{
    public AuditInfo()
    {
        SetCreated(string.Empty, DateTime.Now);
    }

    public string CreatedBy { get; private set; }
    public DateTime CreatedDate { get; private set; }
    public string RevisedBy { get; private set; }
    public DateTime RevisedDate { get; private set; }

    public string CreatedInfo
    {
        get { return "Created: " + CreatedDate.ToShortDateString() + " by " + CreatedBy; }
    }

    public string RevisedInfo
    {
        get { return "Revised: " + RevisedDate.ToShortDateString() + " by " + RevisedBy; }
    }

    internal void SetCreated(string createdBy, DateTime createdDate)
    {
        CreatedBy = createdBy;
        CreatedDate = createdDate;
        SetRevised(createdBy, createdDate);
    }

    internal void SetRevised(string revisedBy, DateTime revisedDate)
    {
        RevisedBy = revisedBy;
        RevisedDate = revisedDate;
    }
}

Interface implemented by auditable entities:

public interface IAuditable
{
    AuditInfo AuditInfo { get; }
}