XML Configuration and References

[Husain Alshehhi]

The website says: 

Note! The StructureMap team strongly feels that Xml configuration is both undesirable and unnecessary. Please feel free to use the Google user group to ask for advice on how to move away from Xml configuration in existing applications.

My first question is: 

Why is XML not desirable? I find it to be a good option. Consider the case when you can change the class to use in the registry without recompiling the code. How would I do that if I don't have XML configuration. If I hard code the classes in the registry file, then I cannot swap classes without recompiling.

My second question is:

I worked around the XML configuration issue by adding custom configuration in my web.config for the assemblies. I also have a separate Container project that references the interfaces project and the concrete type projects. My Service project references teh Container projects because it needs to resolve some types. Why does the service has to know about the projects in which the concrete types reside?

[Jeremy Miller]

@Husain,

The first thing to keep in mind is that Xml configuration is not the only way to achieve any of your goals here.

The Xml configuration was extremely error prone, especially compared to the strongly typed registration DSL or using type scanning registrations (what most users lean on now) and caused me a *lot* of work in user support.

"I also have a separate Container project that references the interfaces project and the concrete type projects." -- Okay. I personally don't think that this kind of assembly reference is actually a problem, but if you still insist on it you can have StructureMap discover Registry classes in assemblies scanned from the file system. That's how users are handling that today. It's more complexity and very easily confusing for new devs, but you've got the ability to do that.

"Consider the case when you can change the class to use in the registry without recompiling the code."

I've heard that argument off and on for years and it's just not compelling to me. I would NEVER deploy changes that impact behavior like IoC configuration changes without running our automated build anyway. If it's purely configuration items like connection strings, you can still happily read that information inside of a Registry class or new Container().

- Jeremy

[Andrew Stanton]

I think one of the things that I've found useful about no-recompilation-needed container systems is that they can also be used as a simple plugin manager. 

I'm not saying XML is great, but if I have a customer that uses my Program X, and they want to use Module B+ instead of Module B with it, I'd rather be able to give them a dll with the ModuleB function in it and an update to the config file to use ModuleB when the program requests an IModule. 

Sure there are other ways to do plugins and such, but having to recompile Program X just to swap out a single interface implementation run afoul of both common sense and the point of using interfaces.

[Steve Smith]

Can't you accomplish this without the file by just having a plugins folder you scan, and either overwrite updated assemblies or use a convention to load the latest one?

--
You received this message because you are subscribed to the Google Groups "structuremap-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to structuremap-us...@googlegroups.com.
To post to this group, send email to structure...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/structuremap-users/809b42af-1d1d-42f0-8eaa-8de862107601%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Steve Smith
http://Ardalis.com/
http://twitter.com/ardalis

[Adel Lahlou]

@Jeremy

I definitely understand that enforcing in-code registry and compilation provides compile-time checks and Intellisense which helps prevent user errors. However, the ability to use Xml Configurations or non-recompiling class configurations are useful in clusters with thousands of nodes. Configuration deployments are much faster than code deployments, unfortunately one or two orders of magnitude faster. While rolling deployment mitigates short-term errors that occur after deployment, configuration can be effectively used to mitigate medium term errors that manifest after the deployment window. Retroversioning the bits is an option (the most common you'll see in PaaS),  but again much slower since it might kick off another rolling deployment (depending on fallback configuration). It's a use case that might not be common, but it's the one I've found that enables incredibly quick mitigation.

[Jeremy Miller]

So first, see this: https://jeremydmiller.com/2018/01/29/sunsetting-structuremap/

The StructureMap Registry is just a C# class. Regardless of whether or not SM comes with some kind of Xml configuration out of the box, there’s nothing stopping you from writing code within a Registry class that reads registrations from an external xml file.

- Jeremy

--
You received this message because you are subscribed to the Google Groups "structuremap-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to structuremap-us...@googlegroups.com.
To post to this group, send email to structure...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/structuremap-users/b31aa6a8-c54a-4498-a4d9-dba8cd425d29%40googlegroups.com.