31

Closed

Service registration through configuration

description

The only way to register services today is in the AddModuleServices in the ModuleInitializer class. It would be great if this could be defined outside the module assembly, for example in a xml configuration file. This would allow service implementations to be placed in a separate assembly with no references from the main module assembly. I think this will make the architecture more composable and flexible.
Closed Oct 11, 2007 at 9:11 PM by blainew
These are in the October bundles in the Releases folders.

comments

simonince wrote Jan 23, 2007 at 8:42 AM

I agree - but I think modules could be required to register what services they require to function programmatically, then configuration is used to supply concrete implementations to meet these requirements.

wrote Jan 23, 2007 at 9:08 AM

wrote Jan 23, 2007 at 12:09 PM

MarianoSzklanny wrote Jan 23, 2007 at 1:16 PM

Simon, can you expand a bit more on your idea? What do you mean by "modules could be required to register what services they require to function programmatically, then configuration is used to supply concrete implementations to meet these requirements"?If modules register the services they need, why use configuration for them? Are you assuming that modules should register 'interfaces' only? How would that differ from having everything in configuration?

Are you looking for something like this?// web.config<module name="Module1"> <services> <service type="Module1.Services.MyService, Module1.Services" registerAs="Module1.Services.IMyService, Module1" scope="Module"> </services></module>

Please give as much detail as possible so we are on the same page.ThanksMariano Szklanny[url:http://staff.southworks.net/mariano]

simonince wrote Jan 23, 2007 at 2:27 PM

Mariano,

The way I imagine this working only applies to Global services - Module specific ones don't seem appropriate. So what I would expect is something like this for a module (this is just one way of doing this - attributes or configuration could also be used etc);

protected virtual void AddGlobalServices(IServiceCollection globalServices) { globalServices.RegisterRequiredServiceType<INavigationService>();globalServices.RegisterRequiredServiceType<ILogicService>(); }

Then, in configuration in the web site;

<applicationServices><service type="INavigationService, MyServiceAssembly" serviceProvider="MyWebNavigationService, MyConcreteServicesAssembly" />... etc</applicationServices>

Then, at initialisation time, the module loader checks that every "required" service has a matching concrete implementation in configuration.

I just feel this makes it easier to swap service providers in and out according to different situations.

MarianoSzklanny wrote Jan 23, 2007 at 3:52 PM

I get your point Simon, but I don't understand why a module should imperatively specify the services it requires:

-- [quote] ---globalServices.RegisterRequiredServiceType<INavigationService>();globalServices.RegisterRequiredServiceType<ILogicService>();---

You can simply use the [ServiceDependency] attribute to express that a service is required.Am I missing something?

Thanks

wrote Jan 23, 2007 at 4:00 PM

simonince wrote Jan 23, 2007 at 4:44 PM

That's a good point - but I think [ServiceDependency] would only validate the Interface exists at compile time... without some kind of checking I'm concerned that you lose some reliability when doing releases... at the moment, it is compile-time verified that the concrete service type exists, but if you move to configuration it is possible to deploy a module without deploying the required services.

It is therefore possible that the application could fail in an unpredictable manner; e.g. after running for a day someone uses the functionality that requires an IMyService that hasn't been used yet - and it has been missed from configuration. If some kind of checking during module initalisation occurs, this can be prevented.

Note the difference between the two approaches is that I am assuming a "pool" of global services would be registered, and at module initialisation each module checks it can find all it needs. What you have suggested is that each module specifies the global services it exposes - it is a slightly different angle on it I think!!

I suspect someone just needs to make a call on this one - feel free to email me if you want to discuss offline though (simon.ince@capgemini.com)

wrote Jan 29, 2007 at 9:20 AM

wrote Mar 7, 2007 at 8:46 PM

wrote Mar 14, 2007 at 11:36 PM

eavonius wrote Mar 21, 2007 at 2:36 PM

I think this is not a good idea. Users or support personnel who configure the product in the field can break dependencies between modules if they remove the registration of services that must be there for the code to work. This has been a major problem with some Java frameworks IMHO. Just my opinion however.

DavidHayden wrote Mar 21, 2007 at 5:21 PM

IMHO, not only is this feature critical, but I can't believe it wasn't offered at the beginning :)

Why anyone wouldn't want the option of being able to plug in concrete services via configuration at will without having to change source code is beyond my grasp. The only way I can change service providers now is by having to change the source code and recompile. Most times I would rather the ability to specify and swap out service providers via a configuration file without having to touch code.

If you don't want to use the proposed configuration approach for fear of somebody screwing it up, don't use it. However, certainly the option is very important for developers and applications that prefer a pluggable and provider-based approach to services and would rather be able to swap out providers without touching source code.

How is asking for this any different from Microsoft adding Membership, Profile, and Role Providers that can be swapped out at will in web.config without any change to code? It isn't :) It also makes sense for integration with Enterprise Library which is very much configuration-based, giving us that wonderful ability to change logging, database, cryptography, validation, etc. settings on customer demand without having to make source code changes.

Please add :) This is certainly my humble opinion, too, but it seems like a win-win to me.

Regards,

David HaydenMicrosoft MVP C#http://www.davidhayden.com/

wrote Mar 22, 2007 at 8:49 PM

wrote Mar 22, 2007 at 8:57 PM

wrote Mar 23, 2007 at 2:51 PM

wrote Mar 26, 2007 at 1:31 AM

wrote Mar 30, 2007 at 10:11 PM

ejadib wrote Apr 4, 2007 at 5:42 PM

Julian and I have written an article that discusses one possible way to register services through configuration.

[url:How-To: Registering services through configuration in WCSF|http://staff.southworks.net/blogs/ejadib/archive/2007/03/30/WCSF_3A00_-Registering-services-through-configuration.aspx]

Ezequiel Jadib[url:http://staff.southworks.net/blogs/ejadib]

wrote Apr 7, 2007 at 4:52 PM

wrote Apr 9, 2007 at 7:48 PM

wrote Apr 10, 2007 at 7:22 AM

wrote Apr 25, 2007 at 9:17 PM

wrote Apr 28, 2007 at 4:28 PM

wrote May 25, 2007 at 10:23 AM

wrote May 30, 2007 at 10:09 PM

wrote Jun 7, 2007 at 12:00 AM

wrote Jun 19, 2007 at 11:49 PM

wrote Jun 24, 2007 at 8:10 PM

wrote Jul 1, 2007 at 10:56 AM

wrote Jul 28, 2007 at 11:36 AM

wrote Aug 2, 2007 at 11:22 PM

wrote Oct 2, 2007 at 3:04 AM

wrote Oct 3, 2007 at 5:50 PM

wrote Oct 4, 2007 at 4:24 AM

wrote Oct 4, 2007 at 8:46 PM

wrote Oct 10, 2007 at 9:58 PM

wrote Oct 11, 2007 at 9:11 PM

wrote Feb 22, 2013 at 12:03 AM

wrote May 16, 2013 at 11:43 AM