Proper Setup of Listeners For DI

Description

So I've been exploring how Event Listeners are set up with DI and it looks like they are instantiated when the session factory is first configured and they are persisted for the duration of the session factory. I feel like this takes a way from some of the features DI provides, like registering types per request which seems impossible if we are not resolving the EventListeners when we need them as appose to at application start.

I've made some adjustments to the code in order to resolve event listeners as needed:

When configuring:

cfg.SetListenersDI(ListenerType.PostInsert, new[]
                {
                    typeof(FormGeneratorCreate).AssemblyQualifiedName
                });

In Cfg/Configuration.cs

public void SetListenersDI(ListenerType type, string[] listenerClasses)
		{
			eventListeners.DIListenerRegistration.Add(type, listenerClasses);
		}

Event/EventListeners.cs

public readonly IDictionary<ListenerType, string[]> DIListenerRegistration =
			new Dictionary<ListenerType, string[]>();

		public IPostUpdateEventListener[] PostCommitUpdateEventListeners
		{
			get
			{
				IPostUpdateEventListener[] eventListeners =
					GetListenersForDI(ListenerType.PostCommitUpdate) as IPostUpdateEventListener[];

				if (eventListeners != null)
				{
					return eventListeners;
				}

				return postCommitUpdateEventListeners;
			}
			set
			{
				if (value != null)
				{
					postCommitUpdateEventListeners = value;
				}
			}
		}


		private object[] GetListenersForDI(ListenerType listenerType)
		{
			string[] listenerClasses;
			if (DIListenerRegistration.TryGetValue(listenerType, out listenerClasses))
			{
				var listeners = (object[])Array.CreateInstance(GetListenerClassFor(listenerType), listenerClasses.Length);
				for (int i = 0; i < listeners.Length; i++)
				{
					try
					{
						listeners[i] = Cfg.Environment.BytecodeProvider.ObjectsFactory.CreateInstance(ReflectHelper.ClassForName(listenerClasses[i]));
					}
					catch (Exception e)
					{
						throw new MappingException(
							"Unable to instantiate specified event (" + listenerType + ") listener class: " + listenerClasses[i], e);
					}
				}

				return listeners;
			}

			return null;
		}

I'm not too sure why it was done the other way (maybe for performance)? Even if we are resolving these types when needed I don't believe it would be that much of a performance hit and would allow more flexibility with DI.

Environment

None

Activity

Show:

Sammi Maan Sinno January 19, 2017 at 5:03 PM

any thoughts on this? if I fork and do a merge request is there a possibility it will get accepted?

Details

Assignee

Unassigned

Reporter

Sammi Maan Sinno

Labels

Components

ByteCode providers

Affects versions

4.1.0

Priority

Trivial

Who's Looking?

Open Who's Looking?

Created January 17, 2017 at 4:53 PM

Updated January 19, 2017 at 5:03 PM

Configure

Who's Looking?