Wytyczne dotyczące nazw i klas

Mam problemy z prawidłowym nazwaniem moich klas i usług, gdy w grę wchodzą narzędzia i inne klasy pomocy.

Jak byś zbudował następujące elementy:

EventService.cs
EventServiceUtils.cs
EventServiceValidators.cs
EventServiceCoordinator.cs

itp...

Mam wiele usług o takich samych potrzebach jak powyższa usługa. Jedną z myśli jest podzielenie tego wszystkiego na odpowiednią przestrzeń nazw, dzięki czemu będzie wyglądać mniej więcej tak:

Services.EventService.EventService.cs //(the actual service)
Services.EventService.Validators.DateValidator.cs
Services.EventService.Validators.ParticipantValidator.cs
Services.EventService.Coordinators.ParticipantCoordinator.cs
Services.EventService.ExtensionMethods.Extensions.cs

i tak dalej. Każda przestrzeń nazw jest oczywiście oddzielnym folderem. Ale to nie wydaje się 100%, ponieważ prawdopodobnie jest więcej DateValidatorsw innych usługach, co może łatwo prowadzić do niechcianych referencji.

A także Services.EventService.EventService.cs zawiera nazwę klasy w przestrzeni nazw, co też nie jest dobre. Możesz użyć Services.Event.EventService.cs, ale oczywiście istnieje już jednostka o tej nazwie.

To jest model domeny.

Myślę, że najważniejszą rzeczą, którą możesz zrobić, aby poprawić tutaj swoją przestrzeń nazw, jest usunięcie jej Servicez EventServiceprzestrzeni nazw. Zmieniłem też przestrzenie nazw, aby były bardziej podobne do tego:

Services.Events.EventService.cs //(the actual service)
Services.Events.EventExtensions.cs
Services.Events.ParticipantCoordinator.cs
Services.Validators.DateValidator.cs
Services.Validators.ParticipantValidator.cs

Nadal uważam, że przydałaby się poprawa.

Kiedyś lubiłem przestrzenie nazw, ale obecnie myślę, że mniej znaczy więcej. Głębokie zagnieżdżenie przestrzeni nazw może sprawić, że kod będzie zbyt szczegółowy, a rozbijanie elementów na daleko zmniejsza zdolność do dziedziczenia. Na przykład w kodzie DateValidatorklasa może być łatwo używana w innym miejscu, więc nie powinna mieć wielu przestrzeni nazw powyżej niej, ponieważ usługi inne niż EventService mogą teraz korzystać z klasy DateValidator. To samo dotyczy metod rozszerzenia. Nie ma czasu (który widzę), w którym musisz zobaczyć wszystkie metody rozszerzenia w tym samym czasie, dlatego sensowniej jest pogrupować je według tego, z czym się wiąże. W tym przypadku EventExtensionsprawdopodobnie linki do twojego EventService, więc logicznie powinny moim zdaniem siedzieć razem.

Dlaczego nie przeczytasz ogólnych wskazówek dotyczących nazewnictwa i wskazówek dotyczących nazewnictwa przestrzeni nazw firmy Microsoft, aby zastosować uniwersalny wzór?

Myślę, że formuła <Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]po prostu działa dobrze.

Właściwy projekt przestrzeni nazw będzie uwzględniał zarówno logiczny, jak i fizyczny projekt.

Chociaż pierwotnym uzasadnieniem dla przestrzeni nazw było głównie zapobieganie konfliktom nazw między nazwami obiektów i metod, stał się ważnym elementem w ogólnej architekturze i projekcie rozwiązania. Nie tylko chcesz, aby hierarchia pojęciowa i logiczny projekt miały sens, ale zapewne chcesz również, aby Twój kod był starannie zapakowany w dobrze zaprojektowane i łatwe do ponownego wykorzystania biblioteki, które można później łatwo łączyć z innymi projektami i produktami. Być może jest to bardziej pożądany rezultat dobrego projektu fizycznego.

Spójrz na platformę .NET Framework i sposób, w jaki jednostki pokrewne funkcje są dostarczane w zestawach o rozsądnych rozmiarach. Możesz rzucić odniesienie i instrukcję użytkowania i nagle masz odpowiednią funkcjonalność dostępną bez konieczności przeciągania dowolnej liczby zlewów kuchennych. Wynika to z faktu, że fizyczny projekt systemu .NET Framework - w tym inteligentna przestrzeń nazw - zawiera logicznie powiązany kod w fizycznie powiązanych urządzeniach do wdrożenia. Tworząc doskonałe odwzorowanie przestrzeni nazw i zestawów, architekci i programiści platformy Microsoft .NET znacznie ułatwiają twoją pracę (oczywiście niektórzy mogą twierdzić inaczej, ale jestem raczej zadowolony z tego, co zrobili).

Przestrzeń nazw w języku C # jest naprawdę dowolna. Przestrzenie nazw można umieszczać w najdziwniejszych miejscach, w zespołach daleko od siebie oddalonych. Każda pomocna dyscyplina w tym obszarze jest naprawdę osobistym wkładem w dobrze zorganizowany produkt. Nie odważyłbym się doradzić ci dokładnie, co robić w każdym przypadku. Mam nadzieję, że w tej odpowiedzi uda mi się nakłonić cię do zastanowienia się nad projektem fizycznym, a także projektem logicznym podczas definiowania przestrzeni nazw. Im bardziej trzymasz rzeczy logicznie powiązane i możliwe do wdrożenia (fizycznie) w pakiecie, tym łatwiej będzie później, zarówno dla ciebie, jak i dla innych osób, które pewnego dnia będą musiały poradzić sobie z twoim kodem.

Zastanów się więc, jak Twój kod będzie pakowany w zespoły i komponenty podczas rozwiązywania problemów z przestrzenią nazw!