클래스 나 모듈은 언제 별도의 Assembly / DLL에 있어야합니까?

클래스가 자체 어셈블리 / DLL에 있어야하는 시점을 결정하기위한 지침이 있습니까? 나는 종종 두 개의 사고 학교를 봅니다 :

1) 모든 클래스 그룹은 리포지토리, 서비스, DTO, 인프라 등 자체 DLL에 속합니다.

2) 모든 것이 단일 DLL에 있어야하지만 네임 스페이스 / 폴더를 통해 분리되어야합니다. 예를 들어 Core.Repositories, Core.Services, Core.DTO 등과 같은 추가 네임 스페이스가있는 "Core"DLL이 있습니다.

직장에서는 "비즈니스"라는 단일 어셈블리에서 모든 것을 일괄 처리합니다. 일부 폴더는 있지만 실제 분리는 없습니다. 비즈니스 오브젝트 (논리, 일부는 클래스가 아니어야 함)는 "BusinessObjects"폴더에주의없이 집중됩니다. 둘 이상의 클래스에서 사용되는 것은 "Core"폴더에 있습니다. 유틸리티는 "유틸리티"폴더에 있으며, 데이터 액세스 인프라는 "데이터"폴더입니다.

새 모듈의 경우 별도의 데이터 액세스 계층이 필요합니다 (기본 저장소 구현을 생각하십시오).하지만 다른 160 (! 거기 수업. 동시에 모든 사람이 단일 라이브러리에서 클래스를 채우는 데 익숙하기 때문에 새 클래스 라이브러리를 만드는 데 관심이 있습니다. 그러나 폴더 / 네임 스페이스가 작동 할 수 있습니다.

c# architecture directory-structure

— 웨인 몰리나
소스

답변:

별도의 네임 스페이스에 모든 클래스가있는 하나의 프로젝트보다 각 프로젝트에서 클래스로 분류 된 더 많은 프로젝트 (예 : 어셈블리)를 갖는 것이 더 좋습니다. 프로젝트를 재사용하고 응용 프로그램에서 다른 계층을 나타내는 것을 목표로해야합니다. 그런 다음 불필요한 클래스를 모두 포함하지 않고도 향후 응용 프로그램에서 이러한 프로젝트를 재사용 할 수 있습니다.

예를 들어, 당신이 언급 한 것을 기반으로, 나는 분명히 다음 프로젝트를 가질 것입니다 :

핵심
데이터
도메인 (또는 BusinessObjects)
서비스
유틸리티 (또는 헬퍼)

— 남자 이름
소스

유감스럽게도 대답에 투표 할 수 없습니다. 이것이 바로 우리 회사에서 조언하는 것입니다. 예를 들어 중간 크기 웹 사이트와 같은 6 개 정도의 프로젝트가있는 결과로 디렉토리 기반의 기능 기반 계층 구조를 유지할 수 없습니다. 결과적으로 6 개 프로젝트로 끝날 때마다 파일 더미를 탐색하기가 매우 어려워집니다. 일반적으로 이것을 조언하는 사람들은 상대적으로 큰 프로젝트에서 프로젝트의 기능 기반 구조를 시도한 적이 없습니다 (직접 판단하기는 미안하지만 그러한 결과를 다루는 것은 정말 고통 스럽습니다). jammycakes 답변은 올바른 접근 방식을 조언합니다.

— alehro

수업을 카테고리별로 나누면 큰 프로젝트에서 혼란을 초래합니다. 기능 / 관점별로 구분하십시오. 그런 다음 네임 스페이스가이 부분을 미러링합니다. 그리고 전체 구조는 사양에서 사전을 반영합니다. 클래스를 범주로 나누는 것은 변수 약어에 유형 약어를 추가하는 것과 같습니다. 일반적으로 냄새가 나쁩니다.

— alehro

제안 된 솔루션 (예 : 너무 많은 프로젝트 또는 너무 적은)을 남용하기 쉽습니다. 재사용 성과 낮은 커플 링을 염두에두고 균형을 잘 잡으면 더 테스트 가능하고 유지 보수가 용이해야합니다.

— Bernard

클린 코드의 "Uncle Bob"Martin, SOLID Principles 명성은 여기 에 세 가지 원칙 을 설명 했습니다 .

방출 재사용 동등성 원리 : 재사용 과립은 방출 과립이다.
공통 폐쇄 원칙 : 함께 변경되는 클래스가 함께 패키지됩니다.
공통 재사용 원칙 : 함께 사용되는 클래스가 함께 패키지됩니다.

일반적으로 솔루션의 프로젝트 수를 가능한 한 낮게 유지해야합니다. 하나 이상의 특정 사용자 스토리를 구현하기 위해 수행해야하거나 단일 어셈블리로 측정 가능한 성능 문제가 발생하는 경우 (일반적으로 최대 수 메가 바이트 크기에 도달 한 경우)에만 분할하십시오.

— jammycakes
소스

+1이 원칙은 좋은 지침입니다. 클래스를 다른 어셈블리로 분리하면 추가 설계 고려 사항 (예 : 각 어셈블리의 버전이 함께 작동하도록 허용됨)이 발생하여 전체 코드베이스가 증가하여 유지 관리 비용이 증가합니다.

— Ben

그러나 이러한 원칙 외에도 별도의 어셈블리에서 교체 또는 교체 될 가능성이있는 코드를 패키지화하는 것이 좋습니다. 이 코드는 별도의 어셈블리를 결합하는 데 필요한 추가 고려 사항의 이점을 제공하며 별도의 어셈블리를 사용하면 다른 버전을 쉽게 테스트하고 비교할 수 있습니다.

— Ben

예, 그러나 교체하거나 교체해야하는 진정한 요구 사항이 있는지 확인하십시오. 예를 들어, 프레임 워크 및 타사 라이브러리 (NuGet 패키지 등)는 일반적으로 여러 IOC 컨테이너와 여러 로깅 프레임 워크를 지원해야합니다. 반면에 사용자 영역 코드의 경우 이러한 추상화는 일반적으로 순전히 추론 적이며 불필요하고 방해 적이며 실제로 필요할 때 드문 경우에는 결코 해결되지 않습니다.

— jammycakes

"하나 이상의 특정 사용자 스토리를 구현하기 위해 필요한 경우 또는 단일 어셈블리로 측정 가능한 성능 문제가 발생하는 경우 (일반적으로 최대 수 메가 바이트 크기에 도달 한 경우)에만 분할하십시오." - 완전히 무작위가 아니라 현실의 조언에 근거

— hyankov

죄송하지만 정확히 "실제로 근거가없고 실제로는 근거가 없습니다"는 무엇입니까? 나는 당신이 그렇게 생각하는 것 이외의 다른 이유없이 필요 이상으로 더 많은 프로젝트로 분할 된 솔루션에 대해 수년간의 작업을 한 후에이 답변을 게시했습니다. 결과? 빙하 컴파일 시간과 의존성 지옥의 쇠약 (특히 NuGet 전). 물건을 별도의 조립품으로 나누는 데는 비용이 들며, 그 비용을 상쇄 할 수있는 이점이 없다면 비즈니스를 훔치는 경우 일뿐입니다.

— jammycakes

내가 함께 일하는 다른 안내 원리 :

다른 프로젝트에서이 코드를 재사용 할 것이라고 생각하십니까? 하나의 관련 웹 응용 프로그램 그룹에 대해 모든 응용 프로그램에서 사용하는 사용자 계정 관련 모듈이 하나있었습니다. 모두 사용자 계정과 로그인에 동일한 모델을 사용했기 때문입니다. 지오메트리 및 수학 라이브러리와 비슷한 작업을 수행하고 DLL을 포함하여 여러 응용 프로그램에서 재사용했습니다.
전체 프로젝트를 재배치 / 재 컴파일하지 않고이 코드를 수정 / 배포하고 싶습니까? 때로는 모듈을 다시 빌드하고 웹 응용 프로그램을 배포하고 다시 시작하는 것이 유용했습니다.

미래에는 기본 및 일반 리포지토리가 다시 유용 할 수있는 것처럼 들리지만 가능한 경우 새 DLL로 분리하는 것이 좋습니다.

— 좌절 된 폼 디자이너
소스

두 번째 요점이 정말 합리적이라고 생각합니다. 모듈로 나누면 개발 / 테스트 및 컴파일 시간이 도움이됩니다.

— WM