Umbraco-cms: Consider making database Dtos public

[aochmann]

I want to suggest making database Dtos classes public (instead of internal at the moment).
It will be very helpful for custom plugins / applications that use Umbraco.Core as reference to use them and operating on database easily in a strongly typed manner (e.g. using PetaPoco or any other ORMs). Currently we're forced to keep duplicates of the Dtos to make it possible and it's extremely hard to keep them in sync in case of more or less dynamic database structure changes.
Is there any other possible reason why they are internal?

[ronaldbarendse]

The biggest reason why they're internal is probably to make sure you're using the services to update them, as directly updating them within the database will cause a lot of problems with out-of-date content caches, Examine indexes, distributed cache refreshers, etc.

Yes, you can already directly change data by writing your own SQL queries, but doing that on Umbraco tables will always be at your own risk.

[mzajkowski]

Yeah, that's a solid argument, but in many cases when we want to access database schema (access, not manipulate), it might be useful.

I forgot about DatabaseSchemaHelper class which was present in v7 (https://github.com/umbraco/Umbraco-CMS/blob/v7/dev/src/Umbraco.Core/Persistence/DatabaseSchemaHelper.cs), but from what I can see it was still not used to retrieve the model/dto for the table, but in most cases to operate on DB - which I obviously don't want to do outside of the services :) The name like it might suggest methods e.g. to get the schema for table/class etc. which might be the solution we're dreaming about now.

Maybe the pure SQL query would be safer than the strongly-typed approach in this case, but our isse popped out because we wanted to keep it typed and we couldn't without duplicates or custom mappers in this case.

[nul800sebastiaan]

Yes, Ronald is right, we don't encourage you to update the database directly, have all kinds of things we do in code to make sure that everything is updated correctly through the services layer, which also helps propagate changes in load balanced environment, kicks off events that people rely on, etc.

Using the services layer also means you don't need to worry about database structure changes, that's all handled for you.