Register as Scoped or Transient for Csla 6 object factories?

[swegele]

Maybe this is a dumb question, but I find myself wondering how y'all will be registering your factory classes in Csla 6 (the factories that allow us to get rid of static constructors in business objects). Would you register this factory as scoped or transient?

public class AlphaInfoFactory : MyReadOnlyBaseFactory<AlphaInfo>
{
    public AlphaInfoFactory(IDataPortalFactory portal, ApplicationContext applicationContext)
        : base(portal, applicationContext)
    {
    }

    public AlphaInfo GetById(Guid id)
    {
        return Portal.Fetch(id);
    }
}

and it's base class for reference

public abstract class MyReadOnlyBaseFactory<T> : IBusinessObjectFactory
    where T : MyReadOnlyBase<T>, new()
{
    public readonly IDataPortal<T> Portal;

    public readonly ApplicationContext ApplicationContext;

    protected MyReadOnlyBaseFactory(IDataPortalFactory portalFactory, ApplicationContext applicationContext)
    {
        Portal = portalFactory.GetPortal<T>();
        ApplicationContext = applicationContext;
    }

   ...
}

[TheCakeMonster]

Can I answer it depends, and leave it at that? 😉

I think I'd go with Transient in almost all scenarios. There is a theoretical risk with Scoped that there could be some form of multithreaded access and that might not be guaranteed to work (although in practice both the chance of multithreaded access, and the chance of a bug are both very small in most scenarios.)

I don't really see much of a benefit to using Scoped, so I probably wouldn't. The only benefit there might be in using Scoped is less work for the garbage collector, so that's the "it depends" bit. If you already know that garbage collection will cause you an issue, then Scoped might help alleviate that in certain circumstances.

In reality, what seems to give the garbage collector more of a problem is long-lived instances of reference types. The longer an item exists on the heap, the larger the generation number it gets assigned, and as I understand it, Gen 2 collection is very expensive. Using a lifetime of Scoped is likely to result in instances existing for longer, so you'd have to do a test of your particular scenario to work out if there really is a benefit to Scoped and not just go on an assumption.

So, Transient. Almost always (but not quite always.)

[swegele]

For the last month in my Csla 6 POC, I've been registering them as scoped. Yesterday I thought "Hmm what if that is not right?!" and asked for help. Now I think I agree with your assessment that the GC won't be an issue. This makes me think I should probably also adjust the base factory class to create new transient Portal instances too:

public abstract class MyReadOnlyBaseFactory<T> : IBusinessObjectFactory
    where T : MyReadOnlyBase<T>, new()
{
    private readonly IDataPortalFactory PortalFactory;
    public IDataPortal<T> Portal { get { return portalFactory.GetPortal<T>(); }}

    public readonly ApplicationContext ApplicationContext;

    protected MyReadOnlyBaseFactory(IDataPortalFactory portalFactory, ApplicationContext applicationContext)
    {
        PortalFactory = portalFactory;
        ApplicationContext = applicationContext;
    }

   ...
}

[richardbartley]

I'm facing something on this topic too - ASPNetCore web api and having to use AddTransient on repositories seems only way to get it to work (although we sometimes see ObjectDisposedExceptions firing in our async rules - despite awaiting everything I can see everywhere) because we have business objects with lots of async rules on them using EF underneath and of course EF DbContext is not thread safe. AddScoped just didn't work for us - _"DbContext is not thread-safe. Do not share contexts between threads. Make sure to await all async calls before continuing to use the context instance. An InvalidOperationException thrown by EF Core code can put the context into an unrecoverable stateunless I'm doing something wrong.

Is it possible to get AddScoped working, with async business rules all playing nicely together in an ASPNetCore web api setup? Or is it more that AddTransient is the path to follow?

[rockfordlhotka]

In CSLA 7 we did address this by ensuring that (by default) every root data portal call creates a DI scope that exists for the duration of that root data portal call. This means that, in data portal operation methods (logical server-side), you should be able to use a scoped service.

This is because, by default, every root data portal operation runs on a single thread and also that scope only exists for the duration of that root operation. All child data portal usage called by that root will run in that same scope.