Setting AllowNew/Edit/Remove in constructor for CSLA 6 Collection object

[mtavares628]

In prior versions of CSLA I was able to set the AllowNew, AllowEdit and AllowRemove properties in a collection object within the constructor based on calls to HasPermission. So for example I had code like this:

        public MyCollection()
        {
            var rlce = RaiseListChangedEvents;
            RaiseListChangedEvents = false;
            AllowNew = BusinessRules.HasPermission(Csla.Rules.AuthorizationActions.CreateObject, typeof(MyCollection));
            AllowEdit = BusinessRules.HasPermission(Csla.Rules.AuthorizationActions.EditObject, typeof(MyCollection));
            AllowRemove = BusinessRules.HasPermission(Csla.Rules.AuthorizationActions.DeleteObject, typeof(MyCollection));
            RaiseListChangedEvents = rlce;
        }

However, for CSLA 6 the HasPermission method requires the ApplicationContext, and the ApplicationContext doesn't exist in the constructor (unless I'm doing something wrong). So is the work around for this that I now have to set these properties in the Create and Fetch DataPortal methods? Or is it possible to inject the ApplicationContext into the constructor?

[rockfordlhotka]

Requiring a constructor to inject application context would have been a massive breaking change to all business classes in every existing codebase, and so I chose not to go down that path. Instead, I added the IUseApplicationContext interface, which is used when CSLA creates instances of your domain types.

I did consider trying to check for alternate constructors, but given that lots of instances are created, I didn't want to add that use of reflection into the create instance process. Not that I did any perf testing, so perhaps that choice was premature optimization.

In other words, maybe we could enhance the create instance process to first check for a ctor with parameters, and in that case use DI to inject into the ctor, and if not, then check for IUseApplicationContext. That would take some thought, testing, etc. as it obviously impacts existing code and has risk.

Another option may be to make the implementation of IUseApplicationContext virtual in the base classes, so you could override and thus know and take action as ApplicationContext is set.

The only think I can think of for both these options is that there's some complexity with LocalProxy in the data portal, where domain objects' ApplicationContext values are "fixed up" as the object graph flows from the logical server back to the logical client, which current spams IUseApplicationContext to reset all the references in the graph. We don't re-create the instances, we just change out the context references.

[mtavares628]

Both options sound tricky to implement, but from a consumer's perspective I like the first option better, since it would mean keeping similar code in the constructor to what is there now.

In the meantime to get by, I will just set those properties in the Create and Fetch methods.

[TheCakeMonster]

@mtavares628 This might be overcomplicating things, but I think you could write the code you showed generically. If you do this in a lot of classes, I think you could create a generic base class into which to add a method that contains that code, and call it from the data access methds in the classes that inherit from your base class.

That might reduce the total amount of code you have a bit. However, it might be at the expense of how explicitly and obvious it is that your rules are being applied.

public class AuthorisingCollectionBase<TList, TChild> : BusinessListBase<TList, TChild>
{
	protected ApplyCollectionAuthorisationRules()
	{
		var rlce = RaiseListChangedEvents;
		RaiseListChangedEvents = false;
		AllowNew = BusinessRules.HasPermission(Csla.Rules.AuthorizationActions.CreateObject, typeof(TList));
		AllowEdit = BusinessRules.HasPermission(Csla.Rules.AuthorizationActions.EditObject, typeof(TList));
		AllowRemove = BusinessRules.HasPermission(Csla.Rules.AuthorizationActions.DeleteObject, typeof(TList));
		RaiseListChangedEvents = rlce;
	}
}

I've mocked this up in the browser so there might be compilation issues with this exact syntax.

[mtavares628]

Thanks for the suggestion @TheCakeMonster. This code is actually being generated by the CslaGenFork templates, and based on some settings on the BO, what it generates may be different, so I can't change it across the board for all BOs. But what you suggest would be a lot cleaner if I wasn't using it.