솔루션의 폴더가 네임 스페이스와 일치해야합니까?

솔루션의 폴더가 네임 스페이스와 일치해야합니까?

우리 팀 프로젝트 중 하나에는 프로젝트에 많은 하위 폴더가있는 클래스 라이브러리가 있습니다.

프로젝트 이름 및 네임 스페이스 : MyCompany.Project.Section.

이 프로젝트에는 네임 스페이스 섹션과 일치하는 여러 폴더가 있습니다.

• 폴더 Vehicles에는 MyCompany.Project.Section.Vehicles네임 스페이스에 클래스가 있습니다.
• 폴더 Clothing에는 MyCompany.Project.Section.Clothing네임 스페이스에 클래스가 있습니다.
• 기타

이 같은 프로젝트 안에 다른 불량 폴더가 있습니다

• 폴더 BusinessObjects에는 MyCompany.Project.Section네임 스페이스에 클래스가 있습니다.

"조직적 편의성"을 위해 폴더가 만들어지는 몇 가지 경우가 있습니다.

내 질문은 : 표준은 무엇입니까? 클래스 라이브러리에서 폴더는 일반적으로 네임 스페이스 구조와 일치합니까, 아니면 혼합 백입니까?

또한 기본 제공 템플릿을 사용하여 클래스를 폴더에 추가하면 기본적으로 폴더 계층 구조를 반영하는 네임 스페이스에 배치됩니다.

수업은 찾기가 쉬울 것이며 혼자서도 충분한 이유가 될 것입니다.

우리가 따르는 규칙은 다음과 같습니다.

• 프로젝트 / 어셈블리 이름은 .dll 끝을 제외하고 루트 네임 스페이스와 동일합니다.
• 위 규칙의 예외는 .Core로 끝나는 프로젝트이며 .Core는 제거됩니다.
• 폴더는 네임 스페이스와 같습니다.
• 파일 당 하나의 유형 (클래스, 구조체, 열거 형, 대리자 등)으로 올바른 파일을 쉽게 찾을 수 있습니다.

아니.

나는 하나의 (나) 개발자 팀과 함께 크고 작은 프로젝트에서 두 가지 방법을 모두 시도했습니다.

가장 간단하고 생산적인 경로는 프로젝트 당 하나의 네임 스페이스를 갖고 모든 클래스가 해당 네임 스페이스에 들어가는 것입니다. 그런 다음 원하는 프로젝트 폴더에 클래스 파일을 자유롭게 넣을 수 있습니다. 네임 스페이스가 하나뿐이므로 항상 파일 맨 위에 using 문을 추가 할 필요가 없습니다.

소스 파일을 폴더로 구성하는 것이 중요하며 모든 폴더를 사용해야한다고 생각합니다. 이러한 폴더도 네임 스페이스에 매핑해야하는 것은 불필요하고 더 많은 작업이 발생하며 추가 부담으로 인해 조직이 해체 될 수 있기 때문에 실제로 조직에 유해한 것으로 나타났습니다.

이 FxCop 경고를 예로 들어 보겠습니다.

CA1020 : 유형
이 거의없는 네임 스페이스 사용 안 함 원인 : 전역 네임 스페이스 이외의 네임 스페이스에 5 가지 미만의 유형이 포함되어 있습니다 https://msdn.microsoft.com/en-gb/library/ms182130.aspx

이 경고는 새 파일 생성을 정당화 할 네 개의 유사한 클래스가있을 때까지 새 파일을 일반 Project.General 폴더 또는 프로젝트 루트에 덤프하도록 권장합니다. 그런 일이 일어날까요?

파일 찾기

받아 들여진 대답은 "수업을 더 쉽게 찾을 수 있고 그 자체만으로도 충분한 이유가 될 것입니다."라고 말합니다.

대답은 하나의 네임 스페이스가있는 프로젝트라고 제안하는 것이 아니라 폴더 구조에 매핑되지 않는 프로젝트에 여러 네임 스페이스가 있음을 의미한다고 생각합니다.

네임 스페이스에서 클래스 파일이있는 폴더를 확인할 수없는 경우 Visual Studio의 정의로 이동 또는 검색 솔루션 탐색기 상자를 사용하여 찾을 수 있습니다. 또한 이것은 내 의견으로는 큰 문제가 아닙니다. 최적화 시간을 정당화하기 위해 파일을 찾는 문제에 대해 개발 시간의 0.1 %조차 소비하지 않습니다.

이름 충돌

여러 네임 스페이스를 생성하면 프로젝트에 동일한 이름을 가진 두 개의 클래스가있을 수 있습니다. 하지만 정말 좋은가요? 가능하지 못하게하는 것이 더 쉬울까요? 같은 이름을 가진 두 개의 클래스를 허용하면 90 %의 시간이 특정 방식으로 작동하고 갑자기 특별한 경우가있는 복잡한 상황이 발생합니다. 별도의 네임 스페이스에 두 개의 Rectangle 클래스가 정의되어 있다고 가정합니다.

• Project1.Image.Rectangle 클래스
• Project1.Window.Rectangle 클래스

소스 파일에 두 네임 스페이스가 모두 포함되어야하는 문제가 발생할 수 있습니다. 이제 해당 파일의 모든 곳에서 전체 네임 스페이스를 작성해야합니다.

var rectangle = new Project1.Window.Rectangle();

또는 진술을 사용하여 불쾌한 것에 대해 혼란스러워하십시오.

using Rectangle = Project1.Window.Rectangle;

프로젝트에서 단일 네임 스페이스를 사용하면 다른 이름을 사용해야하며 더 설명적인 이름을 다음과 같이 주장합니다.

• Project1.ImageRectangle 클래스
• Project1.WindowRectangle 클래스

그리고 사용법은 어느 곳에서나 동일하므로 파일이 두 가지 유형을 모두 사용하는 경우 특별한 경우를 다룰 필요가 없습니다.

진술을 사용하여

using Project1.General;  
using Project1.Image;  
using Project1.Window;  
using Project1.Window.Controls;  
using Project1.Shapes;  
using Project1.Input;  
using Project1.Data;  

vs

using Project1;

코드를 작성하는 동안 네임 스페이스를 항상 추가 할 필요가 없습니다. 실제로 걸리는 시간이 아니며, 그것을해야하고 많은 사용 문으로 파일을 채우는 흐름이 끊어졌습니다. 무엇을 위해? 그만한 가치가 있습니까?

프로젝트 폴더 구조 변경

폴더가 네임 스페이스에 매핑되면 프로젝트 폴더 경로가 각 소스 파일에 효과적으로 하드 코딩됩니다. 즉, 프로젝트에서 파일 또는 폴더의 이름을 바꾸거나 이동하려면 실제 파일 내용을 변경해야합니다. 해당 폴더에있는 파일의 네임 스페이스 선언과 해당 폴더에있는 클래스를 참조하는 다른 모든 파일에 대한 명령문 사용 변경 사항 자체는 툴링에있어 사소한 것이지만 일반적으로 클래스가 변경되지 않은 많은 파일로 구성된 커밋이 커집니다.

프로젝트에 단일 네임 스페이스를 사용하면 소스 파일 자체를 수정하지 않고 원하는대로 프로젝트 폴더 구조를 변경할 수 있습니다.

Visual Studio는 새 파일의 네임 스페이스를 생성 된 프로젝트 폴더에 자동으로 매핑합니다.

불행히도 네임 스페이스를 수정하는 번거 로움이 그들을 다루는 번거 로움보다 적습니다. 또한 Add-> New를 사용하지 않고 기존 파일을 복사하여 붙여 넣는 습관을 들었습니다.

Intellisense 및 개체 브라우저

대규모 프로젝트에서 여러 네임 스페이스를 사용한다는 견해에서 가장 큰 이점은 네임 스페이스 계층 구조로 클래스를 표시하는 도구에서 클래스를 볼 때 추가 구성이 있다는 것입니다. 문서조차도. 프로젝트에 네임 스페이스가 하나만 있으면 모든 클래스가 범주로 구분되지 않고 단일 목록으로 표시됩니다. 그러나 개인적으로 나는 이것의 부족으로 인해 혼란 스럽거나 지연되지 않았으므로 여러 네임 스페이스를 정당화 할만 큼 큰 이점을 찾지 못했습니다.

나는 큰 공공 클래스 라이브러리를 작성한다면 그때는 있지만 것입니다 아마이 프로젝트에 여러 네임 스페이스를 사용하는 어셈블리 툴과 문서 깔끔한 모습 있도록.

.NET 내에서 표준은 가능한 경우 표준을 시도하지만 어려운 규칙으로 준수하기 위해 불필요하게 깊은 구조를 만들지 않는 것입니다. 내 프로젝트는 네임 스페이스 == 구조 규칙을 100 % 준수하지 않으며 때로는 그러한 규칙에서 벗어나는 것이 더 깨끗합니다.

Java에서는 선택의 여지가 없습니다. 이론적으로 작동하는 것과 실제 작동하는 것을 고전적인 사례라고 부릅니다.

@lassevk : 나는이 규칙에 동의하고 추가 할 것이 하나 더 있습니다.

중첩 클래스가 있어도 파일 당 하나씩 분리합니다. 이처럼 :

// ----- Foo.cs
partial class Foo
{
    // Foo implementation here
}

과

// ----- Foo.Bar.cs
partial class Foo
{
    class Bar
    {
        // Foo.Bar implementation here
    }
}

예라고 대답하겠습니다.

먼저 네임 스페이스를 따라 가면 실제 코드 파일을보다 쉽게 ​​찾을 수 있습니다 (예를 들어 누군가가 나에게 예외 호출 스택을 이메일로 보내는 경우). 폴더가 네임 스페이스와 동기화되지 않게하려면 큰 코드베이스에서 파일을 찾는 것이 지치게됩니다.

둘째, VS는 상위 폴더 구조와 동일한 네임 스페이스를 사용하여 폴더에 새 클래스를 생성합니다. 이 문제를 해결하기로 결정했다면 새 파일을 추가 할 때 매일해야 할 일이 하나 더있을 것입니다.

물론 이것은 xis 폴더 / 네임 스페이스 계층 구조의 깊이에 대해 보수적이어야한다는 것은 말할 것도 없습니다.

그렇습니다. 그렇지 않으면 혼란을 초래할뿐입니다.

표준은 무엇입니까?

공식 표준은 없지만 일반적으로 폴더 대 네임 스페이스 매핑 패턴이 가장 널리 사용됩니다.

클래스 라이브러리에서 폴더는 일반적으로 네임 스페이스 구조와 일치합니까, 아니면 혼합 백입니까?

예, 대부분의 클래스 라이브러리에서 폴더는 조직의 편의를 위해 네임 스페이스와 일치합니다.