Microsoft MVP성태의 닷넷 이야기
.NET Framework: 277. F#과 WPF가 어울리지 못하는 근본적인 이유 [링크 복사], [링크+제목 복사],
조회: 26061
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 2개 있습니다.)

F#과 WPF가 어울리지 못하는 근본적인 이유

F# 언어를 요즘 틈틈이 보고 있는데요. 그러다 보니, F# 관련 블로그를 같이 읽게 되었는데 오늘은 다음의 글이 눈에 띄더군요.

XAML은 또 뭔가?
; http://fsharp.tistory.com/74

F#에서 WPF 및 그 외 모든 XAML 기반한 UI 프로그래밍을 지원하지 못하는 이유는 한마디로 F# 언어에 "partial" 키워드가 없기 때문입니다.

이해를 돕기 위해 C# 언어를 통해 partial 키워드가 어떤 것인지 한번 알아볼까요? 간단하게 다음과 같은 Test.cs 파일을 추가하고,

==== Test.cs ====

using System;

partial class Test
{
    public void DoMethod()
    {
        Console.WriteLine("DoMethod");
    }
}

다시, TestExtend.cs 파일을 다음과 같이 추가해 줍니다.

==== TestExtend.cs ====

using System;

partial class Test
{
    public void DoExtend()
    {
        DoMethod();
    }
}

이렇게 빌드하면 정상적으로 컴파일이 완료되는 것을 볼 수 있습니다. 즉, partial 키워드는 다중 cs 파일(Test.cs, TestExtend.cs)에 걸쳐서 정의된 클래스(class Test)를 단일하게 묶어서 빌드할 수 있도록 해줍니다.

왜 이런 키워드가 필요하느냐에 대해서는 두 가지 정도의 사례를 들어보면 쉽게 수긍이 갈 수 있습니다.

첫 번째는, '자동 생성된 코드'의 기능을 안전하게 확장하고 싶은 경우입니다.

Visual Studio에는 '서비스 참조'나 'Typed Dataset'과 같은 기능을 이용하는 경우 자동으로 생성해 주는 코드 파일들이 제공되는데, partial 키워드가 없을 때는 해당 코드 파일들에 정의된 클래스를 확장하고 싶은 경우 '상속'을 받아서 별도의 다른 cs 파일로 정의해 주어야 했습니다. 왜냐하면, 자동 생성된 파일을 임의로 변경하는 경우 다음번에 다시 자동 생성하는 절차를 거치면 개발자에 의해서 변경된 부분이 없어지기 때문입니다.

그렇다고 해서, '상속'이 근본적인 해결책이 되는 것도 아닙니다. 원래 생성된 클래스 명을 사용하면 안된다는 '표현할 수 없는 규칙'이 존재한다는 것도 우스운 일이고, 내부적으로 자동 생성된 코드의 private 필드를 접근해야 하는 경우 부득이 Reflection을 이용해야만 하는 불편함이 있습니다.

두 번째는, ASP.NET aspx 파일의 '디자인 타임 코드 생성'을 안전하게 처리할 수 있게 되었습니다. (이것은 WinForm 디자인에도 그대로 적용됩니다.)

"partial 키워드가 없던" 시절에는 aspx 페이지에 <asp:Button id="btn_Test" />라는 UI 요소를 추가하는 경우 aspx.cs 파일에 다음과 같은 식으로 임의로 '디자인 영역'임을 알리는 코드와 함께 이에 대한 변수 추가를 하는 식이었습니다.

public class TestPage : System.Web.UI.Page
{
    protected System.Web.UI.WebControls.Button btn_Test;
    
    private void Page_Load(object sender, System.EventArgs e)
    {
    }

    #region Web Form Designer generated code
    override protected void OnInit(EventArgs e)
    {
        //
        // CODEGEN: This call is required by the ASP.NET Web Form Designer.
        //
        InitializeComponent();
        base.OnInit(e);
    }
        
    /// 
    /// Required method for Designer support - do not modify
    /// the contents of this method with the code editor.
    /// 
    private void InitializeComponent()
    {    
        this.Load += new System.EventHandler(this.Page_Load);
    }
    #endregion
}

즉, 하나의 cs 파일에 정의된 클래스 코드 내부에 WebForm 디자이너의 변경 사항을 같이 반영하는 구조였습니다. 이 때문에 Visual Studio 2003 시절에, aspx 웹 페이지의 디자인 관련 코드들이 알 수 없는 이유로 날아간 '사용자 경험'을 하신 분들이 있었을 것입니다. 왜냐하면, 마이크로소프트 측의 개발자 입장에서도 무리하게 하나의 cs 파일에 '자동 변경되는 코드'와 '사용자의 수작업된 코드'를 적절하게 다룰 수 없어서 그러한 버그들이 발생한 것이었습니다.

