버튼 클릭 이벤트의 코딩 표준

Question

기본 버튼 클릭 이벤트에 코드를 첨부 할 때 좋은 코딩 표준을 따르려고합니다. 두 가지 옵션은 다음과 같습니다. Click 이벤트 처리기 또는에 여러 줄의 코드를 포함 시키면 결국 이러한 코드 줄과 동일한 작업을 수행 할 수 있습니다.

소프트웨어 설계 원칙은 무엇입니까? 또는 왜 어떤 방식 으로든 사용하려는 이유에 대한 구체적인 추론은 무엇입니까?

[또한, 단지 약간 연장지고 기존 표준 윈폼 애플리케이션이다.]

옵션 A :

private void btnExport_Click(object sender, EventArgs e) 
{ 
    var FileName = getFileName(reportPrefix); 

    if (fileName == null)    
    { 
     return; 
    } 

    SaveFile(fileName, QueryString); 
} 

옵션 B :

private void btnExport_Click(object sender, EventArgs e) 
{ 
    DoExport();   
} 


private void DoExport() 
{ 
    var FileName = getFileName(reportPrefix); 

    if (fileName == null)    
    { 
     return; 
    } 

    SaveFile(fileName, QueryString); 

} 

Answer 1

옵션을 권하고 싶습니다. 다음과 같은 이유로 B :

1. 우려의 분리 : 실제 작업을 수행하고 다른 방법으로 캡슐화되는 실제 구현 로직로 구분되는 이벤트 (이벤트 핸들러) 또는 대리인 운반되는 코드 .

2. DoExport의 의도는 그 이름에서 분명합니다. 누군가 코드를 읽으면

   옵션 B :"단추를 클릭 할 때 내보내기"로 해석됩니다.
   옵션 A :"버튼을 클릭하면 fileName이 인 경우 파일 이름을 읽은 다음 반환하고 파일을 저장하십시오."

   어느 것이 읽기 쉬울까요? 가독성 목적으로 옵션 B는 의도를 명확하고 간결하게 표현한 방법을 제공합니다.

3. button을 anchor, linkButton, Label 또는 다른 컨트롤과 같은 다른 컨트롤로 변경하려는 경우 구현 세부 정보와 이벤트 핸들러를 바인딩 할 필요가 없습니다. DoExport 메소드는 EventArgs' or the 발신자`객체에 의존해서는 안됩니다.

4. 나중에 코드의 다른 위치에서 내보내기 기능 (DoExport)을 호출해야합니다. 그런 다음 DoExport 방법으로 쉽게 전화 할 수 있습니다.

5. 테스트 :이 메서드는 공개로 테스트하려는 경우. 이벤트를 발생시키고 기능을 테스트하기 위해 코드를 작성하는 것보다 메소드를 테스트하는 것이 훨씬 쉽습니다.

Answer 2

어느 쪽도 있지만, B는 가장 가까운 :

SRP (단일 책임 원칙)는 UI에서 비즈니스 로직을 분리뿐만 아니라 방법의 수준에서,하지만 것을 추천 적어도 클래스 레벨 (네임 스페이스 및/또는 라이브러리 레벨 분리도 유용 할 수 있습니다). 이것은 UI가 내보내기 논리의 변경과 독립적으로 변경 될 가능성이 있기 때문입니다.

btnExport_Click이 포함 된 UI 클래스는 UI를 구동하고 데이터를 사용자에게 표시하고 클릭과 같은 사용자 상호 작용을 비즈니스 논리로 라우팅합니다.

public class YouUIClass 
{ 
    IExporter exporter; 

    private void btnExport_Click(object sender, EventArgs e) 
    { 
     var fileName = GetFileName(reportPrefix); 

     if (fileName == null)    
     { 
      return; 
     } 
     exporter.DoExport(fileName);   
    } 
} 

public class Exporter : IExporter 
{ 
    public void DoExport(string fileName) 
    { 
     SaveFile(fileName, queryString); 
    } 
} 

(당신은 filename과 같은 몇 가지 인수를 전달해야 할 수 있습니다 또는 :

그리고 다른 클래스가 완전히, 바람직하게는 추상화 뒤에, 인터페이스가 이상적이다는 (DIP는 종속성 반전 원리), 수출에 대한 책임 내가 GetFileName이 UI라고 가정했기 때문에 UI에서 수출 방법으로 queryString을 보여주었습니다.

큰 이점 중 하나는 UI가 관련없이 비즈니스 논리를 테스트 할 수 있다는 것입니다. 수동 테스트는 UI가 이벤트를 후속 레이어로 올바르게 전달하는지 확인하는 것입니다.

이런 방식으로 UI를 분리 할 때 MVC, MVP & MVVM과 같은 패턴을 롤링하는 대신이 접근법을 따라갈 수있는 패턴이 있습니다.