•  03-07-2019
  •  | 
  •  

문제

WebForms/WinForms 생성 코드 시나리오 외부에 부분 클래스를 잘 사용합니까? 아니면이 기능이 기본적으로이를 지원 하는가?

도움이 되었습니까?

해결책

생성 된 코드를 프로그래머 코드와 믹싱하는 시나리오 (Webforms, Winforms, Linq-to-SQL 등)를 지원하는 것이 부분적입니다.

그것을 사용해야 할 이유가 더 있습니다. 예를 들어, 대형 다루기 쉬운 파일에 큰 클래스가 있지만 클래스에 논리적으로 관련된 방법 그룹이있는 경우 부분 클래스는 파일 크기를보다 관리하기 쉽게 만드는 옵션 일 수 있습니다.

다른 팁

코드 생성은 부분 클래스의 원동력이었습니다. 필요는 끊임없이 변화하는 코드 생성 클래스를 갖추고 있지만 개발자는 클래스를 재생성 할 때마다 무시되지 않는 클래스의 일부로 사용자 정의 코드를 제공 할 수 있습니다.

예를 들어 Winforms 또는 유형-다타타 세트 (또는 해당 문제에 대한 디자이너)를 사용하십시오. 디자이너를 변경할 때마다 해당 코드를 파일로 직렬화합니다. 발전기가 알지 못하는 몇 가지 추가 방법을 제공해야한다고 가정 해 봅시다. 생성 된 파일에 추가하면 다음에 생성 될 때 변경 사항이 손실됩니다.

현재 작업하고있는 프로젝트는 모든 DAL, BLL 및 비즈니스 엔티티에 코드 생성을 사용합니다. 그러나 생성기는 정보의 75% 만받습니다. 나머지 부분은 손으로 코딩되어야합니다 (예 : 사용자 정의 비즈니스 로직). 모든 BLL 클래스에 선택 방법이 있다고 가정 할 수 있으므로 생성하기 쉽습니다. 그러나 내 고객 BLL에는 SelectAllByLocation 메소드도 있어야합니다. 모든 BLL 클래스에 일반적이지 않기 때문에 이것을 발전기에 넣을 수는 없습니다. 따라서 모든 클래스를 부분 클래스로 생성 한 다음 별도의 파일에서 사용자 정의 메소드를 정의합니다. 이제 구조가 변경되거나 어떤 이유로 든 BLL을 재생해야 할 때 내 사용자 정의 코드가 사라지지 않습니다.

나는 내가 쓰는 사용자 정의 컨트롤의 다른 하위 요소를 분리하는 수단으로 부분 클래스를 사용합니다. 또한 Entity Creation 소프트웨어와 함께 사용될 때 LLBLGEN과 같은 제품은 생성 된 버전의 클래스 및 사용자 정의 사용자 편집 버전을 만들 수 있으며 엔티티를 재생 해야하는 경우 교체되지 않습니다.

나는 종종 부분 클래스를 사용하여 각 중첩 클래스에 자체 파일을 제공합니다. 대부분의 구현이 한 클래스에서만 요구되는 곳에 대해 작업 한 아키텍처가 있었으므로 해당 클래스에서 해당 클래스를 중첩했습니다. 부분 클래스 능력을 사용하고 각각의 파일을 자체 파일로 분할하여 파일을 더 쉽게 유지할 수 있도록하는 것이 합리적이었습니다.

또한 재고 재정의 그룹화 또는 재고 부동산의 숨기기에도 사용했습니다. 그런 것들. 주식 변경을 혼합하는 편리한 방법입니다 (파일을 복사하고 부분 클래스 이름을 대상 클래스로 변경하십시오. 대상 클래스도 부분적으로 만들어지는 한).

부분 클래스에 대한 또 다른 사용은 조건부 편집을 사용하여 방법을 선택적으로 사라지는 부분 방법을 활용하는 것입니다. 디버그 모드 진단 코드 또는 특수 단위 테스트 시나리오에 좋습니다.

초록 방법과 같은 부분 방법을 선언 한 다음 다른 부분 클래스에서 키워드 "부분"을 입력하면 지능을 활용하여 해당 방법의 구현을 만들 수 있습니다.