하지만, partial 키워드의 도입으로 인해 이런 문제점이 깔끔하게 해결되었습니다. 사용자 코드는 .aspx.cs 파일에 작성하게 하고, 디자이너에서 변경되는 코드들은 .aspx.designer.cs에 반영하면 되었기 때문입니다. (어차피 빌드 과정에서 partial 키워드로 인해 하나의 클래스로 묶이게 되므로.)

결국, 과거(2003)/현재(2010) 버전의 Visual Studio에서 aspx 파일에 대해 생성되는 차이는 partial 키워드의 도입으로 발생한 변경이었습니다.

fs_xaml_1.png




partial은 Visual Studio의 XAML 디자이너에도 영향을 미칩니다.

fs_xaml_2.png

위의 예제로 설명해 보면, Visual Studio의 XAML 디자인 화면은 MainWindow.xaml 파일로 직렬화되고, 사용자 코드는 "MainWindow.xaml.cs" 파일에 포함됩니다. 그리고 MainWindow.xaml 파일은 빌드 시에 MainWindow.g.cs 파일로 변경되고, <Window x:Class="WpfApplication1.MainWindow" />에 따라 결국 다음과 같이 WpfApplication1.MainWindow 클래스의 partial로 정의됩니다.
==== MainWindow.g.cs ====
[System.CodeDom.Compiler.GeneratedCodeAttribute("PresentationBuildTasks", "4.0.0.0")]
public partial class MainWindow : System.Windows.Window, System.Windows.Markup.IComponentConnector {
        
    private bool _contentLoaded;

    ...[생략]...        
}

아울러 MainWindow.xaml.cs 파일에 포함된 사용자 코드 역시 partial 클래스로 제공되기 때문에 빌드 시에 2개의 코드는 하나의 클래스로 결합되어 동작을 하게 되는 것입니다.

namespace WpfApplication1
{
    /// 
    /// Interaction logic for MainWindow.xaml
    /// 
    public partial class MainWindow : Window
    {
        public MainWindow()
        {
            InitializeComponent();
        }
    }
}




이처럼, XAML 디자이너가 생성해 주는 코드가 partial class를 지원하기 때문에 F#에서는 자연스럽게 연동이 될 수 없는 구조가 되어버렸으며, 설령 partial class가 아니라고 해도 F# 코드와 연동하려면 Visual Studio 2003 시절처럼 하나의 코드 파일에 디자인 관련 코드를 함께 심어주어야 하는 구조로 가야 하는데 이는 또다시 이전의 알 수 없는 버그로의 회귀를 의미하게 됩니다.

partial 키워드의 부재로, XAML과 연동하기 위해 겨우 나온 해법이라면... C#과 섞어쓴다거나, xaml 자체를 로드해서 UI 템플릿으로만 사용하는 방법 등입니다.

Build MVVM Applications in F#
; https://learn.microsoft.com/en-us/archive/msdn-magazine/2011/september/fsharp-programming-build-mvvm-applications-in-fsharp

그나마 WebForm(aspx)의 경우에는 다행히 designer 코드만 partial로 되어 있을 뿐 aspx 파일 자체는 상속구조로 빌드되기 때문에 다음과 같이 CodeFile/Inhertis 속성을 바꾸는 것으로 해결되기는 합니다.

<%@ Page Language="F#" CodeFile="Default.aspx.fs" Inherits="FSharpWeb.Default" %>
<html>
    <body>
        <form runat="server">
            <asp:Button ID="btnTest" RunAt="server" Text="Click me!" OnClick="ButtonClicked" /><br />
            <asp:Label ID="lblResult" RunAt="server" />
        </form>
    </body>
</html>

하지만, ASPX 디자이너에서 Button/Label과 같은 UI 요소를 추가하는 것에 따른 변수 선언은 개발자가 직접 .fs 파일에 추가해 주어야 합니다.

이쯤에서 결론을 내리자면,,, XAML (및 WinForm/WebForm)과 자연스러운 연동을 원한다면, F#에서는 다음과 같은 식으로 partial 키워드가 추가되는 것이 가장 이상적인 해법이 됩니다.

partial type MainWindow =
    ...[생략]...

(그나저나... 표면상 partial 지원이 그리 어려워 보이지는 않은데, F#에서 이토록 업데이트를 하지 않는 이유가 궁금하군요. ^^)




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 1/9/2024]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 



