Visual Studio 2022 internal vs public - dlaczego Microsoft kładzie nacisk na internal nawet w WebAPI?

Witam.
Nowe klasy automatycznie są tworzone jako internal. Czy to się troszkę nie kłóci z tym co robimy w projekcie typu WebAPI? Mówi się, że najlepiej jest rozdzielać logikę osobnym projektem i tam też trzymać repozytoria i/lub serwisy, ale w przypadku klas internal to to niestety nie zadziała. W Startup.cs nie będę mógł zarejestrować klasy z osobnego projektu

services.AddScoped<SuperProService>();

internal class SuperProService 
{
   // complicated super pro logic
}

Coś znowu przeoczyłem?

Klasy zawsze były domyślne tworzone jako internal, tylko nie były jawnie wskazywane. Pusta klasa bez dopisku, że jest publiczna
jest właśnie internal.

Wydawało mi się, że bez dopisku domyślnie jest private. Czyli to nie ma nic wspólnego z "nowymi trendami", po prostu Microsoft twierdzi, że taki zapis jest najczęściej używany i dlatego go dopisuje?

AdamWox napisał(a):

Wydawało mi się, że bez dopisku domyślnie jest private.

Nie, to metody i pola. Niezagnieżdżone klasy nie mogą być private.

Czyli to nie ma nic wspólnego z "nowymi trendami", po prostu Microsoft twierdzi, że taki zapis jest najczęściej używany i dlatego go dopisuje?

Po prostu większość klas powinna być wewnętrzna w ramach modułu, a jedynie niektóre publiczne. Stąd więcej sensu ma domyślny internal.

Trochę się to gryzie z zamysłem rozdzielania jak najwięcej na projekty. Ja wiem, że to idzie zmienić, wystarczy pogrzebać w plikach, ale fajnie by było jakby VS wiedział jaki to typ projektu i dostosował odpowiednio dodawanie nowych klas. Zrobił taki bajer jak intelicode, a z tym by miał problem?

Ale to nie jest kwestia VS tylko języka C#. Jeśli nie ma modyfikatora, to klasa jest internal, zmiana kompilatora teraz mogła by napsuć sporo istniejącego kodu, a kompilacja warunkowa w zależności do typu projektu to byłaby też raczej zbędna komplikacja.

No, ale w czym przeszkadza oznaczenie klasy jako internal w podzieleniu na projekty? Klasy wewnątrz biblioteki powinny być internal. Wystawiasz publicznie tylko interfejsy. W celu zarejestrowania tworzysz sobie w danym projekcie metodę rozszerzającą IServiceCollection i w niej sobie rejestrujesz wszystkie potrzebne rzeczy w ramach tego projektu, a potem w Startup.cs wywołujesz ją sobie na obiekcie services.

Już kiedyś też pisałem o tym. W moich projektach interfejsy nie mają sensu, bo to niepotrzebny "bojlerplejt". Jedyne mądre zastosowanie w tym momencie to twój przykład, ale jaką to robi różnicę, skoro i tak wszystko to co będzie w klasie internal będzie dostępne publicznie w interfejsie? Wtedy wystarczy klasę zrobić public i mam ten sam rezultat bez klepania, "bo tak powinno się", interfejsów.

No to już zależy tak naprawdę czego potrzebujesz.
Różnica taka, że korzystając z interfejsów udostępniasz na zewnątrz biblioteki tylko kontrakt bez niepotrzebnego udostępniania szczegółów implementacji.
Ja używam interfejsów przede wszystkim dla klas, które rejestruję w IOC, potem jest możliwość łatwej podmiany implementacji w zależności np. od środowiska, czy w trakcie działania aplikacji wstrzykiwania odpowiedniego serwisu. Pomijając tworzenie testów i mockowanie interfejsów.

AdamWox napisał(a):

Już kiedyś też pisałem o tym. W moich projektach interfejsy nie mają sensu, bo to niepotrzebny "bojlerplejt". Jedyne mądre zastosowanie w tym momencie to twój przykład, ale jaką to robi różnicę, skoro i tak wszystko to co będzie w klasie internal będzie dostępne publicznie w interfejsie? Wtedy wystarczy klasę zrobić public i mam ten sam rezultat bez klepania, "bo tak powinno się", interfejsów.

No ok, tylko interfejsy właśnie m.in. do tego służą, aby łączyć ze sobą kod z wielu modułów. Interfejsy pozwalają Ci odseparować kod używający ich implementacji od zależności tego kodu, czyli jeśli masz projekt główny G i moduł M, który ma swoje zależności A, B i C, to G nie musi nic wiedzieć o A, B i C. Jeśli M ma tylko klasy, to G musi być świadomy istnienia A, B i C.

Dokładnie.

Należy rozróżniać bezsensowne klepanie interfejsów per jedna implementacja w obrębie pojedynczej dllki, od wystawiania publicznego kontraktu dla różnych aplikacji klienckich.

Jeśli nie opłaca się u mnie klepać interfejsów, a potrzebuje klasę (serwis) dopisać do DI, to logicznym jest, że musi być publiczna jeśli jej definicja znajduje się w innym projekcie

@AdamWox: tak w sumie to w czym problem?

No w tym, że Visual Studio kładzie nacisk na klasy internal

Przecież klasy już były domyślnie internal, ponieważ w wersjach VS do wersji 2019 (włącznie), przy tworzeniu klas VS nie dodawał modyfikatora dostępu- co za tym idzie, nowe klasy były internal. Np:

class Foo { }

Jak już zostało Ci wyjaśnione, to nie kwestia VS tylko języka C#. Jedyne co zrobił VS 2022 to sprawił że to co do tej pory na pierwszy rzut oka było niejawne, stało się jawne.