Not the best candidate for the first post, but rather the trigger to start.
Legacy technologies are still close to us. Great times of Cobol sank into oblivion. Some others are still alive and supported. Like WCF. Does anybody like it? Old wordy xml-based protocol with a lot of overhead and complicated configuration, making it quite sophisticated to deal with security, not always clear instance management. I'd like to talk about the latter.
Given: 10 years old WCF service, which we would like to extend and adjust for the future needs. We did not choose the technology. Some other people chose it for us long time ago. Amount of technical dept and dependencies on the external systems do not allow us to move towards REST or something else. So we have to live with what we have.
Idea: we would like to make our life less miserable and introduce, let's say, Automapper to map data contracts to domain object or to DTO (data transfer object) or any others. Or we'd like to leverage any Dependency Injection framework. What do they have in common? They have to be initialized only once per life time of the application (at least in most of the cases). How to interfere into WCF service life-cycle in order to achieve that?
Solution: set up a custom attribute, extending System.Attribute class and implementing System.ServiceModel.Description.IServiceBehavior interface. AddBindingParameter is the method being called before the actual method in the service implementation is called. AddBindingParameter is called once for each listen URI. For example, if a service has four endpoints, and two of them have the same listen URI, then this method gets called three times. More details: https://docs.microsoft.com/en-us/dotnet/api/system.servicemodel.description.iservicebehavior.addbindingparameters
Multiple invocation for the same method means that we have to make sure that Automapper or DI container is initialized only once. It could be done by implementing custom double-check logic or leveraging Lazy class (https://docs.microsoft.com/en-us/dotnet/api/system.lazy-1).
What could we also do is to make base class for the custom attribute. In the base class implement the double-check logic and allow users to instantiate their own code only once.
Given: 10 years old WCF service, which we would like to extend and adjust for the future needs. We did not choose the technology. Some other people chose it for us long time ago. Amount of technical dept and dependencies on the external systems do not allow us to move towards REST or something else. So we have to live with what we have.
Idea: we would like to make our life less miserable and introduce, let's say, Automapper to map data contracts to domain object or to DTO (data transfer object) or any others. Or we'd like to leverage any Dependency Injection framework. What do they have in common? They have to be initialized only once per life time of the application (at least in most of the cases). How to interfere into WCF service life-cycle in order to achieve that?
Solution: set up a custom attribute, extending System.Attribute class and implementing System.ServiceModel.Description.IServiceBehavior interface. AddBindingParameter is the method being called before the actual method in the service implementation is called. AddBindingParameter is called once for each listen URI. For example, if a service has four endpoints, and two of them have the same listen URI, then this method gets called three times. More details: https://docs.microsoft.com/en-us/dotnet/api/system.servicemodel.description.iservicebehavior.addbindingparameters
Multiple invocation for the same method means that we have to make sure that Automapper or DI container is initialized only once. It could be done by implementing custom double-check logic or leveraging Lazy class (https://docs.microsoft.com/en-us/dotnet/api/system.lazy-1).
What could we also do is to make base class for the custom attribute. In the base class implement the double-check logic and allow users to instantiate their own code only once.