2011-12-05 09시28분
[lancers] 무조건 MVVM을 쓰면 되겠군요! ㅋㅋㅋ
[guest]
2015-09-10 12시22분
Fun cross-platform graphics library, based on the Small Basic library, made specifically for F# and C#.
; https://github.com/ptrelford/FunSharp
정성태

... 61  62  63  64  65  66  67  68  69  70  71  72  73  [74]  75  ...
NoWriterDateCnt.TitleFile(s)
12086정성태12/20/201920915디버깅 기술: 144. windbg - Marshal.FreeHGlobal에서 발생한 덤프 분석 사례
12085정성태12/20/201918885오류 유형: 586. iisreset - The data is invalid. (2147942413, 8007000d) 오류 발생 - 두 번째 이야기 [1]
12084정성태12/19/201919314디버깅 기술: 143. windbg/sos - Hashtable의 buckets 배열 내용을 모두 덤프하는 방법 (do_hashtable.py) [1]
12083정성태12/17/201922289Linux: 27. linux - lldb를 이용한 .NET Core 응용 프로그램의 메모리 덤프 분석 방법 [2]
12082정성태12/17/201920555오류 유형: 585. lsof: WARNING: can't stat() fuse.gvfsd-fuse file system
12081정성태12/16/201922410개발 환경 구성: 465. 로컬 PC에서 개발 중인 ASP.NET Core 웹 응용 프로그램을 다른 PC에서도 접근하는 방법 [5]
12080정성태12/16/201919572.NET Framework: 870. C# - 프로세스의 모든 핸들을 열람
12079정성태12/13/201921457오류 유형: 584. 원격 데스크톱(rdp) 환경에서 다중 또는 고용량 파일 복사 시 "Unspecified error" 오류 발생
12078정성태12/13/201921243Linux: 26. .NET Core 응용 프로그램을 위한 메모리 덤프 방법 [3]
12077정성태12/13/201920344Linux: 25. 자주 실행할 명령어 또는 초기 환경을 "~/.bashrc" 파일에 등록
12076정성태12/12/201918868디버깅 기술: 142. Linux - lldb 환경에서 sos 확장 명령어를 이용한 닷넷 프로세스 디버깅 - 배포 방법에 따른 차이
12075정성태12/11/201919669디버깅 기술: 141. Linux - lldb 환경에서 sos 확장 명령어를 이용한 닷넷 프로세스 디버깅
12074정성태12/10/201919340디버깅 기술: 140. windbg/Visual Studio - 값이 변경된 경우를 위한 정지점(BP) 설정(Data Breakpoint)
12073정성태12/10/201920873Linux: 24. Linux/C# - 실행 파일이 아닌 스크립트 형식의 명령어를 Process.Start로 실행하는 방법
12072정성태12/9/201917670오류 유형: 583. iisreset 수행 시 "No such interface supported" 오류
12071정성태12/9/201921182오류 유형: 582. 리눅스 디스크 공간 부족 및 safemode 부팅 방법
12070정성태12/9/201923111오류 유형: 581. resize2fs: Bad magic number in super-block while trying to open /dev/.../root
12069정성태12/2/201919492디버깅 기술: 139. windbg - x64 덤프 분석 시 메서드의 인자 또는 로컬 변수의 값을 확인하는 방법
12068정성태11/28/201928159디버깅 기술: 138. windbg와 Win32 API로 알아보는 Windows Heap 정보 분석 [3]파일 다운로드2
12067정성태11/27/201919567디버깅 기술: 137. 실제 사례를 통해 Debug Diagnostics 도구가 생성한 닷넷 웹 응용 프로그램의 성능 장애 보고서 설명 [1]파일 다운로드1
12066정성태11/27/201919236디버깅 기술: 136. windbg - C# PInvoke 호출 시 마샬링을 담당하는 함수 분석 - OracleCommand.ExecuteReader에서 OpsSql.Prepare2 PInvoke 호출 분석
12065정성태11/25/201917537디버깅 기술: 135. windbg - C# PInvoke 호출 시 마샬링을 담당하는 함수 분석파일 다운로드1
12064정성태11/25/201920463오류 유형: 580. HTTP Error 500.0/500.33 - ANCM In-Process Handler Load Failure
12063정성태11/21/201919387디버깅 기술: 134. windbg - RtlReportCriticalFailure로부터 parameters 정보 찾는 방법
12062정성태11/21/201918891디버깅 기술: 133. windbg - CoTaskMemFree/FreeCoTaskMem에서 발생한 덤프 분석 사례 - 두 번째 이야기
12061정성태11/20/201919327Windows: 167. CoTaskMemAlloc/CoTaskMemFree과 윈도우 Heap의 관계
... 61  62  63  64  65  66  67  68  69  70  71  72  73  [74]  75  ...