조건부 빌드 명령문으로 한 부분을 둘러싸면 디버그 전용 또는 테스트 코드를 쉽게 차단할 수 있습니다. 아래의 예에서 디버그 모드에서 LogsomethingDeBugonly 메소드가 호출되지만 릴리스 빌드에서는 메소드가 전혀 존재하지 않는 것과 같습니다. 진단 코드가 생산 코드에서 멀리 떨어지지 않는 좋은 방법입니다. 여러 조건부 컴파일 블록.

// Main Part
public partial class Class1
{
    private partial void LogSomethingDebugOnly();

    public void SomeMethod()
    {
        LogSomethingDebugOnly();
        // do the real work
    }
}

// Debug Part - probably in a different file
public partial class Class1
{

    #if DEBUG

    private partial void LogSomethingDebugOnly()
    {
        // Do the logging or diagnostic work
    }

    #endif
}

LINQ에서 SQL은 부분 클래스를 잘 사용하여 디자이너 생성 코드를 확장합니다. 일반적으로 디자이너가 만든 코드가 사용하는 부분 클래스 패턴을 찾을 수 있다고 생각합니다.

부분 수업이 매우 도움이된다고 생각합니다. 일반적으로자가 생성 클래스를 확장 할 수 있습니다. 나는 하나의 프로젝트에서 무거운 단위 테스트로 그것들을 사용했습니다. 내 UT 클래스는 복잡한 종속성을 가졌으며 여러 클래스에서 코드를 분리하는 것은 매우 실용적이지 않았으며, 물론 상속 구성을 사용하는 것이 좋습니다. 그러나 경우에 따라 부분 클래스가 도움이 될 수 있습니다.

앞에서 언급했듯이, 나는 이것이 코드 냄새라고 생각합니다.

클래스가 너무 커서 더 많은 파일로 분할해야한다면, 단일 책임 원칙을 위반하고 너무 많은 일을하고 있음을 의미합니다. 큰 계급은 함께 협력하는 작은 계급으로 나눌 수 있습니다.

코드를 구성하기 위해 부분 클래스 나 지역을 사용해야하는 경우 코드가 자신의 클래스에 있어야하는지 고려하십시오. 가독성이 높아지고 더 많은 코드 재사용이 발생합니다.

어쩌면 너무 늦었지만 2 센트를 추가하도록 해주세요.

*. 대규모 프로젝트를 수행 할 때 별도의 파일에 클래스를 전파하면 여러 프로그래머가 동시에 작업 할 수 있습니다.

*. vs.net 생성 클래스에 대한 코드 (확장 된 기능)를 쉽게 작성할 수 있습니다. 이를 통해 시스템 생성 코드를 엉망으로 만들지 않고 자신의 요구 코드를 작성할 수 있습니다.

내가있는 곳에는 고객의 들어오는 파일을 처리하는 프로그램이 있습니다. 각 고객의 코드가 자체 클래스 라이브러리 프로젝트에 있도록 설정되어 클라이언트가 사용하기로 선택한 형식을 처리하는 방법을 알고 있습니다.

기본 코드는 라이브러리의 클래스가 구현 해야하는 상당히 광범위한 인터페이스를 정의하여 라이브러리를 사용합니다 (아마도 몇 가지 뚜렷한 인터페이스이어야하지만 지금 변경하기에는 너무 늦었을 것입니다). 때때로 그것은 우리가 일반적으로 신중하게 생각하는 것보다 같은 클래스에서 훨씬 더 많은 코드를 포함합니다. 부분 수업을 통해 우리는 그것들을 다소 분해 할 수 있습니다.

비교적 복잡한 UserControls에서는 이벤트 처리 항목을 하나의 파일과 그림 및 속성을 다른 파일에 넣었습니다. 부분 수업은 이것에 적합합니다. 일반적으로 클래스의 이러한 부분은 비교적 독립적이며 그림과 이벤트 처리를 나란히 편집 할 수있어서 좋습니다.

나는 몇 년 전 프로젝트에서 작업을 수행했으며, 이에 따라 많은 코드가있는 유형의 데이터 세트 클래스가 있습니다. 데이터블의 메소드, 태블라단의 메소드, Tableadapter 인스턴스의 선언 등 이름을 지정했습니다. 모든 사람들이 자주 작업 해야하는 것은 프로젝트의 중심적인 점이었습니다. 부분 클래스 코드 파일에 대해 많은 소스 제어 경합이있었습니다.

