Structural Refactoring - .NET 6.0 & SqlServer

[enisn]

Summary

Why do you need to create DbContext and models for each EF Provider? They're just providers, the project abstraction shouldn't know anything about a provider. So I removed all the provider-specified codes and merged them into a single abstraction layer.

As I can see, migrations are managed by the library. Between EF Providers, the only different thing is migrations. Only migrations are separated in the ideal scenario. You can see, provider specified projects have only migrations but now any of EF providers can be used via generating migrations

---

What brings that structure?

That structure has a couple of benefits like I presented below.

Database Independency

Firstly, database dependency is completely removed. That means developers can use any database as they wish with EntityFramework. They need to manage their own migrations for database providers which we don't provide migrations.

• New usage of a database that ironhook support (PostgreSql).
  If we provide migrations, it can be defined via calling UseIronHook{databasename}Migrations() method.

            services.AddIronHook(options =>
            {
                options.UseNpgsql(
                Configuration.GetConnectionString("Default"), 
                opts => opts.UseIronHookNpgsqlMigrations());
            });

I just replaced UseIronHook() method with MigrateIronHook() method since it doesn't add a middleware, it just performs a migration operation.

app.MigrateIronHook();

• New usage of Non-supported databases

options.UseMySql(Configuration.GetConnectionString("Default"));

Migrations aren't provided by IronHook, but MigrateIronHook can still be used, it'll create a database from the current state of DbContext with https://github.com/FowApps/IronHook/pull/45/files#diff-48af72c016bfcfaede0f855ae54a6f1b88fceeb48b7977aea5bb3bc412f376edR41-R48

app.MigrateIronHook();

Managing own migrations by developers is highly recommended for unsupported databases but it's not mandatory

Multi-Targeting

Now, the project can support both framework versions at the same time. Projects are targeting .NET 5 and .NET6 right now.

In the future, .Net 5 support can be dropped partially.

Common DbContext

I just have removed DB provider-specific DbContexes since there is no difference with CoreDbContext. Using single DbContext is much more maintainable.

---

• Closes ✨ [FEATURE] SQL Server Implementation #40
• Closes 📌 [CUSTOM] Net6 support #44

[enisn]

Hi @codeclimate, all of problems you found are auto-generated files (migrations) 😅

[furkandeveloper]

Thanks for the contribution, @enisn we are reviewing it as a team.

[furkandeveloper]

Update codeclimate.yml file on root and exclude SqlServer migration files. @enisn

[furkandeveloper]

Codeclimate treats files with the same name as duplications. For this reason, we must make the names of the IronHookCoreDbContextFactory classes provider dependent.

for example;

IronHookPostgreSqlCoreDbContextFactory instead of IronHookCoreDbContextFactory
we can use

@enisn

[codeclimate]

Code Climate has analyzed commit c66a794 and detected 4 issues on this pull request.

Here's the issue category breakdown:

Category	Count
Duplication	4

View more on Code Climate.

[enisn]

Any updates?

[furkandeveloper]

Any updates?

Not for now. Tests continue. PR can be merged on weekdays. @enisn

[furkandeveloper]

[enisn]

I can't update the wiki section, Can you update documentation too?

[furkandeveloper]

I updated wiki documentation. Thanks @enisn. Developing with you is so much fun. 🎉🎉🎉🎉

[furkandeveloper]

@all-contributors please add @enisn for infrastructure, tests and code

[allcontributors]

@furkandeveloper

I've put up a pull request to add @enisn! 🎉