We use IUnitOfWorkCore extensively in our self servicing code, version 4.2.

The issue we come across is the AddCollectionForSave and AddCollectionForDelete methods are not implemented by IUnitOfWorkCore for some reason. We use the built in UnitOfWork class, so those methods are there - but not on the interface we use, so we cannot call them.

It seems like those should be part of the interface?

I could of course define "MyUnitOfWork" class that inherits from your UnitOfWork and create a new interface that had these methods. Rather not have to do that. Seems like it would make sense to put them in the core one, I am guessing there is some reason why? It looks like between SS and Adapter, you could have add to that interface methods that use IEntityCollectionCore.

yes, very good point! We'll look into adding these methods. Any other ones you're missing in this interface?

No, just those two. Thanks.

Can you make sure that IUnitOfWorkCore has the AddCallBack() method?

I am still on 4.2 ....about time to upgrade, so I cannot say that you do not already have those in the latest version, but if not can you add? (or let me know they are already there?)

Also in your new version has this improved? Perhaps when moving to .net core we can finally leave 3.5 in the dust and target 4.5.2 as a minimum and make this add callback a simple lambda and not even need the delegate generated, etc?

AddCallback isn't part of IUnitOfWorkCore: https://www.llblgen.com/Documentation/5.2/ReferenceManuals/LLBLGenProRTF/html/CC518F2D.htm

Also in your new version has this improved? Perhaps when moving to .net core we can finally leave 3.5 in the dust and target 4.5.2 as a minimum and make this add callback a simple lambda and not even need the delegate generated, etc?

What exactly do you mean with 'this' ? We added the methods you suggested in v5.2. The AddCallback has an overload in the adapter version of Unit of work specific for adapter, so we skipped it for now. The AddCallback method accept a Delegate, which can be a lambda, i.e. a=>Function(a) compiles to a Delegate

The Delegate generated you mean the one in the stored procedure class? These will stay though, we want to have no breaking changes moving forward, and removing those is a breaking change.

You use the callbacks on the Unit of work with stored proc calls mostly? (Just to get a picture of the use cases how the code is used )

• yes, I saw you added them to the interface in 5.2. I am hoping to get this in the interface of 5.x too, that way when I upgrade it will be there.

Also in your new version has this improved? Perhaps when moving to .net core we can finally leave 3.5 in the dust and target 4.5.2 as a minimum and make this add callback a simple lambda and not even need the delegate generated, etc?

I was meaning much of your code and overloads and such is due to not having compiler features (such as default parameters, async, lambda) and hoping we could make a clean break from all that stuff.

Yes, 100% stored procs. I am in a UOW and need to call a proc. The code looks like this:

uow.AddCallBack(new ActionProcedures.SomeStoredProcCallBack(ActionProcedures.SomeStoredProc), UnitOfWorkCallBackScheduleSlot.PostEntityDelete, someParam1, someParam2, someParam3);

If you were writing this today, the AddCallBack method would simply take Action<Transaction> parameter and usage would look like:

uow.AddCallBack(tran=>ActionProcedures.SomeStoredProc(someParam1, someParam2, someParam3, tran), UnitOfWorkCallBackScheduleSlot.PostEntityDelete);

Are you saying I can do this now? Does not seem like I can?

