JasperFx / lamar

Fast Inversion of Control Tool and Successor to StructureMap
https://jasperfx.github.io/lamar
MIT License
566 stars 117 forks source link

Missing API for setting lifecycle when scanning assemblies #200

Closed chaghi closed 4 years ago

chaghi commented 4 years ago

I'm migrating some projects from StructureMap to Lamar, and although the migration has been mostly transparent, I really miss some API to specify the lifecycle of the services when scanning an assembly.

StructureMap's OnAddedPluginTypes was not carried over to Lamar, and it seems there's no equivalent for these use cases:

            services.Scan(x =>
            {
                x.Assembly("Foo.Bar");
                x.ConnectImplementationsToTypesClosing(typeof(IGenericInterface<>))
                    .OnAddedPluginTypes(v => v.Singleton());
            });

            services.Scan(x =>
            {
                x.Assembly("Spam.Eggs");
                x.WithDefaultConventions();
                    .OnAddedPluginTypes(t => t.Singleton());
            });

For the time being I solved the issue with a couple of custom conventions. Basically I ripped off GenericConnectionScanner and DefaultConventionScanner, and changed them so they add singletons.

What's the official take on this? Will you accept a PR that modifies said scanners/conventions (and potentially others? Those are the ones I'm currently using, but I'm not that familiar with StructureMap and/or Lamar beyond the basics) to optionally accept a lifecycle? And chagning the extension methods so they can accept an optional lifecycle to pass to the convention?

Something around these lines:

            services.Scan(x =>
            {
                x.Assembly("Foo.Bar");
                x.ConnectImplementationsToTypesClosing(typeof(IGenericInterface<>), ServiceLifetime.Singleton);
            });

            services.Scan(x =>
            {
                x.Assembly("Spam.Eggs");
                x.WithDefaultConventions(ServiceLifetime.Singleton);
            });

So, to sum up, I guess the issue is two folded:

  1. Is currently any built-in alternative to set the lifecycle when scanning an assembly that I'm not seeing?
  2. If there isn't, does it make sense to have one? What do you think of my proposed solution? Would you accept a contribution on that direction?
jeremydmiller commented 4 years ago

I'd happily take a pull request for that. You can use attributes too, with the obvious downsides. I'm completely fine with enhancing the existing registration conventions