그래서 코드 파일을 기능별로 그룹화 한 6 개의 부분 클래스 파일로 나누어 작은 조각으로 작업 할 수 있고 작은 것을 변경해야 할 때마다 전체 파일을 잠글 필요가 없습니다.

(물론, 우리는 독점적으로 잠금 소스 제어 시스템을 사용하지 않음으로써 문제를 해결할 수 있었지만 그것은 또 다른 문제입니다.)

일반적으로 나는 그것을 코드 냄새라고 생각합니다.

수업이 그렇게 복잡하다면 아마도 작은 재사용 가능한 구성 요소로 나눌 수 있습니다.

또는 그것은 하나가 있어야하는 상속 계층이 없다는 것을 의미합니다.

코드 생성 시나리오의 경우 좋지만 코드 생성은 또 다른 코드 냄새라고 생각합니다.

나는 게임에서 늦었다 ...하지만 2 센트 만 ...

하나의 용도는 기존 레거시 코드 기반의 기존 God 클래스를 여러 부분 클래스에 리팩터링하는 것입니다. 부분 클래스가 포함 된 파일 이름에 대해 적절한 명명 규칙을 따르는 경우 코드의 발견 가능성을 향상시킬 수 있습니다. 또한 소스 코드 리포지토리를 줄일 수 있습니다.

이상적으로는 신의 수업은 여러 개의 작은 클래스로 분류되어야합니다. 때로는 중간에서 큰 리팩토링을 수행하는 것이 방해가됩니다. 그러한 경우 부분 수업은 일시적인 구제를 제공 할 수 있습니다.

Matt가 지적한 것처럼 교정은 부분의 양쪽이 같은 어셈블리에 있어야합니다. 내 잘못이야.

데이터 액세스 계층에서 사용합니다. Mapper와 같은 생성 된 클래스는 부분적으로 쿼리합니다. 생성되지 않은 멋진 하중을 수행하기 위해 매퍼 방법을 추가 해야하는 경우 사용자 정의 클래스에 추가하십시오.

결국 비즈니스 계층의 데이터 계층을 사용하는 프로그래머는 필요한 모든 기능만으로 하나의 클래스 만 볼 수 있습니다. 데이터 소스가 변경되면 사용자 지정 내용을 덮어 쓰지 않고 일반 부품을 쉽게 생성 할 수 있습니다.

방금 부분 수업에 사용되는 것을 찾았습니다. 데이터를 클라이언트에게 전달하는 데 사용하는 [DataContract] 클래스가 있습니다. 클라이언트가 특정 방식으로 클래스를 표시 할 수 있기를 원했습니다 (텍스트 출력). 그래서 부분 클래스를 만들고 Tostring 메소드를 무시했습니다.

때로는 직장에서 끔찍한 오래된 코드를 찾을 수있어 기존 코드를 깨지 않고 고유 한 요소로 리팩터링하는 것이 불가능할 수 있습니다.

보다 진정한 아키텍처를 만들 수있는 옵션이나 시간이 주어지지 않으면 부분 수업을 통해 필요한 곳에서 논리를 분리하기가 매우 쉽습니다. 이를 통해 기존 코드는 동일한 아키텍처를 계속 사용할 수 있으며보다 구체적인 아키텍처에 한 걸음 더 다가 갈 수 있습니다.

당신이 사용한 모든 곳 #region 이전 섹션은 아마도 부분 클래스에서 별도의 파일로 더 의미가 있습니다.

나는 정적 멤버가 한 파일로 들어가고 인스턴스 멤버가 다른 파일에 들어가는 큰 수업에 개인적으로 부분 수업을 사용합니다.

편집 : Visual Studio 용 DSL 도구는 부분 클래스를 사용합니다.

따라서 많은 자동 생성 코드가 사용하는 기능입니다. #영역을 사용하는 대신 자동 생성 된 코드는 한 파일로 이동하고 사용자 코드 (사용자 정의 코드라고도 함)는 다른 디렉토리로 이동하여 개발자가 무의미한 파일과 혼동되지 않도록합니다.

당신이 결합 할 수있는이 선택을하는 것이 좋지만 상속을 사용하여 사용하지 않아도됩니다.

또한 여러 디렉토리 중 일부 클래스의 논리를 분리하는 것이 유용 할 수 있습니다. 물론 기계의 경우 동일하지만 사용자 가독성 경험을 향상시킵니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top