Passing contextual information with the IUnitOfWork and LightSpeedContext instances

Hello,

I have a few data access libraries that are shared between different projects (web applications, Powershell cmdlets, WPF application). The data access library contains the necessary logic to enforce business logic, including sending emails when some entities were added, modified or deleted. However, when the installer application runs, I'd like to disable certain features, such as sending of emails, since the system isn't fully configured.

Is there perhaps a chance that a LightSpeedContext and IUnitOfWork can have a IDictionary where arbitrary information can be stored by the application? For example, suppose the dictionary were called "ContextData". The setup application can then add a key value pair called "DisableNotifications" with a value of true to LightSpeedContext.ContextData. In the OnSaved methods of my entity, I can check whether that key value pair exists in the UnitOfWork.Context and if it does disable notifications.

Another example includes passing the "tenant" information alongside the unit of work, which entities can use to automatically populate certain fields. However, since the "tenant" may be different from one request to another, such information is better managed alongside the UnitOfWork instead of the LightSpeedContext.

My code is increasingly getting more complex and testing is getting more difficult because I rely on IoC to inject that context into entities. I'm not sure that was wise.

Thanks, Werner

I solved the tenant issue with a ConnectionStrategy. However that's because tenants need to be mapped to certain databases.

Can you solve the second case with an extension method or subclassing the strongly-typed unit of work? You seem to keep coming back to problems where you want UOW to behave more like a Repository that fires NHibernate-style events -- yet you still need IoC and you've got a pretty wild class hierarchy.

Devil's advocate: are you sure you're chasing the simplest possible solution here?

chadw,

Doing the simplest thing is the most complex thing to achieve. How would I implement contextual based information using an extension method?

The complexity arises from using the data access layer in different types of processes (WCF, web application, powershell, windows services and installers) which each have their own quirks. I think I reached a point where simple isn't simple.

Werner