Application Context Null on new

[kcabral817]

I been reading the threads on the application context null issue, #3201 that deals with grids and I believe applies to Automapper when mapping the graph. I think Automapper creates an object but doesn't use "_app.CreateInstanceDI" as it resolves the graph. It then tries to start loading the values, but this will throw a Null Reference Exception as this.ApplicationContext will be null for that class. For business objects that implement IUseApplicationContext, and are created out of band, where do I get the application context?

Factory Method that invokes Automapper

private EmployeeInfoPersist MapItem(EmployeeInformation info)
        {
            var obj = _app.CreateInstanceDI<EmployeeInfoPersist>();    <-- has lists

            using (BypassPropertyChecks(obj))
            { 
                _mapContainer.Map(info, obj);   <-- throws a null reference exception on loading of property
            }
       }

Parent that contains a list.

public class EmployeeInfoPersist : BusinessBase<EmployeeInfoPersist>, IUseApplicationContext  <--has constituted object
    {
        public EmployeeInfoPersist()
        {
            MarkOld();  
        }

[NotUndoable, NonSerialized]
        public static readonly PropertyInfo<EmployeeCertificationInfoListPersist> EmployeeCertificationListProperty = RegisterProperty<EmployeeCertificationInfoListPersist>(p => p.EmployeeCertifications);
        public EmployeeCertificationInfoListPersist EmployeeCertifications
        {
            get => GetProperty(EmployeeCertificationListProperty);
            set => SetProperty(EmployeeCertificationListProperty, value);
        }

Child base class that will have the application null.

public class EmployeeCertificationInfoPersist : BusinessBase<EmployeeCertificationInfoPersist>, IUseApplicationContext _<<---null
   { 
       public EmployeeCertificationInfoPersist()
       {
           MarkAsChild();
           MarkOld();  
       }

Typically, I would solve this by injecting the ApplicationContext into the CTOR, but that idea is DOA on the EmployeeCertificationInfoPersist business object.

So I'm seeing a consistent set of invocations by third parties that do not call _app.CreateInstanceDI<ClassToInstantiate>(); and cause null references on the properties.

How do I fix null applicationContext issue on the business object?

[rockfordlhotka]

I don't know that there is an easy answer.

The domain objects need a reference to ApplicationContext. Requiring that all domain types be registered as a service and also requiring that they all implement a constructor to get that value would have broken literally every business class in every app for everyone who uses CSLA - that scope of breaking change seemed (and still seems) intolerable to me. Just think of the cost to update every class!

Instead, I chose to use an IUseApplicationContext interface, and inside CSLA all business classes are instantiated using a method that does:

1. Create the instance using DI
2. If the instance implements IUseApplicationContext then set the ApplicationContext value

This avoided breaking all existing code in all apps everywhere.

It does mean that creating domain objects by external means (like grids, automapper, etc.) won't work. The thing is, even if I had chosen to break everyone's existing code, it still wouldn't work because most of these other things (like grid controls) won't be using DI to create instances anyway.

The only thing that might work with automapper, would be that you could walk the graph after it is created and set ApplicationContext. In fact, I'm not even sure you'd need to do that - there's code in CSLA that resets the ApplicationContext in a graph when a graph is moved from one context (DI scope) to another, and iirc, we optimized that so really only the root object needs to have the right value (I think?).

[saulyt]

I was just wondering if another solution would be to use AutoMappers ConstructUsing <https://docs.automapper.org/en/stable/Queryable-Extensions.html?highlight=ConstructUsing#custom-destination-type-constructors> feature. Basically inject ApplicationContext into your AutoMap Profile class where you are setting up your mappings. Then use ConstructUsing to tell it to use appContext.CreateInstanceDI to construct your BO. Haven't tried it, just a thought.

…

On Fri, Dec 16, 2022 at 5:22 AM Kevin Cabral ***@***.***> wrote: I been reading the threads on the application context null issue, #3201 <#3201> that deals with grids and I believe applies to Automapper when mapping the graph. I think Automapper creates an object but doesn't use "_app.CreateInstanceDI" as it resolves the graph. It then tries to start loading the values, but this will throw a Null Reference Exception as this.ApplicationContext will be null for that class. For business objects that implement IUseApplicationContext, and are created out of band, where do I get the application context? Factory Method that invokes Automapper private EmployeeInfoPersist MapItem(EmployeeInformation info) { var obj = _app.CreateInstanceDI<EmployeeInfoPersist>(); <-- has lists using (BypassPropertyChecks(obj)) { _mapContainer.Map(info, obj); <-- throws a null reference exception on loading of property } } Parent that contains a list. public class EmployeeInfoPersist : BusinessBase<EmployeeInfoPersist>, IUseApplicationContext <--has constituted object { public EmployeeInfoPersist() { MarkOld(); } [NotUndoable, NonSerialized] public static readonly PropertyInfo<EmployeeCertificationInfoListPersist> EmployeeCertificationListProperty = RegisterProperty<EmployeeCertificationInfoListPersist>(p => p.EmployeeCertifications); public EmployeeCertificationInfoListPersist EmployeeCertifications { get => GetProperty(EmployeeCertificationListProperty); set => SetProperty(EmployeeCertificationListProperty, value); } Child base class that will have the application null. public class EmployeeCertificationInfoPersist : BusinessBase<EmployeeCertificationInfoPersist>, IUseApplicationContext _<<---null { public EmployeeCertificationInfoPersist() { MarkAsChild(); MarkOld(); //do this to ensure database recorded items are not new and rules do not fire for old objects. Set new in create method. } Typically, I would solve this by injecting the ApplicationContext into the CTOR, but that idea is DOA on the EmployeeCertificationInfoPersist business object. So I'm seeing a consistent set of invocations by third parties that do not call _app.CreateInstanceDI<ClassToInstantiate>(); and cause null references on the properties. How do I fix null applicationContext issue on the business object? — Reply to this email directly, view it on GitHub <#3233>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJLAXO7QSVHLPH42B3HYWXLWNQ7ETANCNFSM6AAAAAATAXLUXI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[kcabral817]

All righty folks, let us gather around the fire and tell the story:

With the help of Rocky and Saulyt that led me to the path of discovery, here is how to solve the Automapper child mapping problem:

First:
In the Automapper profile, create a parameter constructor with ApplicationContext.

public EmployeeLibraryProfile(ApplicationContext ApplicationContext)
 {
            _app = ApplicationContext;
 
            CreateMap<Certification, CertificationInfoPersist>()
                   .ForMember(dest => dest.BrokenRulesCollection, o => o.Ignore())
                   .ReverseMap();
     .
     .
     .
}

Second:
On the CreateMap method, append .ConstructUsing(src => _app.CreateInstanceDI()). for example:

 CreateMap<Certification, CertificationInfoPersist>().ConstructUsing(src => _app.CreateInstanceDI<CertificationInfoPersist>())
                   .ForMember(dest => dest.BrokenRulesCollection, o => o.Ignore())
                   .ReverseMap();

Third:
In the Main, add a singleton with the name of the profile class that was used above:

services.AddSingleton(provider => new MapperConfiguration(cfg =>
            {
                cfg.AddProfile(new EmployeeLibraryProfile(provider.CreateScope().ServiceProvider.GetService<ApplicationContext>()));
            }).CreateMapper());

Finally, put fire in the hole and let this baby rock and roll!

[Chicagoan2016]

@kcabral817 out of curiosity, why did you choose AutoMapper?
We have used DataMapper (built-in Csla) and it has worked pretty good. If I recall it doesn't set read-only properties and you could also ask it to 'ignore' certain properties.
We used it to copy values between Csla business objects and DTOs.

[kcabral817]

Before I was led to CSLA, I had Automapper mapping DTOs. Also, I think it's good to be able to demonstrate the versatility of CSLA to others.

[Chicagoan2016]

Also, I think it's good to be able to demonstrate the versatility of CSLA to others.

That's what I am talking about 😊