Auditing user actions

I want to be able audit user actions on the domain model - I want to track when & what they've changed. Now I can do this at the course grained level using nHibernate event listeners, they can tell me when an entity is loaded, saved, updated etc. But without interrogating the state of the entity in depth I'm unable to determine what's gone on between loading an entity and it being saved.

This is where the idea of domain events comes the rescue - the idea of generating events from the domain model. Now this could be done using the standard .Net event pattern, but as described in the above link the use of a decoupled domain events is way more powerful -the use of an intermediary ('DomainEvents' class) to decouple the domain model from the event handlers is simplistic and beautiful.

So now I can have an auditing service listening to both nHibernate & the domain model to track user actions across the domain and when a domain entity is persisted I can then push out the audit data to a message queue for processing asynchronously.

My requirement for auditing goes further than just tracking what a user did, it also includes tracking usage (of the domain model) - we want to track every time a user accesses content to provide usage reports and invoice accordingly...

This will be collected via the same domain events - it's just another specific audit handler, etc.


Simple!


Awkward Coder

Read More

Unstructured development opportunity

Anyone spot the oxymoron in the snippet of a job spec I received today:

Ability to handle multiple competing priorities, work with minimal formal specifications, and deliver at the highest levels.

It then goes on to say:

Experience of designing, building and maintaining sophisticated automated trading applications with a large userbase and significant business dependency. Equity, future and option experience and working closely with business users.

There really must be some telepathic developers out there - no specification but expected to do some kind of BUF design..

I believe the people who run and develop in these type of teams have no experience of working in environments with any kind of formal structure and expect to spend most of their time & money on support & maintenance - but there again the opportunity is everything in the finance sector!

Also they will say they're doing 'Agile', note they don't do 'agile'.

Awkward Coder

Read More

Property setters are just wrong!

In general I think the use of property setters on classes is a sign of bad class design and a lack of OO principles - in most cases when you modify the 'state' of a class some 'behaviour' is invoked whether it be implicit or explicit;

e.g. when I change the address on a user account I want to make sure the address object has been populated (at least).

So these days I've started to design classes that have public getters & private setters, and if you want to modify state you are required to call a method, e.g. 'ChangeAddress'. This is nothing new, there are plenty of examples out there.

So in the example below 'Token' is property that's defined when the object is constructed and 'Path' is a property which is modified by calling the method 'ChangePath'.

    public class File : ObservableEntity<int>
    {
        private string _path;
        private Guid _token;

        private readonly IExtractFileProperties _propertiesExtractor = new FilePropertiesExtractor();
    

        public File()
        {
            _token = Guid.NewGuid();
        }


        public virtual string Path
        {
            get { return _path; }
            private set { ChangePropertyAndNotify(ref _path, value, x => Path); }
        }

        public virtual Guid Token
        {
            get { return _token; }
            private set { ChangePropertyAndNotify(ref _token, value, x => Token); }
        }

     
        public File ChangePath(string path)
        {
            Path = path;

            Size = _propertiesExtractor.Size(Path);
            Format = _propertiesExtractor.Format(Path);
            FileCreatedOn = _propertiesExtractor.CreatedOn(Path);
            FileLastModified = _propertiesExtractor.LastModified(Path);

            return this;
        }    
    }

Now this attitude has been going well as it's made my classes more behaviour rich with better encapsulation & abstraction.

The only problem I've come across is when I'm trying to re-hydrate objects from the database where the properties I'm attempt to set have some kind of special behaviour - properties representing timestamps & versions that are historically set in the database via some function.

So in the following example I've got 3 properties - 'CreatedOn' 'LastModified' & 'Version'. I don't want to expose a method to set this values - I want them to be immutable...

But this is going to be a problem with an ORM, how am I going to update these values when saving or updating - I want them appear to be auto-updating from a users perspective.

    public abstract class ObservableEntity<T> : IEntity<T>, INotifyPropertyChanged
    {
        public event PropertyChangedEventHandler PropertyChanged = delegate { };

        private T _id;

        private DateTime? _createdOn;
        private DateTime? _lastModified;
        private int? _version;

        public virtual T Id
        {
            get { return _id; }
            private set { ChangePropertyAndNotify(ref _id, value, x => Id); }
        }

        public virtual DateTime? CreatedOn
        {
            get { return _createdOn; }
            private set { ChangePropertyAndNotify(ref _createdOn, value, x => CreatedOn); }
        }

        public virtual DateTime? LastModified
        {
            get { return _lastModified; }
            private set { ChangePropertyAndNotify(ref _lastModified, value, x => LastModified); }
        }

        public virtual int? Version
        {
            get { return _version; }
            private set { ChangePropertyAndNotify(ref _version, value, x => Version); }
        }

        protected void ChangePropertyAndNotify<T2>(ref T2 value, T2 newValue, Expression<Func<object, T2>> expression)
        {
            value = newValue;
            Notify(expression);
        }

        protected void Notify<T2>(Expression<Func<object, T2>> expression)
        {
            var propertyName = ((MemberExpression)expression.Body).Member.Name;
            PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
        }
    }