"No breaking changes" - this is a great idea of course. But let some of us move on! This is just extra code must people don't need. Perhaps different templates - people could use the old one or 'new updated template' options to generate code. Heck, all the code is generated - that is the great thing - one template change and everything is better - but now it is more like - don't change it someone might not use it. Even if you did this to me, I would know I could simply change my calls to this new method, etc. Dunno, just seems like I have gotten this same sort of answer from you many times "cannot because must maintain 3.5 compatibility so the template must be that way", etc. (all the code generated for serialization - do I actually need that - I don't send the entities out over the wire, etc) I am just brainstorming here for how we can move forward and have more flexibility with the shipping templates and take advantage of language features, etc.

WayneBrantley wrote:

• yes, I saw you added them to the interface in 5.2. I am hoping to get this in the interface of 5.x too, that way when I upgrade it will be there.

The interface is used among adapter and selfservicing, this method has a specific overload for adapter and selfservicing: the signature is the same (a bool parameter), but for adapter it means 'pass in adapter' for selfservicing it means 'pass in transaction'. So for the interface method, the boolean means a different thing so this is problematic and the reason why we didn't add it to v5.2. I'll see what I can do for you, but no promises.

Also in your new version has this improved? Perhaps when moving to .net core we can finally leave 3.5 in the dust and target 4.5.2 as a minimum and make this add callback a simple lambda and not even need the delegate generated, etc?

I was meaning much of your code and overloads and such is due to not having compiler features (such as default parameters, async, lambda) and hoping we could make a clean break from all that stuff.

Yes, 100% stored procs. I am in a UOW and need to call a proc. The code looks like this:

uow.AddCallBack(new ActionProcedures.SomeStoredProcCallBack(ActionProcedures.SomeStoredProc), UnitOfWorkCallBackScheduleSlot.PostEntityDelete, someParam1, someParam2, someParam3);

If you were writing this today, the AddCallBack method would simply take Action<Transaction> parameter and usage would look like:

uow.AddCallBack(tran=>ActionProcedures.SomeStoredProc(someParam1, someParam2, someParam3, tran), UnitOfWorkCallBackScheduleSlot.PostEntityDelete);

Are you saying I can do this now? Does not seem like I can?

To my knowledge that should work, but haven't tried it in practice. It sees no parameters, so it will be the same and will construct the dynamic invoke with 1 parameter, transaction, as the 'tran=>method(a, b, c, tran)' will be seen as a Delegate with 1 argument (a, b and c are inlined).

"No breaking changes" - this is a great idea of course. But let some of us move on! This is just extra code must people don't need. Perhaps different templates - people could use the old one or 'new updated template' options to generate code. Heck, all the code is generated - that is the great thing - one template change and everything is better - but now it is more like - don't change it someone might not use it. Even if you did this to me, I would know I could simply change my calls to this new method, etc. Dunno, just seems like I have gotten this same sort of answer from you many times "cannot because must maintain 3.5 compatibility so the template must be that way", etc. (all the code generated for serialization - do I actually need that - I don't send the entities out over the wire, etc) I am just brainstorming here for how we can move forward and have more flexibility with the shipping templates and take advantage of language features, etc.

The recent asp.net core mess where they declared to move to .netcore only has showed once again that backwards compatibility is a feature. We'll drop v3.5 in the next version, as microsoft has done so too, but dropping code is not going to happen.

We can fragmentize the codebase and let you cherry pick the features you want. On paper this sounds great, but in practice it comes down to the small fragments the .net core BCL was cut into: you never have the dll you need, you always have to go look for the thing that supports what you want. With cherrypicked features it's the same: say you pick only 50%, and you run into something that is in the 50% you cut. Which feature to enable? You have to look at all of them. So we likely won't go there.

It's also for a gain that's nice on paper but has no real value in practice: the .NET runtime is massive, they don't cut out features because 'modern' development says you should do things in a new awkward way and you won't notice either. Code generated is there if you need it. Sure it takes some miliseconds extra to compile perhaps, but it's not noticeable.

Btw, we do cut code if we can make things smaller in code. But we have other constraints too: to use C#6, the user has to have vs2015. If we add C#6 code to a template, we are forcing people to use 2015 or later. Even MS gets flak for their move to support 2017 onwards, what do you think the flak we'll get when we abandon our users that way?

Look, I'm all for cutting out the cruft we once added and which is long forgotten by many, but we simply can't do that as there's always a group of people depending on that, and unless there's an alternative (so we can pick that) or make it optional (like we've done with some templates in the past for e.g. webservices/validators etc.) in a simple way, we can't. It's not hurting anyone either if there's e.g. binary serialization code in an entity class. When it does, we'll look at it, till then, it likely will stay there, even if it isn't useful for many (and trust me, I'd be the first to cut it)

All your points are understood.

Why not add this to the interface:

    AddCallBack(Action<ITransaction> method, UnitOfWorkCallBackScheduleSlot slot);

Then there is no bool parameter, no nothing. The lamba can use the the transaction or not.?

I think that's not going to work, as adapter doesn't implement ITransaction, but we'll think of something

Great. (Maybe a whole new way to put stored procs into the UOW? Maybe some additional gen'ed code or something.)

Thanks for looking into. I gotta upgrade! Gotta just do it...

These two interfaces are also needed on IUnitOfWorkCore. (Seems like I already asked for this, but cant find the thread).

    void AddDeleteMultiCall(IEntityCollection collection, IPredicate filter, IRelationCollection relations = null);
    void AddUpdateMultiCall(IEntityCollection collection, IEntity entityWithNewValues, IPredicate filter,IRelationCollection relations = null);

Would it be possible to add these too?

Hi Wayne.

Please elaborate more on the arguments for this. Why would you want to add those two methods to the interface?

WayneBrantley wrote:

These two interfaces are also needed on IUnitOfWorkCore. (Seems like I already asked for this, but cant find the thread).

    void AddDeleteMultiCall(IEntityCollection collection, IPredicate filter, IRelationCollection relations = null);
    void AddUpdateMultiCall(IEntityCollection collection, IEntity entityWithNewValues, IPredicate filter,IRelationCollection relations = null);

Would it be possible to add these too?

The thread you're referring to is this thread. These are selfservicing specific methods, so they won't be added to the interface.

What I find a little odd is why you use the interface anyway, as you're using selfservicing, just use the methods on UnitOfWork, it's not as if your code is shareable among adapter code anyway. The interface is meant for defining functionality which is shared among selfservicing and adapter on the unit of work, as they don't have a shared base class.

I use the interface in my cqrs solution which provides UOW decorator. This uses the interface and DI provides the actual implementation.

I added this on my interface since it cannot be on the IUnitOfWorkCore