C# 프로젝트 도우미 또는 유틸리티 클래스 구성

Question

.NET 프로젝트에서 도우미 클래스가 있어야하는 위치에 대한 모범 사례는 무엇입니까? 비즈니스 계층과는 별도로 클래스를 참조하지만 appSetting config manager와 같은 프리젠 테이션과 앱은 때로는 특정 모듈이거나 때로는 앱 전체에서 사용될 수있는 코드입니다.

Answer 1

나는 항상 이와 같은 것들을 꽤 유동적으로 허용합니다. 즉 :

1. 다른 클래스와 같은 "헬퍼"클래스를 테스트합니다. 이것은 그들이 정적이되지 않는 경향이 있습니다.
2. 필자는 필요할 때 이러한 헬퍼를 개별 메소드로 생성 할 수 있습니다. 둘 이상의 클래스에서 필요하다는 것을 알게되면, 같은 프로젝트에서 자신의 클래스 또는 "유틸리티"클래스로 옮깁니다.
3. 두 개 이상의 프로젝트에서 필요하다고 판단되면 프로젝트에서 솔루션, 솔루션에서 하위 시스템, 하위 시스템에서 응용 프로그램, 응용 프로그램에서 라이브러리 또는 프레임 워크 등으로 상위 계층을 이동시킵니다.

Answer 2

대부분의 사용자는 "도우미"폴더에 넣습니다.

도우미에 따라 필요한 경우 모의 할 수 있도록 가상 메서드를 표시 할 수 있습니다. 그것은 구현하는 인터페이스에 바인드하거나 바인드하지만 인터페이스 당 하나의 구체적인 경우에만 과도 할 수 있습니다.

도우미 방법이 외부 의존성이없는 순수한 계산이 아니라면 어떤 경우에도 정적이 아니어야합니다.

그렇다면 다시 고려하십시오.

Answer 3

나는 이것을 utils 네임 스페이스에 넣는 경향이있다. 주 프로젝트 이름 공간에서 꽤 일반적인 경우. MyProject.Utils.MyHelperClass이거나보다 구체적 인 경우 하위 네임 스페이스 MyProject.CRM.Utils.MyCRMHelperClass입니다.

Answer 4

나는 거의 항상 내 솔루션에 MyProject.Core 클래스 라이브러리가 있습니다.

편집 : 나는 "더 큰"질문에 대답했을 것입니다.

하나의 프로젝트에서 모든 프로젝트의 크기에 따라 다릅니다. Microsoft 디자인 가이드에서는 5 개 미만인 경우 네임 스페이스를 만들지 말아야한다는 것에 대해 이야기합니다.

Answer 5

예를 들어 도우미가 사업 객체 나 핵심 객체를 사용해야하는 경우를 제외하고는이 클래스를 필요로하는 모든 프로젝트에서 참조하도록 의도 된 Common이라는 어셈블리에 이러한 클래스를 넣습니다.

Answer 6

저는 Randolpho와 Ben이 한 것의 조합을하는 경향이 있습니다. 유틸리티 네임 스페이스의 "Utilities"폴더에서 정적 도우미 클래스를 사용합니다. 더 나은 파일 구성, 나머지 응용 프로그램 네임 스페이스를 명확하게 유지합니다.