search

EnterpriseLibrary / data-access-application-block

Apache License 2.0
18 stars 19 forks source link

Split the block into separate packages for each database #39

Closed tsahi closed 3 years ago

tsahi commented 4 years ago

Is your feature request related to a problem? Please describe. Today there is one big package that supports SQL Server, Oracle, and SqlCE. There is no reason people using SQL Server will take a dependency on packages supporting Oracle, and vice-versa.

Describe the solution you'd like We should split the package to several packages, so that:

  1. One base package will carry the base functionality, e.g. the abstract Database class, the caching, etc.
  2. A SQL Server package will depend on the base package, but will also depend on Microsoft.Data.SqlClient.
  3. An Oracle package will depend on the base package, but will also depend on Oracle.ManagedDataAccess[.Core]
  4. A SqlCE package will depend on the base package. This won't bring new dependencies.
  5. A Generic (very small) package will depend on the base package, exposing the GenericDatabase for use with OldDb provider.
tsahi commented 4 years ago

As I see it, the root problem is at DatabaseSyntheticConfigSettings, which has references to three different Database derivatives: SqlDatabase, OracleDatabase and GenericDatabase, which is used for anything else, unless you configured a specific Database derivative. They are used in GetDefaultMapping(string), which tries to guess the right mapping based on the provider name, when a provider is not configured in the <dataConfiguration> section.

This allows users to create a database provider for SQL Server or Oracle even without mapping a provider in the configuration, just by providing a connection string name. DAAB will read the providerName attribute and return the right provider.

We can see how this works in the Data.SqlCe.Tests.VSTS project. If you look at the SqlCeDatabaseFixture test class, you can see how it registers the SqlCeDatabase with the System.Data.SqlServerCe.4.0 in code, and then passes this configuration to DatabaseProviderFactory so it can produce the right provider.

So if we split the Data project to separate projects and assemblies for each database provider, we'll have to require users to map their provider name to database provider in configuration.

tsahi commented 4 years ago

This is a major change, and I plan to make several PRs for it. But if I merge partial changes to master, we won't be able to make new releases (or it will become difficult). So I suggest I branch from master, update my fork, and work on it on that branch in my fork. Then, I'll make a PR from the branch on my fork to the branch in this fork. What do you think?

tsahi commented 3 years ago

Update on branches: After I completed splitting SqlDatabase and OracleDatabase to separate projects, I merged it to Split-the-block-into-separate-packages, which is branched from master. Then, I branched milestone7.0 from master, and merged Split-the-block-into-separate-packages to milestone7.0. I will do the next developments toward this milestone on this branch, or branches from this branch. If any changes are committed to master, they will be rebased to this branch.

tsahi commented 3 years ago

As you can see from the commits above, I ended up creating an OleDbDatabase and OdbcDatabase, in two separate projects/packages. This is because each of them carries it's own package dependency, depending on the target framework.

So now we have:

tsahi commented 3 years ago

This is essentially done. support for Microsoft.Data.SqlClient will be done at #38 .