Swap Linq to SQL for Entity Framework 6/core OR PetaPoco?

[mitchelsellers]

The current implementation uses .dbml, which is also known as Linq to SQL, which is an optional installation feature and requires developer opt-in at Visual Studio Installation.

I believe it would be better to either use PetaPoco (DNN Standard) or EntityFramework to keep the number/types of platforms used down and limit developer install needs.

[david-poindexter]

While I don't disagree with this thought process, it does massively change the scope of work here. It is already written in LinqToSql and with the dynamic creation, modification, deletion of custom DB objects, we would need someone with the appropriate skill set to make such a contribution. @valadas @mathisjay and I discussed this at length and decided to keep as is for now. That doesn't mean we can't switch gears - it just means we would have to do a complete rewrite and we'd need to recruit someone that is will to contribute such a rewrite. Thoughts?

[mitchelsellers]

I'm willing to assist with this, as I'm not 100% sure that going forward with LINQ to SQL is the proper solution here. I've been taking with @valadas about this a bit.

[david-poindexter]

Ah, gotcha - sounds good then. Just let me know if/how I can help. To my knowledge, we have not used EF6 yet in DNN Platform yet, so this would be a first? If we go the DAL2 route with PetaPoco, I'm sure I can help there as well.

[X3Technology]

The dynamic creation of tables does not depend on LinqToSql. All of that is done with straight TSQL. The only thing that LinqToSql handles is the DAL for the modules tables, not the ContentType tables.

[david-poindexter]

Cool cool - then it should be pretty straightforward then to switch to EF6 or DAL2.

[mitchelsellers]

Yers, EF6 would be a first, but long-term I think it would be nice. There is some caching benefit possibly of using DAL2

[valadas]

I am going to try and play with EF6 2 situations here:

1. DatabaseOwner and ObjectQualifier support
2. Uninstalling (as we won't have SQL scripts, I need to make this work: Add an uninstall Interface to run custom module code dnnsoftware/Dnn.Platform#2160

As for cache, EF will have a request scope cache, but then we can add a level 2 cache (there is a nuget package for it)

[mitchelsellers]

Your item number 2 is not necessarily a requirement, EF does not require use of migrations

[WillStrohl]

I think using DAL2 would be best until we have built-in support and patterns in the DNN core. When that happens, maybe this could be the first example use case afterward, like we've done as a community with other core modules in the past.