지난 글에서는 CAG 응용 프로그램의 빌드 환경이 설정된 솔루션을 만들어 보았는데요.

.NET : 23.1 CAG - 빌드 환경 구성
; https://www.sysnet.pe.kr/2/0/689

이어서, 가장 간단한 유형의 CAG Shell 응용 프로그램을 띄워보겠습니다. 이번 글도 역시 다음 글에서 소개된 내용의 후반부를 다룹니다.

Composite Application Guidance for WPF - June 2008
How to: Create a Solution Using the Composite Application Library
; https://docs.microsoft.com/en-us/previous-versions/msp-n-p/ff921345(v=pandp.10)

---

WPF 프로젝트에 기본 추가된 Window1 클래스의 이름 및 파일 이름을 모두 Shell로 변경하고, App.xaml 파일을 열어서 Application[@StartupUri] 속성을 제거합니다. (왜냐하면, 나중에 프로그램 코드에서 Shell 타입을 직접 로드하는 코드를 추가합니다.)

=== Shell.xaml.cs ===
public partial class Shell : Window
{
    public Shell()
    {
        InitializeComponent();
    }
}

=== App.xaml ===
<Application x:Class="DevToolManager.App"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
    <Application.Resources>
         
    </Application.Resources>
</Application>

이제, Shell 영역에서 User Control로 만들어진 View들이 활성화될 "Region"을 정의합니다. 이 구역은 향후에 제작될 View들이 위치하게 될 영역인데, 현재는 별다른 View가 정의되지 않을 것이기 때문에 다음과 같은 식으로 다소 "의미 없이" Region을 마음대로 설정해 보겠습니다.

<Window x:Class="DevToolManager.Shell"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:cal="http://www.codeplex.com/CompositeWPF"
    Title="Shell" Height="300" Width="300">

    <Grid>
        <Grid.RowDefinitions>
            <RowDefinition></RowDefinition>
            <RowDefinition></RowDefinition>
        </Grid.RowDefinitions>
    
        <ItemsControl cal:RegionManager.RegionName="MainRegion" />
        <ContentControl Grid.Row="1" cal:RegionManager.RegionName="StatusRegion" />
    </Grid>
</Window>

Region이라 해서 특별하게 생각하기 보다는 단순히 View가 활성화될 Container용 UserControl이라고 생각하시면 편하겠습니다.


보통 WPF 응용 프로그램의 시작점이 App.xaml의 StartupUri 속성에 지정된 타입인 반면, CAG에서는 이것을 Bootstrapper 타입에서 결정합니다. 물론, 이름이야 바꿀 수 있겠지만, CAG의 기존 클래스명이 그러하니 아래에서도 그대로 정의해 보았습니다.

=== Bootstrapper.cs 파일 추가 ====

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.Practices.Composite.UnityExtensions;
using System.Windows;

namespace DevToolManager
{
    public class Bootstrapper : UnityBootstrapper
    {
        protected override DependencyObject CreateShell()
        {
            Shell shell = Container.Resolve<Shell>();
            shell.Show();
            return shell;
        }
    }
}

Bootstrapper를 완성했으니, 이를 이용해서 직접 Shell을 구동해야 할텐데요. 그냥... App.OnStartup에서 이 작업을 해주면 되겠습니다.

namespace DevToolManager
{
    public partial class App : Application
    {
        protected override void OnStartup(StartupEventArgs e)
        {
            base.OnStartup(e);

            Bootstrapper bootstrapper = new Bootstrapper();
            bootstrapper.Run();
        }

    }
}

사실, 지금까지의 코드를 보면 단순히 Shell 타입을 App.StartupUri 속성에 지정하지 않고 수동으로 로드시키는 작업과 비교해보면 크게 다르지 않습니다. CAG 응용 프로그램에서의 차별화된 점이라면, 여기서 반드시 UnityFramework에 의해서 "관리"를 받게 될 모듈들을 정의해야 한다는 제약이 있습니다. (그렇지 않으면 실행 시에 모듈이 지정되지 않았다는 런타임 오류가 발생합니다.)

모듈을 로드하는 방식은 다음과 같이 4가지로 다양하게 준비되어 있습니다.

• 코드로 모듈 추가: 코드 상에서 직접 대상 모듈을 추가한다. 물론, 이런 경우 해당 어셈블리에 대한 정적 참조를 하고 있어야 한다.
• XAML 파일에서 모듈 추가: ModuleCatalog.xaml을 이용하여 추가될 모듈 정의
• App.Config에서 모듈 추가
• 디렉터리에서 모듈 추가: 모듈을 담고 있는 어셈블리가 있는 폴더를 지정

프레임워크에 포함될 기반 라이브러리는 어차피 참조를 해서 관리를 하는 것이 편하기 때문에 그런 경우에는 코드로 모듈을 추가하면 되지만, 그 이외의 업무를 담당하는 어셈블리들은 ModuleCatalog.XAML 또는 app.config에 모듈을 추가하면 됩니다. 상식이라고 생각되긴 하지만, 혹시나 싶어 한마디 하자면, 절대 (사실 절대까지는 아니지만!) 업무용 어셈블리를 참조 추가해서 코드상에서 모듈을 추가하지 마십시오. 당장 지금 편하다고 해서 코드로 모듈을 추가하는 것은 나중에 프로젝트 규모가 커지면 사실상 "참조 지옥(Circular Reference Hell)"을 불러일으키기 때문입니다.

일단, 나중에 바꾸겠지만 별다르게 모듈이 정의되지 않은 현재 상태에서 런타임 오류를 없애기 위해 디렉터리를 지정함으로써 모듈을 추가하는 방식을 사용하는 코드를 추가하겠습니다. 코드 정의는 다음과 같이 "Bootstrapper" 타입 안에서 GetModuleCatalog를 재정의하는 것으로 완료됩니다.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.Practices.Composite.UnityExtensions;
using System.Windows;
using Microsoft.Practices.Composite.Modularity;
using System.IO;

namespace DevToolManager
{
    public class Bootstrapper : UnityBootstrapper
    {
		...[중간생략]...

        protected override Microsoft.Practices.Composite.Modularity.IModuleCatalog GetModuleCatalog()
        {
            string modulePath = @".\Modules";
            if (Directory.Exists(modulePath) == false)
            {
                Directory.CreateDirectory(modulePath);
            }
            
            return new DirectoryModuleCatalog() { ModulePath = modulePath };
        }
    }
}

오늘은 여기까지만!

*** 첨부된 압축 파일은, 위의 과정을 완료한 예제 솔루션입니다.

---

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

[최초 등록일: 4/6/2009]
[최종 수정일: 7/17/2021]


이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

by SeongTae Jeong, mailto:techsharer at outlook.com