네임 스페이스 및 클래스 이름 지침

유틸리티 및 기타 도움말 클래스가 포함될 때 클래스 및 서비스 이름을 올바르게 지정하는 데 문제가 있습니다.

다음을 어떻게 구성 하시겠습니까?

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

기타...

위의 서비스와 동일한 요구를 가진 여러 서비스가 있습니다. 한 가지 생각은이 모든 것을 적절한 네임 스페이스로 분리하여 다음과 같이 보이게하는 것입니다.

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

등등. 모든 네임 스페이스는 물론 별도의 폴더입니다. 그러나 DateValidators다른 서비스 에는 아마도 더 많은 것이 있기 때문에 100 % 느낌이 들지 않습니다 . 이는 원치 않는 참조로 쉽게 이어질 수 있습니다.

또한 Services.EventService.EventService.cs네임 스페이스에 클래스 이름을 포함시키는 것도 좋지 않습니다. 을 사용할 수 Services.Event.EventService.cs있지만 물론 해당 이름을 가진 엔터티가 이미 있습니다.

이것이 도메인 모델입니다.

네임 스페이스를 향상시키기 위해 할 수있는 가장 큰 일은 네임 스페이스에서 제거 Service하는 것 EventService입니다. 또한 네임 스페이스를 다음과 같이 조정합니다.

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

그래도 여전히 개선이 필요하다고 생각합니다.

나는 네임 스페이스를 좋아했지만 요즘에는 더 적은 것으로 생각합니다. 네임 스페이스를 깊게 중첩하면 코드가 너무 장황하게되어서 개체를 세분화하면 상속 능력이 떨어집니다. 예를 들어, 코드에서 DateValidator클래스를 다른 곳에서 쉽게 사용할 수 있으므로 EventService 이외의 서비스는 이제 DateValidator 클래스를 활용할 수 있으므로 그 위에 네임 스페이스가 많지 않아야합니다. 확장 방법에도 동일하게 적용됩니다. 모든 확장 메소드를 동시에 볼 필요가있는 시간이 없습니다 (따라서 볼 수 있습니다). 따라서 관련 메소드와 그룹화하는 것이 더 합리적입니다. 이 경우 EventExtensions아마도 귀하의에 연결 EventService되므로 논리적으로 제 의견으로는 함께 앉아야합니다.

범용 패턴을 따르기 위해 Microsoft의 일반 이름 지정 지침 및 네임 스페이스 이름 지정 지침 을 읽지 않는 이유는 무엇 입니까?

수식 <Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]이 잘 작동 한다고 생각합니다 .

적절한 네임 스페이스 디자인은 논리적 디자인과 물리적 디자인을 모두 고려합니다.

네임 스페이스에 대한 원래의 이론적 근거는 대부분 객체와 메소드 이름 사이의 이름 충돌을 방지하기위한 것이었지만 전체 솔루션 아키텍처와 디자인에서 중요한 요소가되었습니다. 개념적 계층 구조와 논리적 디자인이 합리적이기를 원할뿐만 아니라 나중에 다른 프로젝트와 제품에 쉽게 묶을 수 있도록 잘 디자인되고 재사용이 쉬운 라이브러리에 코드를 깔끔하게 패키지 할 수 있습니다. 그것은 아마도 좋은 물리적 디자인의 바람직한 결과 일 것입니다.

.NET Framework와 합리적인 크기의 어셈블리에서 관련 기능 단위가 어떻게 제공되는지 살펴보십시오. 참조 및 using 문을 삭제할 수 있으며 주방 싱크를 드래그하지 않고도 관련 기능을 사용할 수 있습니다. 지능적인 이름 공간 지정을 포함한 .NET Framework의 물리적 디자인은 논리적으로 관련된 코드를 물리적으로 관련된 배포 가능한 단위로 패키지했기 때문입니다. 네임 스페이스와 어셈블리간에 탁월한 매핑을 만들어서 Microsoft .NET 프레임 워크의 설계자와 개발자는 작업을 훨씬 더 쉽게 만들었습니다 (물론 다른 점은 논란의 여지가 있지만 그 일에 만족합니다).

C #의 네임 스페이스는 실제로 임의적입니다. 서로 멀리 떨어져있는 어셈블리에서 가장 이상한 곳에 네임 스페이스를 넣을 수 있습니다. 이 분야에서 도움이되는 분야는 실제로 잘 조직 된 소프트웨어 제품에 대한 귀하의 개인적인 기여입니다. 나는 각 경우에 정확히 무엇을해야하는지 조언하지 않을 것이다. 이 답변에서 내가 성취하고자하는 것은 네임 스페이스를 정의 할 때 논리적 디자인뿐만 아니라 물리적 디자인에 대해 생각하게하는 것입니다. 논리적으로 관련되고 배포 가능하게 (물리적으로) 번들로 묶일수록 나중에 언젠가 코드를 처리해야하는 다른 사람과 사용자 모두에게 더 쉬운 일이 될 것입니다.

따라서 네임 스페이스 문제를 해결할 때 어셈블리 및 컴포넌트에서 코드가 어떻게 패키지화 될지 생각해보십시오!