Now when using nHibernate as your ORM this becomes very easy because you can attach Listeners and do custom actions.

So I've got a custom action when NH saves or updates an entity to set these properties with the correct values.

public class EntitySaveOrUpdateEventListener : IPreInsertEventListener, IPreUpdateEventListener
    {
        public bool OnPreInsert(PreInsertEvent @event)
        {
            var hasType = (@event.Entity.GetType().GetInterface(typeof(IVersionable).Name, true) != null);
            if (!hasType)
                return false;

            var now = DateTime.Now;
            var createdOnIndex = new List<string>(@event.Persister.PropertyNames).FindIndex(x => x == "CreatedOn");
            @event.State[createdOnIndex] = now;
            SetPrivateVariable("CreatedOn", now, @event.Entity);

            var lastModifiedIndex = new List<string>(@event.Persister.PropertyNames).FindIndex(x => x == "LastModified");
            @event.State[lastModifiedIndex] = now;
            SetPrivateVariable("LastModified", now, @event.Entity);

            var versionIndex = new List<string>(@event.Persister.PropertyNames).FindIndex(x => x == "Version");
            var version = GetPrivateVariable<int?>("Version", @event.Entity);

            version = version.GetValueOrDefault() + 1;
            @event.State[versionIndex] = version;
            SetPrivateVariable("Version", version, @event.Entity);
            
            return false;
        }

        public bool OnPreUpdate(PreUpdateEvent @event)
        {
            var hasType = (@event.Entity.GetType().GetInterface(typeof(IVersionable).Name, true) != null);
            if (!hasType)
                return false;

            var now = DateTime.Now;
            var lastModifiedIndex = new List<string>(@event.Persister.PropertyNames).FindIndex(x => x == "LastModified");
            @event.State[lastModifiedIndex] = now;
            SetPrivateVariable("LastModified", now, @event.Entity);

            var versionIndex = new List<string>(@event.Persister.PropertyNames).FindIndex(x => x == "Version");
            var version = GetPrivateVariable<int?>("Version", @event.Entity);

            version = version.GetValueOrDefault() + 1;
            @event.State[versionIndex] = version;
            SetPrivateVariable("Version", version, @event.Entity);
            return false;
        }

        public void SetPrivateVariable(string name, object value, object entity)
        {
            var entityType = entity.GetType();

            var pi = entityType.GetProperty(name, BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Instance);
            pi.ReflectedType.BaseType.InvokeMember(name,
                                            BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.SetProperty | BindingFlags.Instance,
                                            null,
                                            entity,
                                            new[] { value });
        }

        public T GetPrivateVariable<T>(string name, object entity)
        {
            var entityType = entity.GetType();

            var pi = entityType.GetProperty(name, BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Instance);

            return (T)pi.GetValue(entity, null);
        }
    }

Now if you follow this code, when an entity is saved for the first time then the 'CreatedOn' & 'LastModified' property values are set to the current date & time and the 'Version' property is incremented (the initial value is 0) via the private backing properties. When the entity is updated only the 'LastModified' & 'Version' properties are set via the private backing properties.

This event listener is then instantiated via the fluent NH config.

private static ISessionFactory CreateSessionFactoryImpl()
        {
            return Fluently.Configure()
                .Database(MsSqlConfiguration.MsSql2005.ConnectionString(c => c.FromConnectionStringWithKey("Pronunciations")).ShowSql())
                .Mappings(m => m.FluentMappings.AddFromAssemblyOf<IMap>())
                .ExposeConfiguration(c =>
                                         {
                                             c.EventListeners.PreInsertEventListeners = new IPreInsertEventListener[] { new EntitySaveOrUpdateEventListener() };
                                             c.EventListeners.PreUpdateEventListeners = new IPreUpdateEventListener[] { new EntitySaveOrUpdateEventListener() };
                                         })
                .BuildSessionFactory();
        }

Awkward Coder

Read More

Lambda beats magic string

Okay magic strings are a pain, in the worst cases they're bugs waiting to happen but I've been living with the following for while and it's always been nagging me when ever I look at the code.

