Combining business logic for plugins and net8 project

[KimBon]

Hi

Wondering whether it is possible to develop a joint business logic layer that can be consumed by plugins on net framework 462 and .net8 .

I have been looking to former threads, but Im not sure if I understand well and if they are still relevant:
#15

In a simple setup, there would be business layer consisting of:

• service classes doing the orchestration
• models that are not the early bound ones
  This layer would be .net standard 2 so that they can be shared.

Plugins or the web app have to make sure they fetch the data and update the output.
Plugins will do that either via organization service or the plugincontext.targetentity (pre operation).
The web app will do that with the new dataverse client.

Downside of this is that both will have very similar logic for their data access logic.

Based on this idea, I would like to validate some assumptions:

• is it a good idea to have a .net standard 2 library used by the plugins project? also future-wise?
• can early bound classes be shared in some way or its not a good idea to reuse them in business layer
• early bound classes cannot be used by the business layer since they are based on Microsoft.Xrm.Sdk.Client which lives in two projects (dataverse and plugin sdk)?
• a client/service cannot be injected to further limit the similar logic in fetching input and handling the output?
• for use of the dataverse client in .NET8 what is the right way for dependency injection and related lifetime? Does this differ if this would be a background worker reading a service bus?

Are there any alternatives to this approach?
What is on the roadmap in bringing some clarity for this topic?
What is the way forward looking at further support in the future?

cc @MattB-msft @JimDaly

[MattB-msft]

@KimBon Thanks for a concise write up of your askes :)

Short answer is "yes" this is possible, and we have designed the system to support this type of development.
A few things to consider when developing applications like this:

It's not necessary to target .net standard for any of this. .net framework is fully backward compatible, targeting .net 4.6.2 will create libs that are usable on .net 4.6.2 and .net 4.8.

You can use Earlybound classes in both plugins and clients.

Your common 'shared' code should aways use IOrganizationService for access to Dataverse itself, the client and server clients are derived from that.
note: you cannot use the IOrgaizationServiceAsync interfaces as they are not implemented on the server.  

[KimBon]

@MattB-msft thanks for your feedback

You mean that the shared lib can use .net framework 4.6.2, so can work in plugins and can be used in .net 8 since .net 8 is backward compatible and supports net462 libs? Should the project have multiple target frameworks (TFM)?
This also means that this business logic is not developed with the C# lang matching Net8 version and has to be reviewed once plugin framework in platform would move there?

I now tested with a .NET Standard 2 library, using an IsExternalInit class to force for c# 11 (similar to this stackoverflow thread) Not sure this is a good idea and supported by MS for plugins. I can share a Poc with you if useful

If the shared code were to use IOrganizationService, can the service be a singleton in the .net 8 app? Or should it be cloned for each request scope?

If used in plugins, supporting IOrganizationSerivce alone would not suffice, as the plugin can use the target or pre/post images too?:

• the shared library does not do any data access
• the shared library uses some kind of data/repository interface, that is implemented per technology: either iorganizationservice or iexecutioncontext. That would make this setup even more complex though.

[MattB-msft]

Targeting .net 462 for your shared libraries will provide maximum compatibility.
IOrganizationService and the underlying Microsoft.Xrm.Sdk.dll do not ship .net standard targets, so you will not be able to use them in a .net standard lib.

.net 462 compiled code will work properly in .net 48, Lang version is a separate from framework version and has to do with which version of the dotnet SDK you're using to do compilation. see: https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/configure-language-version

.net standard in general has been set aside in favor of newer concepts in .net 5+ .. you can read more on that here: https://learn.microsoft.com/en-us/dotnet/standard/net-standard?tabs=net-standard-1-0

Were it me, (and this is my opinion only) I would not mess with .net standard and just multi-target if needed.

In Plugins, IOrganizationService is what you get from the OrganizationServiceFactory type:

            OrgSvcFactory = (IOrganizationServiceFactory)serviceProvider.GetService(typeof(IOrganizationServiceFactory));
            CurrentUserService = OrgSvcFactory.CreateOrganizationService(PluginExecutionContext.UserId);

In this case 'CurrentUserService' is an IOrganizationService.

Both Pre and Post images return 'Entity' types.
You can choose to cast them to Strong types using the .ToEntity() extension on entities if you wish.

Your shared library should accept an Ilogger for logging, and if you wanted to do data ops from within it, accept an IOrganizationService.

MattB

[jordimontana82]

@KimBon, alternatively you can put the common bits in a Shared Project / Source Nuget Package / Git Submodule, and then reference them from two different projects (net462 in plugins, and net 8 in client applications), like I'm doing in this repo:

https://github.com/DynamicsValue/fake-xrm-easy-samples

[KimBon]

@jordimontana82 I was indeed looking at shared project amongst other.
In your sample, I see you are sharing the early bound entities, which rely on the same namespace.

Injecting an interface like IOrganizationService would be similar probably. However, If I am injecting an interface like ILogger - which is different namespace in both cilents - I dont see how that could work further unless I make abstraction of these?
IOrganizationServiceProxy also seems not to be used by newer dataverse client, but would be needed to use early bound?

[MattB-msft]

The problem with ILogger is an unfortunate byproduct of a decision made several years ago (6?) and has reached the point where we cannot change that on the server without breaking a ridicules number of customers's codebases.

The Ilogger implementation in Microsoft.Xrm.Sdk is intended to work for the server itself and has many additional features over normal Ilogger. Unfortunately, its not inherited from Ilogger so you cannot cast it. the best way to deal with it in shared code Aliasing the type

@KimBon .net8 should be able to accept .net4.8 modules as this support was added to .net in the .net 6.0 time line as part of the deprecation of the .net standard work. Give it a try.

[FarmerenHE]

The goal would actually be to reuse the business logic in a .NET 8 LTS project, not a .NET framework 4.8.

We have taken a different approach to plugins as to avoid this as much as possible.

We only have in plugins what absolutly must run inside the plugin transaction (thus synchronized), for everything else we use the servicebus trigger, instead of a plugin trigger, that puts data onto a servicebus and we can then catch it from an azure function and do all the processing there.

It does cost a few more API calls but in our experience its just as fast as an async plugin and is way easier to develop, debug, maintain and performancescale.

[KimBon]

@FarmerenHE That is an interesting approach as well, but it does indeed cost a bit of overhead certainly in simple operations that do not take long to run.

I will be looking into the ILogger abstraction because that seems to be a blocker for now. Next to that will see if shared project or submodules would be sufficient and have a look at target multi framework.