Added support to keep and resolve aspects from IoC container

[samoshkin]

Hi,

Recently I've learned about SNAP. Tried to use it in a project, I'm currently working on. And I ran into lack of the ability to keep aspects in container and having SNAP to resolve aspect instances from the container just before interception occurs.

Problems of direct aspect instantiation

Here are some problems I see with current approach of direct aspect instantiation.

• All business components are kept in container while aspect classes are not managed by IoC Container, and instead are created manually on container setup step. This seems inconsistent: aspect class doesn't differ much from business component and could be considered as a regular component. Why not let container manage all the components?
• Another problem, that aspects classes could use other services, which are already kept in container. Consider LoggerAspect class which have dependency to DiagnosticService, which is already managed by container. Currently there is no way to supply external dependency into an aspect class. This downgrades aspect classes to be very simple ones (w/o external dependencies), or forces the developer to get access to external dependencies via static ServiceLocator.

It would be nice to allow container manage both aspects and business components and resolve dependencies between them rather than forcing developer in burden of doing it on its own. So, I've decided to add this valuable feature to SNAP.

New behavior

All changes are non-breaking!

1. When configuring SNAP, developer could specify whether all or selected set of aspects are managed by container.
2. When intercepting method and aspect is configured to be kept in container, SNAP will resolve aspect (instance of specified interceptor type) from IoC container rather that directly instantiate it. Otherwise, SNAP will instantiate it directly via constructor.
3. Default behavior is to use direct instantiation rather that resolving aspect from IoC container. So, existing clients will not be affected.

This behavior is applied for all of 5 currently supported containers: Autofac, Castle.Windsor, Ninject, StructureMap, LinFu.

Detailed commit list

8f62fbf
Refactor MethodInterceptor class.

Do some refactoring of MethodInterceptor class. Extract SignatureCache and related functionality to separate class (Interception). Interception notion is a binding of the interceptor type being applied to the specific method, which is decorated with the specific attribute. This class allow to get target attribute and method info for given method invocation (intercepted one).

c785ae6
Add concept InterceptorRegistration.

We need to avoid creating aspect instances of SNAP configuration step.
Do not create instances of IAttributeInterceptor directy on aspect configuration build step. Just create list of interceptor registrations (that is, settings of InterceptorType, TargetAttribute and Order). Defer instantiation of IAttributeInterceptor, move this logic it in MasterProxy class just before invoking the interceptor.

e367e47
Added support for Snap.Autofac to keep and resolve aspects from container instead of creating them directly.

1. Add reference to CommonServiceLocator.1.0 to provide access to containers from different vendors in a container-agnostic manner.
2. Add concept of IInteceptorCreationStrategy. Create two implementations: InstantiateInterceptorDirectlyCreationStrategy and ResolveInterceptorFromContainerCreationStrategy.
3. Change MasterProxy class to select appropriate strategy of how to create interceptor isntances.
4. Change AutofacAspectModule.RegistrationActivating hook. Wrap Autofac container instance in a service locator adapter and pass it to MasterProxy.
5. Cover new functionality with unit tests.

In several next commits:
1f58e6d: Add support for Snap.CastleWindsor to keep and resolve aspects from container.
edd2530: Add support for Snap.StructureMap to keep and resolve aspects from container.
33f3d2b: Add support for Snap.Ninject to keep and resolve aspects from container.
92555a2: Add support for LinFu to keep and resolve aspects from container.

FIX for LinFu:
33f87af
Change LinFu aspect post processing behavior not to intercept types which implement IInterceptor. Inteceptors could not be intercepted too.

70564b2
When service is not registered in container and being asken, NullReferenceException is thrown in AspectPostProcessor class due to IServiceRequestResult.ActualResult is null.
Fix to do nothing in AspectPostProcessor class if IServiceRequestResult.ActualResult is null.

---

No activity was in upstream master branch since I've forked (samoshkin:keep-aspects-in-container branch is fast-forward from TylerBrinks:master).
Well, seems that's all. I'm looking forward for your response.

[TylerBrinks]

Merged your changes. Any chance you can update the github wiki so everyone else using SNAP can understand the changes?

Thanks!

[samoshkin]

Hi,

Any chance you can update the github wiki so everyone else using SNAP can understand the changes?
No problems. Will do it till the end of the week.

[samoshkin]

Added new page to github wiki: Aspect instance management.