Consistently expose Service classes

[LennardF1989]

Right now the code-base of Umbraco is all over the place.

• Some classes are internal (UserService)
• Some classes are public sealed (AuditService)
• Some classes are public (ContentService)

With proper dependency injection, it can be desirable to replace these services with an own implementation. But right now, for some of these you are forced to make proxy classes to be able to do so. Whereas in most cases being able to extend the original class and then override a single method through the interface is all that is needed.

In my situation, I now have to override one particular function in the UserService, so I have to make a ProxyUserService : IUserService, get an instance of the original UserService (eg. through reflection), and then proxy all methods. This results in a 230-something LoC class, while this could have been a few lines.

IMO: There is no reason to make things either sealed or internal other than making it hard on the developer, as there are always (convoluted) ways around it. If someone goes down the route of replacing something, they will most likely have a very good reason to do so and it's on them to make sure it remains working if Umbraco HQ changes something.

[bergmania]

Hi @LennardF1989.

This is a bit more complex IMO.

The more public, the harder it is to maintain and the less things can be released to minor versions, due to us not being able to change signatures. We already do lots of things to avoid breaking changes, and that makes all tasks a bit bigger.

From a "Umbraco as a product" point of view. We would like everything to be sealed internal and only interfaces to be public due to the performance benefits.
From a "Umbraco as a framework" point of view. We would like everything to be public.

That said, we would like to make it more consistent, but depending on the direction. This will be breaking changes.

[LennardF1989]

I don't quite understand the point of signatures not being able to change. I would tag these classes as "special cases" where they are public "at a risk". As in, you will treat them as if they are not public when developing. You could make that very clear with some attributes on them.

If I have a reason to extend the original implementation, I should also be prepared for it to break :P

As for the sealed performance, agree. In that case maybe "all service classes" is a bit too much, but I'd say at least the most used ones with some core fundamentals? UserService is one of those.

[bergmania]

We looked into making a attribute solution to what's "real" public, but found out that was too unmaintainable - #9456.

IIRC there also exists solutions to read internal methods/classes, but I can't remember who know about it. It was not just InternalVisibleTo.
This would definitely be preferred over having more public than absolutely necessary.