search

DNNCommunity / Dnn.StructuredContent

This is a proof of concept for a structured content solution for DNN Platform (formerly known as DotNetNuke). This should not be used in a production environment. Anything can change at this stage of development.
Other
13 stars 5 forks source link

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

Closed mitchelsellers closed 2 years ago

mitchelsellers commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

mitchelsellers commented 2 years ago

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 commented 2 years ago

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: https://github.com/dnnsoftware/Dnn.Platform/issues/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 commented 2 years ago

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

WillStrohl commented 2 years ago

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.