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)