Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Package segregation #48

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Package segregation #48

wants to merge 3 commits into from

Conversation

flespi
Copy link

@flespi flespi commented Jan 31, 2023

This segregation of packages makes it easier to integrate Core functionality using technologies other than AspNet.

@unaizorrilla
Copy link
Collaborator

Can you explain a use case for this with more details?

@flespi
Copy link
Author

flespi commented Feb 2, 2023

The idea behind this improvement is to reduce coupling with web dependencies, to keep core capabilities and abstractions implementation-agnostic.

Think about ClaimsPrincipal class (or System.Security.Claims assembly). There are not many cases where you need to use it outside the context of an ASP.NET application. However, it was designed to have low coupling with web implementations.

Many packages adopt the practice of separating ASP.NET interoperability from the core.
Finbuckle is a good example of that. They created these well-defined scopes:

  • Finbuckle.MultiTenant (Core)
  • Finbuckle.MultiTenant.AspNetCore (ASP.NET integration)
  • Finbuckle.MultiTenant.EntityFrameworkCore (EF store)

Some time ago, I was using Finbuckle and had to get the tenant info within the scope of a MassTransit event. It was as easy as defining and injecting a new provider.

Also, (and this might be the most important point) this ensures that store packages interact only with the abstractions that make sense to them, and avoids inappropriate interactions with ASP.NET context.

In addition, think that you want to get authorization information from the application layer. Nowadays, a reference to Balea implies knowing all the dependencies and assemblies related to ASP.NET because it contains a framework reference.

<ItemGroup>
    <FrameworkReference Include="Microsoft.AspNetCore.App" />
    ...
</ItemGroup>

@flespi
Copy link
Author

flespi commented Feb 2, 2023

In my opinion, the only thing that Balea lacks to be considered the definitive solution for authorization is to facilitate the management of definitions (permissions, roles, etc).

It can be achieved by defining pluggable dependencies (similar to the UserManager / UserStore abstractions of Microsoft.AspNetCore.Identity), which allow CRUD operations on Balea entities.

The stores that exist today are more like grantors.

This enhancement could be a small first step towards that goal.

I have made some progress on this idea. Although at the moment it is just a draft. You can find it in the branch stores.

How it is How it can be
before after

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants