아니.

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

가장 간단하고 생산적인 경로는 프로젝트 당 하나의 네임 스페이스를 갖고 모든 클래스가 해당 네임 스페이스에 들어가는 것입니다. 그런 다음 원하는 프로젝트 폴더에 클래스 파일을 자유롭게 넣을 수 있습니다. 네임 스페이스가 하나뿐이므로 항상 파일 맨 위에 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 및 개체 브라우저

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

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

답변

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

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