EntityFramework support vs direct SQL

[RussKahler1970]

reviewing the oqtane framework and it looks very promising and interesting. Any idea if there would ever be interest in supporting entityFramework based Repository model?

[hishamco]

Any idea if there would ever be interest in supporting entityFramework based Repository model?

Oqtane is already using repository pattern, have a look to https://github.com/oqtane/oqtane.framework/tree/dev/Oqtane.Server/Repository

[RussKahler1970]

I see that and I am a big proponent of the Repository pattern but if you look at the SQLRepository its using direct SQL and its returning raw data. I would love to see a EntityFrameowrk Repository if possible and really one using the Specification pattern with it would be a great addition.

[markagama]

This sounds like a great idea, I wonder if there is a list of work tasks that we can see or vote on?

[sbwalker]

@RussKahler1970 as @hishamco mentioned, Oqtane already uses an EF Core Repository model and does NOT rely on direct SQL.

If you look in the Oqtane.Server\Repository folder you will see the repository classes for all of the entities which the framework currently supports. If you review the code more closely you will notice that the SQLRepository you identified is not a generic repository... it is only used in one very specific scenario - to allow a host user to navigate to a SQL Manager module in the UI and enter raw SQL statements that are executed against a specific database for development/debugging purposes. All other scenarios have dedicated repositories implemented using standard EF Core.

A decision was made a few years ago to NOT use a generic repository pattern as in practice there are many repositories which require custom methods that do not conform to a generic set of repository methods - and in essence EF Core itself is a generic repository so it does not offer much benefit to add another unnecessary layer of abstraction ). The current repository has been optimized to support multiple types of databases as well as multi-tenancy requirements, so I would be very hesitant to refactor it unless there is a very clear and obvious benefit.

[markagama]

@sbwalker I think the ability for the admin to make changes to the db using SQL for testing is very positive. I imagine this code is removed for a release build.

I wonder if this facility could be extended to modules for debugging? Probably a very low priority.

[sbwalker]

@markagama the SQL Management capability already supports modules for debugging (as long as the module stores its data in the same database as the other Oqtane entities - which is the typical approach),

[RussKahler1970]

I do see Entity specific based repositories that are built with specific arguments and returns. My concern would be as I add in entities that would have a more complex structure and need to allow for runtime level filtering, sorting, grouping and pagination. I guess I was hoping to find something that would allow more dynamic nature to data access. Just as an example if you get into CRM or business related data it might include 10+ entities and the application might require complex filtering options that users can control and change at runtime. Different tenants might have different data elements.

I guess the question really is how would this framework support dynamic entity framework access?

[sbwalker]

@RussKahler1970 Oqtane does not prevent you from using any data access method you prefer in your own modules.