public abstract class Observable<T> : IEntity<T>, INotifyPropertyChanged
{
public event PropertyChangedEventHandler PropertyChanged = delegate { };

private T _id;

public virtual T Id
{
 get { return _id; }
 private set { ChangePropertyAndNotify(ref _id, value, "Id"); }
}

protected void ChangePropertyAndNotify<T2>(ref T2 value, T2 newValue, string propertyName)
{     
 PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
}
}

So after reading the MSDN article by Jeremy Miller and the example of using the Lambda expression in Fluent nHibernate mapping syntax I thought can we apply this to the above to remove the magic string "Id", and the answer is yes!

public abstract class Observable<T> : IEntity<T>, INotifyPropertyChanged
{
public event PropertyChangedEventHandler PropertyChanged = delegate { };

private T _id;

public virtual T Id
{
  get { return _id; }
  private set { ChangePropertyAndNotify(ref _id, value, x => Id); }
}

protected void ChangePropertyAndNotify<T2>(ref T2 value, T2 newValue, Expression<Func<object, T2>> expression)
{
  value = newValue;
  var propertyName = ((MemberExpression)expression.Body).Member.Name;
  PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
}
}

The power of this is the Expression syntax and the ability at runtime to query and manipulate for other purposes other than what it was directly designed for.

Now is there a performance penalty for doing this?

Simple answer is I don't care until it becomes a problem, and to be honest I don't currently think it's going to be - avoid premature optimization at all costs, they're distractions from the requirement.

Awkward Coder

Read More

Using repositories inside a domain entity

If you follow the principles of DDD you'll be well aware of the persistence ignorance discussion\argument. I believe domain entities should be agnostic of the persistence layer and therefore not statically bound at compile time. Overall I'm happy with this approach but it does give issues when trying to place certain business logic on the entity that requires access to some service (read repository).

Now obviously you can use the 'double-dispatch' approach and pass in the repository via an interface and only couple the entity to an interface, but to me this still seems a level of coupling that's unacceptable - usually we see these interfaces in an 'interfaces' project, to couple this to the domain model (entities) seems wrong.

So to get round this you can use functional programming, to be more specific you can use a lambda expression.

So imagine I have a Registration entity and it has responsibility for generating the user name from other data contained in the registration entity. Now to make sure the suggested user name hasn't already been allocated in the database the Registration entity needs to call the database to work this out.

So to avoid coupling the repository interface to the entity we pass in a Func<> into the method and call this to talk to the database, now from the entity perspective it's doesn't know what or how the func is defined it only know the parameters it has to provide and the result from the function - hence reduced coupling.

public sealed class Registration
    {
        public int? Id { get; private set; }
        public string Username { get; set; }
        public string FirstName { get; set; }
        public string LastName { get; set; }

        public Registration(int? id)
        {
            Id = id;
        }

        public void GenerateUserName(Func<string, IList<Registration>> func)
        {
            var suggestedUserName = FirstName + "." + LastName;
            var existingNames = func(suggestedUserName);

            if (existingNames.Count != 0)
                suggestedUserName += (existingNames.Count + 1);

            Username = suggestedUserName;
        }
    }

Now the Func> takes a parameter and returns a list of Registration objects. And you can probably imagine the Func<> is a call to database looking for all matches of the suggested name.

So from the calling perspective the code now looks like this, with a single line to generate the suggested user name and check it against the database.

public sealed class AssetManagementService : IServiceAssetManagement
    {
        public AssetManagementService(IRepository<Registration, string> registrationRepository,
                                      ICanValidate<RegistrationArgs> registrationValidator)
        {
            _registrationRepository = registrationRepository;
        }
  
        public void RegisterUser(Registration registration)
        {
            registration.GenerateUserName(x => _registrationRepository.FindBy(new FindByMatchingUsername(x)));
      
            var result = _registrationValidator.Validate(new RegistrationArgs(registration));
            if (!result.IsValid())
                throw new ArgumentException(result.Message, "registration");

            using (var transaction = new TransactionScope(TransactionScopeOption.Required))
            {
                _registrationRepository.Save(registration);

                transaction.Complete();
            }
        }
    }

Now from an OO perspective this is bad, violations of basic principles of Encapsulation & Abstraction, but and it's a big but it is an attempt to become more declarative and it's definitely using a Functional programming style which whether you like it or not will become a standard addition to any developer toolbox in the future. Personally I starting like the declarative nature and the clean code this produces.

Awkward Coder

Read More

Functional intro

Jeremy Miller has a great article in this months MSDN magazine introducing functional programming for the OO developer. If you've been using the features of .Net 3.5 - Func, Action, etc. you've probably been using these techniques & patterns without realising. I know I have.

It's a good read!

You might also be interested in Jon Skeet's new book release later this month.


Awkward Coder

Read More