search

elsa-workflows / elsa-core

A .NET workflows library
https://v3.elsaworkflows.io/
MIT License
6.11k stars 1.11k forks source link

[CHORE] Modules depend on each other #5534

Open XuJin186 opened 1 month ago

XuJin186 commented 1 month ago

Maintenance Task Request

Task Overview

Interdependencies between multiple modules result in unnecessary introductions

Purpose of the Task

For example, I only need the runtime module, but I need persistence, I will introduce the EF CORE module to achieve, but found that the EF CORE module is not only the entity of the runtime, there are many non-Runtime

Potential Issues

Identify any potential issues that might arise from this task Discuss any challenges or potential disruptions that could occur as a result of this maintenance task. This will help prepare for and mitigate any negative impacts.

Suggestion

Separate ef core dependencies and create one for each module that has an entity

sfmskywalker commented 1 month ago

Hi @XuJin186,

I understand your point about separating EF Core providers into distinct modules for Workflow Runtime, Management, Identity, etc. While this would provide a cleaner separation of concerns, it also introduces practical issues, particularly the significant increase in the number of packages (e.g., 20 additional packages for various database providers).

Here is a table with the package names for each module and provider combination:

Module MySql SQLite SQLServer PostgreSQL
Alterations Elsa.Alterations.Persistence.EntityFrameworkCore.MySql Elsa.Alterations.Persistence.EntityFrameworkCore.Sqlite Elsa.Alterations.Persistence.EntityFrameworkCore.SqlServer Elsa.Alterations.Persistence.EntityFrameworkCore.PostgreSql
Management Elsa.Management.Persistence.EntityFrameworkCore.MySql Elsa.Management.Persistence.EntityFrameworkCore.Sqlite Elsa.Management.Persistence.EntityFrameworkCore.SqlServer Elsa.Management.Persistence.EntityFrameworkCore.PostgreSql
Runtime Elsa.Runtime.Persistence.EntityFrameworkCore.MySql Elsa.Runtime.Persistence.EntityFrameworkCore.Sqlite Elsa.Runtime.Persistence.EntityFrameworkCore.SqlServer Elsa.Runtime.Persistence.EntityFrameworkCore.PostgreSql
Identity Elsa.Identity.Persistence.EntityFrameworkCore.MySql Elsa.Identity.Persistence.EntityFrameworkCore.Sqlite Elsa.Identity.Persistence.EntityFrameworkCore.SqlServer Elsa.Identity.Persistence.EntityFrameworkCore.PostgreSql
Labels Elsa.Labels.Persistence.EntityFrameworkCore.MySql Elsa.Labels.Persistence.EntityFrameworkCore.Sqlite Elsa.Labels.Persistence.EntityFrameworkCore.SqlServer Elsa.Labels.Persistence.EntityFrameworkCore.PostgreSql

Which results in the following list of packages:

This list would grow with 4 additional packages for each new module that needs persistence. And, if we add support for e.g. Oracle, we would need 1 additional package per module.

The main challenge is balancing the semantic clarity with the overhead of maintaining numerous packages. Could you elaborate on any specific benefits you see that might outweigh this overhead? Alternatively, do you have suggestions for achieving this modularity without drastically increasing the package count?

Looking forward to your thoughts!

XuJin186 commented 1 month ago

@sfmskywalker Thank you for your busy schedule. I don't think your so-called persistence. Entityframeworkcore. SQL Server is necessary to form Nuget package. Can you open DbContextOptionsBuilder and let the developer specify what database to use? It seems that the migration part can also be left to developers.

XuJin186 commented 1 month ago

elsa.UseWorkflowRuntime(runtime => runtime.UseEntityFrameworkCore(build=>build.useSqlServer(connectionString))); Similar to this, build is DbContextOptionsBuilder