Microsoft MVP성태의 닷넷 이야기
.NET Framework: 277. F#과 WPF가 어울리지 못하는 근본적인 이유 [링크 복사], [링크+제목 복사],
조회: 26068
글쓴 사람
정성태 (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
정성태

... 136  137  138  139  140  141  142  [143]  144  145  146  147  148  149  150  ...
NoWriterDateCnt.TitleFile(s)
1479정성태8/14/201325070오류 유형: 183. IIS - 바인딩 추가 시 Object reference not set to an instance of an object 오류 [5]
1478정성태8/14/201328415오류 유형: 182. 윈도우 정품 활성화 오류 - 0x80070426
1477정성태8/14/201327247VC++: 71. codeplex의 Project Austin - 실감나게 책장 넘기는 표현
1476정성태8/13/201335727디버깅 기술: 55. Windbg - 윈도우 핸들 테이블 (2)
1475정성태8/12/201334842.NET Framework: 377. 프로세스가 종료된 후에도 소켓이 살아있다면?파일 다운로드1
1474정성태8/10/201330870오류 유형: 181. 윈도우 8 - WmiPrvSE.exe 프로세스가 CPU 소비하는 현상
1473정성태8/8/201327740VC++: 70. Win32 socket이 Thread-safe할까? [1]파일 다운로드1
1472정성태8/7/201326134.NET Framework: 376. .NET 2.0의 유니코드 관련 문자열 비교 오류
1471정성태8/7/201330938개발 환경 구성: 193. .aspx 확장자 대신 .html 확장자를 사용하는 방법
1470정성태8/6/201326897오류 유형: 180. DISM.exe 0xc1510111 실행 오류
1469정성태8/6/201323912.NET Framework: 375. System.Net.Sockets.Socket이 Thread-safe할까? [2]파일 다운로드1
1468정성태8/6/201322062오류 유형: 179. IIS - No connection could be made because the target machine actively refused it 127.0.0.1:80
1467정성태8/5/201325511Java: 16. IE에 로드된 Java Applet의 다운로드 위치를 확인하는 방법
1466정성태7/27/201331123.NET Framework: 374. C#과 비교한 C++ STL vector 성능 [7]파일 다운로드1
1465정성태7/18/201334420기타: 33. C:\Windows\Installer 폴더의 용량 줄이기 [3]
1464정성태7/15/201322695오류 유형: 178. Visual Studio 2012 Express - ImportCardinalityMismatchException
1463정성태7/15/201323368오류 유형: 177. [DBNETLIB][ConnectionOpen (Connect()).]SQL Server does not exist or access denied.
1462정성태7/5/201326640VC++: 69. geek스러운 C/C++ 퀴즈 문제 [2]
1461정성태6/27/201343190.NET Framework: 373. C# 문자열의 인코딩이란?
1460정성태6/17/201325056.NET Framework: 372. PerformanceCounter - Category does not exist. [1]
1459정성태6/15/201328769Windows: 74. 한글 키가 아닌 영문 키를 기본으로 선택하는 방법 [5]
1458정성태6/13/201329538.NET Framework: 371. CAS Lock 방식이 과연 성능에 얼마나 도움이 될까요? [1]파일 다운로드1
1457정성태6/13/201325742개발 환경 구성: 192. "Probabilistic Programming and Bayesian Methods for Hackers" 예제 코드 실행 방법
1456정성태6/5/201334370.NET Framework: 370. C# - WebKit .NET 사용 [2]파일 다운로드1
1455정성태6/1/201328216.NET Framework: 369. ThreadPool.QueueUserWorkItem의 실행 지연 [4]파일 다운로드1
1454정성태5/31/201326216Java: 15. Java 7 Control Panel 실행시키는 방법
... 136  137  138  139  140  141  142  [143]  144  145  146  147  148  149  150  ...