Log in


   Active Threads  

You are here: Home > LLBLGen Pro > Architecture> DRY approach to audit fields

Pages: 1
DRY approach to audit fields

  Print all messages in this thread  
Poster Message

Joined on:
23-Jan-2005 19:53:47
393 posts
# Posted on: 19-Jan-2017 16:54:29.  
Like many other places, we have some tables in our database with audit fields such as LastModifiedTimestamp and LastModifiedBy. However, not all tables have these fields and some tables might only have one of them. (Yes, this is a database consistency issue first, but the database is more than 20 years old and it's not getting fixed this year. Dissapointed)

I'd like to manage this from one piece of code. Essentially, before saving, test for IsDirty/IsNew and update the timestamp and/or user id if the entity has changed or is new.

There are two previous threads that touch on this topic.


I could override DataAccessAdapter but I'd need to do some kind of test for whether either of those fields were in the entity being saved.

(From this thread https://llblgen.com/tinyforum/Messages.aspx?ThreadID=3612)

        /// <summary>
        /// Overrides OnBeforeEntitySave. This allows us to "interrupt" the save of an entity to populate audit fields.
        /// </summary>
        /// <param name="entitySaved"></param>
        /// <param name="insertAction"></param>
        public override void OnBeforeEntitySave(IEntity2 entitySaved, bool insertAction)
            string auditSaveType = string.Empty;

            if (entitySaved.IsNew)
//need to test whether this entity actually has these audit fields
                entitySaved.SetNewFieldValue("CreatedByUserId", _userId);
                entitySaved.SetNewFieldValue("CreatedDate", DateTime.Now);

            if (entitySaved.IsDirty)
//need to test whether this entity actually has these audit fields
                entitySaved.SetNewFieldValue("LastUpdatedByUserId", _userId);
                entitySaved.SetNewFieldValue("LastUpdatedDate", DateTime.Now);
            base.OnBeforeEntitySave(entitySaved, insertAction);

I'm looking for any suggestions on how to handle this. Is overriding the DataAccessAdapter the best approach from an application perspective? What would be the most efficient way to test for field existence? Or is there a better way (something like AOP perhaps)?
Joel Reinford
LLBLGenPro Version: 5.5.3
Templates: Adapter
Framework: .Net 4.6
Database: SQL Server 2012/2014, DB2 v10
Support Team

Guatemala City
Joined on:
28-Nov-2005 23:35:24
8137 posts
# Posted on: 20-Jan-2017 06:44:13.  
OnBeforeEntitySave is a good place for that. You could use an Auditor as well, however, as the field to be updated is in the same entity I think that OnBeforeEntitySave is best suitable for that.

About the entities that doesn't look like these auditable entities, you could mark the auditable entities with some interface in LLBLGen Designer then use that interface in your code to differentiate them, and use that concept to discriminate them in the OnBeforeEntitySave handler. More info about this: http://www.llblgen.com/documentation/5.1/Designer/How%20To/AssignInterfacesNamespacesToElements.htm

David Elizondo
LLBLGen'ing (articles and code snippets) | linkedin | twitter
Pages: 1  

Powered by HnD ©2002-2007 Solutions Design
HnD uses LLBLGen Pro

Version: 2.1.12172008 Final.