CLIEL LAB

무차별 대입 공격 방어 도구 (Brute Force Attack Depend Tool) - Ban_Server

클리엘 — Fri, 16 Jan 2026 09:48:42 +0900

Remote Desktop의 경우 원격 port는 3389, MS-SQL Server의 경우 1433이 기본 port입니다. 그런데 server를 외부에서 접속 가능하도록 두면 이 2개 port에 대해서 무차별 대입 공격이 발생함을 알 수 있습니다.

For Remote Desktop, the default remote port is 3389, and for MS-SQL Server, it is 1433. However, if you leave the server accessible from outside, you can see that brute-force attacks occur on these two ports.

port번호를 바꾸면 일시적으로는 공격 빈도가 줄지만 시간이 지나면 다시 공격이 되살아나서 별 의미가 없습니다. 때문에 접속 가능한 IP만 제한적으로 열어두는 것이 제일 좋은데 만약 접속을 허용하는 IP만 특정할 수 없는 경우라면 해결 방법을 달리해야 합니다.

Changing the port number may temporarily reduce the frequency of attacks, but over time, the attacks will resume, making it largely ineffective. Therefore, the best approach is to restrict access to only specific IP addresses. If it is not possible to specify the exact IP addresses allowed for access, an alternative solution must be implemented.

무차별 대입 공격에 대응할 수 있는 방법이야 여러가지로 존재할테지만 그 방법중의 하나로 Ban_Server와 Ban_MSSQL을 소개하고자 합니다. Ban_Server는 Windows Server에서 원격제어를, Ban_MSSQL은 MSSQL Server의 전용port로 무단 접속을 시도하면 이와 관련된 Log를 만들때 이를 감지하고 공격자의 IP를 차단하는 역활을 수행합니다.

There are various methods to counter indiscriminate brute-force attacks, and among them, we introduce Ban_Server and Ban_MSSQL. Ban_Server detects unauthorized attempts to remotely control Windows Server and Ban_MSSQL detects unauthorized attempts to connect to the dedicated port of MSSQL Server. When creating logs related to these attempts, they perform the role of detecting them and blocking the attacker's IP address.

1. 설치방법

1. Installation Method

우선 Microsoft의 아래 homepage에서 Console Application용으로 .NET 10 Runtime을 내려받아 설치합니다.

First, download and install the .NET 10 Runtime for Console Applications from the Microsoft homepage below.

.NET 10.0 런타임 다운로드

.NET 10.0 런타임에는 기존 .NET 및 ASP.NET Core 애플리케이션을 실행하는 데 필요한 모든 것이 포함됩니다.

dotnet.microsoft.com

.NET 10 Runtime 설치를 하고 나면 아래 file을 내려 받고 file을 server의 임의폴더에 풀어줍니다.

After installing the .NET 10 Runtime, download the file below and extract it to any folder on the server.

Ban.zip

0.40MB

압축을 풀고나면 Ban_Server와 Ban_MSSQL 2개의 folder가 있는지 확인하고 각각의 폴더를 원하는 위치로 옮겨줍니다. 만약 REMOTE와 MSSQL을 모두 사용할 필요가 없다면 필요한 것만 사용하고 다른건 삭제해도 됩니다.

After unzipping, verify that the Ban_Server and Ban_MSSQL folders are present, then move each folder to your desired location. If you do not need to use both REMOTE and MSSQL, you may use only the necessary one and delete the other.

이제 ask Scheduler를 등록해야 하는데 우선 Remote Desktop에 대응할 Task Scheduler부터 등록합니다. 이를 위해 Control Panel -> Administrative Tools -> Task Scheduler를 실행하여 아래 제시된 방법으로 Task Scheduler를 등록합니다.

You must now register the Scheduler. Begin by registering the Task Scheduler for Remote Desktop. To do this, run Control Panel -> Administrative Tools -> Task Scheduler and register the Task Scheduler using the method described below.

오른쪽의 Create Task를 선택합니다.

Select Create Task on the right.

Name에 Ban_REMOTE를 입력하고 아래 Security Options에는 'Run whether user is logged on or not'을 선택합니다. 이때 Name은 해당 Task Scheduler가 어떠한 목적으로 만들어졌는지를 구분할 수 있을 정도면 다른 이름을 지정할 수도 있습니다.

Enter Ban_REMOTE in the Name field and select ‘Run whether user is logged on or not’ under Security Options. At this point, you can assign a different name to the Task Scheduler as long as it clearly indicates the purpose for which it was created.

다음으로 Trigger Tab으로 이동해 Begin the task에 'On an event'를 선택하고 Log에는 Security를 Event ID로는 4625를 입력합니다.

Next, go to the Trigger tab, select ‘On an event’ for Begin the task, and enter Security for Log and 4625 for Event ID.

Actions tab에서는 Action에 'Start a program'을 선택하고 Program/script에 Ban_Server.exe를 명시한 뒤 Start in (optional)에 Ban_Server.exe가 존재하는 folder를 지정합니다.

In the Actions tab, select ‘Start a program’ for Action, specify Ban_Server.exe in Program/script, and then designate the folder where Ban_Server.exe is located in Start in (optional).

이것으로 REMOTE(Ban_Server)에 대한 Task Scheduler을 완료하였습니다. 같은 방법으로 MSSQL에 관한 event로 등록해 줘야 하는데 위의 설정과정 대부분이 동일합니다. 다만 MSSQL의 경우 Trigger에서 Log를 Application을 잡고 Event ID를 18456으로 해야 합니다.

This completes the Task Scheduler setup for REMOTE(Ban_Server). You must register the event for MSSQL using the same method; most of the configuration steps above are identical. However, for MSSQL, you must set the Application in the Trigger to Log and the Event ID to 18456.

2. 사용방법

2. How to Use

압축을 풀어놓은 folder를 보면 jsconfig.json이라는 이름의 file을 볼 수 있습니다. 해당 file을 아래 내용으로 구성되어 있습니다.

When you unzip the folder, you will find a file named jsconfig.json. This file is structured as follows:

{
"FailedCount": 1,
"WhiteLists": []
}

FailedCount는 실패한 건수에 대한 대응입니다. 동일한 IP에 대하여 설정한 횟수 이상의 접속실패건이 발생하는 경우에만 해당 IP를 방화벽에 등록하여 차단을 수행하도록 합니다.

FailedCount corresponds to the number of failures. Only when the number of connection failures exceeds the set limit for the same IP address will that IP be registered in the firewall and blocked.

WhiteLists는 Ban_Server.exe가 예외로 둘 IP를 지정하는 곳입니다.

WhiteLists is where Ban_Server.exe specifies the IP addresses to be treated as exceptions.

{
"FailedCount": 1,
"WhiteLists": ["192.168.10.1", "192.168.10.2"]
}

따라서 만약 위와 같이 '192.168.10.1'과 '192.168.10.2'의 IP를 등록했다면 해당 IP에 대해서만 접속실패가 발생하더라도 차단방화벽의 IP로 등록하지 않습니다.

Therefore, if you have registered the IP addresses ‘192.168.10.1’ and ‘192.168.10.2’ as described above, even if access failures occur only for those specific IPs, they will not be added to the firewall's blocked list.

3. 기타

3. Other

Ban_Server는 Open source project이며 Git을 통해 source를 살펴보고 변경할 수 있습니다.

Ban_Server is an open-source project, and you can view and modify the source code via Git.

cliel/Ban_Server: 무차별 대입 공격 방어(Brute Force Attack Defend) (github.com)

GitHub - cliel/Ban_Server: 무차별 대입 공격 방어(Brute Force Attack Defend)

무차별 대입 공격 방어(Brute Force Attack Defend). Contribute to cliel/Ban_Server development by creating an account on GitHub.

github.com

※ 해당 프로그램 사용으로 인한 부작용에 대해서는 책임지지 않습니다.

※ We are not responsible for any adverse effects resulting from the use of this program.

※ json에서 FailedCount는 정확성을 보장하지 않습니다. FailCount를 3으로 하면 "3번 실패 시 작동한다."가 아니라 "3번 이상 실패 시 작동한다"쯤으로 해석해야 합니다. LOG를 읽고 program이 동작하는 시점에 다시 공격이 들어올 수 있는 등 여러 가지 예외 사항이 발생하므로 IP가 Block 완료될 때쯤 실제 공격은 3회 이상으로 이루어질 수 있습니다.

※ The FailedCount in JSON does not guarantee accuracy. Setting FailCount to 3 should be interpreted as “activates after 3 or more failures,” not “activates after exactly 3 failures.” Various exceptions can occur, such as attacks resuming while the program is processing logs. Therefore, by the time the IP is fully blocked, the actual attack may have occurred more than three times.

※ Ban_Server는 Windows Server상의 EventLog를 기반으로 동작합니다. Log가 많이 쌓아두면 그 만큼 처리하는데 시간이 오래 걸릴 수 있으며 Log의 관리특성에 따라 원하는 방향으로 프로그램이 동작하지 않을 수 있기 때문에 적절한 관리가 필요합니다.

※ Ban_Server operates based on the EventLog on Windows Server. If logs accumulate excessively, processing may take longer, and depending on log management characteristics, the program may not function as intended. Therefore, proper management is required.

Hyper-V Virtual Machine상에서 Docker실행하기

클리엘 — Sat, 4 May 2024 16:53:25 +0900

일단 Virtual Machine상에서 Docker를 설치할 때 설치 option에서 Hyper-V대신 WSL(Windows Subsystem Linux)을 사용한다는 설정이 있습니다. 이 설정을 제외하고 설치합니다.

그런 뒤 Docker를 실행하면 다음과 같은 오류를 볼 수 있는데

말이 길지만 내용은 BIOS상에서 가상화를 설정해야 한다는 것입니다. 하지만 Hyper-V의 Virtual Machine에서 BIOS를 제한적일 수밖에 없습니다. 이 문제를 해결하려면 Virtual Machine를 끈뒤 Host Machine상에서 관리자 권한으로 PowerShell를 실행하고 아래 명령을 통해 Virtual Machine의 가상화를 설정해 줘야 합니다.

Set-VMProcessor -VMName Windows11 -ExposeVirtualizationExtensions $true

위 명령에서 Windows11은 Virtual Machine의 이름입니다. Virtual Machine의 이름에 'Windows 11'처럼 공백이 있으면 오류가 날 수 있으므로 공백을 없애주는 것이 좋습니다.

[C# 12와 .NET 8] 11. LINQ

클리엘 — Mon, 11 Mar 2024 12:04:55 +0900

LINQ(Language INtegrated Query)는 일련의 data를 대상으로 filtering 및 sorting 하고 다른 형태로 결과를 투영할 수 있는 언어확장 도구입니다.

1. 왜 LINQ인가?

(1) 명령형및 선언형 언어의 비교

LINQ는 2008년 .NET 3.0과 .NET Framework 3.0과 함께 도입되었습니다. 그전에 C#및 .NET개발자는 명령형이라고 하는 절차적 code문을 사용해 예를 들어 loop처럼 일련의 item들을 처리하곤 했습니다.

첫 번째 item에 대한 현재 위치를 설정합니다.
지정한 값과 하나 또는 그 이상의 속성을 비교 비교하여 예를 들어 가격이 50 이상이어야 한다거나 수량이 동일한지등과 같은 경우처럼 처리해야 하는 item인지를 확인합니다.
2번에서 조건과 일치하는 경우라면 item을 처리합니다. 예를 들어 사용자에게 하나 또는 그 이상의 속성을 표시하거나 새로운 값으로 update 할 수 있고 또는 item을 제거하거나 counting과 summing처럼 값을 집계할 수도 있을 것입니다.
다음 item으로 이동합니다. 모든 item이 처리될때까지 이 과정을 반복합니다.

명령형이라고 하는 절차적 code는 compiler에게 '이렇게 하라. 저렇게 하라'와 같이 주어진 목표를 어떻게 달성할 수 있는지를 말해줍니다. Compiler는 우리가 달성하고자 하는 목표자체를 알 수 없기 때문에 그 자체로 우리를 도울 수는 없습니다. 모든 방법적 절차가 정확하게 맞다는 것에 대한 모든 책임은 100% 개발자가에게 있습니다.

LINQ는 이러한 일반적인 작업들을 오류를 최소화하면서 더 쉽게 code를 만들 수 있도록 해줍니다. Move나 read, update 기타 등등 각각의 동작에 대한 상태를 명시적으로 설명하는 대신 LINQ는 개발자가 선언적 혹은 기능적인 style의 문을 작성할 수 있도록 합니다.

선언적 code는 compiler에게 달성하기 위한 목표가 무엇인지를 말해주며 compiler는 가장 최적의 방법을 통해 목표를 달성하게 됩니다. 또한 해당 문은 기존보다 더 간소하면서도 깔끔한 상태를 유지할 수 있습니다.

LINQ를 제대로 이해하지 않으면 작성한 code는 약간의 자체적인 bug를 갖게 될 수 있습니다. 아래 글을 읽어보세요.(https://twitter.com/amantinband/status/1559187912218099714). 해당 부분과 관련해서 솔직히 말하자면 이것은 LINQ의 동작과 multi-threading 동작이 결합된 것으로 사람들이 가장 혼란스러워 하는 것이 이 부분이므로 code가 위험해 질 수 있는 부분을 잘 이해해야 합니다.

2. LINQ 표현식

이전 글을 통해 우리는 이미 간단하게나마 LINQ를 사용해 본적이 있습니다.

그러나 위의 글에 대한 핵심은 LINQ가 아니므로 LINQ가 어떻게 동작하는지에 대해서는 생략했습니다. 이제 LINQ의 표현식을 이해하기 위한 시간을 가져보고자 합니다.

(1) 무엇이 LINQ를 만드는가?

LINQ는 몇가지 부분으로 나뉠 수 있는데 일부는 필수적이지만 일부는 선택적입니다.

Extension method(필수적) : 여기에는 Where나 OrderBy 그리고 Select를 포함한 LINQ의 기능을 제공합니다.
LINQ provider(필수적) : 여기에는 memory상에서 개체를 표현하기 위한 LINQ to Objects와 외부 database에 저장된 data와 EF Core를 통한 model을 처리하기 위한 LINQ to Entities, 그리고 XML로 저장된 data를 처리하기 위한 LINQ to XML을 포함합니다. 이들 provider는 다양한 유형의 data에 대해 특정한 방식으로 LINQ표현식을 실행합니다.
Lambda 표현식(선택적) : LINQ query를 간소화하기 위해 명명된 method대신 예를 들어 filtering를 위한 Where method를 조건부 논리와 같이 사용할 수 있습니다.
LINQ query comprehension 구문(선택적) : 여기에는 from, in, where, orderby, descending, select와 같은 C# keyword가 존재합니다. 이들은 몇몇 LINQ 표현 method에 대한 별칭에 해당하며 특히 이미 SQL(Structured Query Language)과 같이 다른 query언어를 경험해 본 적이 있다면 이들을 더욱 친숙하게 사용할 수 있을 것입니다. 처음 LINQ를 사용할 때는 종종 LINQ query comprehension 구문을 LINQ라고 오해하는 경우도 있는데 이것은 선택적으로 사용하는 LINQ의 여러 부분 중 하나에 해당할 뿐입니다.

(2) 열거 가능한 class에 LINQ 표현식 적용하기

Where나 Select와 같은 LINQ 확장 method는 Enumerable static class에 의해 IEnumerable<T>를 구현하는 모든 sequence type에 추가되었습니다.

예를 들어 모든 type의 array는 IEnumerable<T> class를 구현하며 여기서 T는 array에 속하는 item에 대한 type을 의미합니다. 다시 말해 모든 array는 질의와 이들의 조작하는데 대한 LINQ를 지원한다고 할 수 있습니다.

List<T>, Dictionary<TKey, TValue>, Stack<T>, Queue<T>와 같은 모든 generic collection은 IEnumerable<T>를 구현하므로 이들도 역시 LINQ를 통해 data질의하고 변경할 수 있습니다.

Enumerable은 아래 표에서 요약된것처럼 50여 개 이상의 method를 정의하고 있습니다.

아래 표는 향후 참고용으로 유용할 수 있지만 지금은 간단하게 어떤 method가 존재하고 나중에 어떤 method를 사용하는 것이 적절한지 확인하는 차원에서 살펴볼 수 있습니다.

Method	Description
First, FirstOrDefault, Last, LastOrDefault	Sequence에서 첫번째 혹은 마지막 item을 가져오며 예외 혹은 type에 대한 기본값을 반환할 수 있습니다. 예를 들어 첫번째 혹은 마지막 item이 존재하지 않는 경우 int type이면 0을 참조 type이라면 null을 반환합니다.
Where	지정한 filter와 일치하는 item에 대한 sequence를 반환합니다.
Single, SingleOrDefault	지정한 filter와 일치하는 item을 반환하거나 아니면 예외 혹은 일치하는 것이 존재하지 않는다면 type에 대한 기본값을 반환합니다.
ElementAt, ElementAtOrDefault	지정한 index위치의 item을 반환하거나 아니면 예외 혹은 position에 해당하는 item이 존재하지 않는 경우 type의 기본값을 반환합니다. .NET 6에서 도입된것은 int대신 Index를 전달할 수 있게 overload되어 Span<T> sequences에서 더 효휼적입니다.
Select, SelectMany	Item을 다른 type으로 투영하며 item의 중첩된 계층을 평탄화합니다.
OrderBy, OrderByDescending, ThenBy, ThenByDescending	지정된 field또는 속성을 통해 item을 정렬합니다.
Order, OrderDescending	.NET 7에 도입된 것으로 item을 item자체별로 정렬합니다.
Reverse	Item의 순서를 뒤집습니다.
GroupBy, GroupJoin, Join	두개의 sequences를 group화 하거나 join합니다.
Skip, SkipWhile	Item 특정 수만큼 skip하거나 표현식이 true일때까지 skip합니다.
Take, TakeWhile	Item을 특정 수만큼 가져오거나 표현식이 true일땨까지 가져옵니다. .NET 6에서 도입된 것은 Range를 전달할 수 있도록 overload되었는데 예를 들어 Take(range: 3..^5)은 3번째 item부터 시작하여 5번째 item에서 끝나는 부분집합을 가져온다는 것을 의미합니다. 또는 Skip(4)대신 Take(4..)와 같이 사용할 수도 있습니다.
Aggregate, Average, Count, LongCount, Max, Min, Sum	전체값 계산
TryGetNonEnumeratedCount	Count()는 Count속성이 sequence하에서 구현되었는지를 확인하고 그 값을 반환하거나 item을 count하기 위해 전체 sequence를 열거합니다. .NET 6에서 도입된 것은 해당 method로 오로지 Count만을 확인하여 없는 경우 잠재적인 저성능 운용을 동작을 방지하기 위해 false를 반환하며 out매개변수를 0으로 설정합니다.
All, Any, Contains	Item이 filter에 대해 전체 혹은 일부와 일치하거나 sequence가 지정한 item을 포함하고 있다면 true를 반환합니다.
Cast<T>	지정한 type으로 item을 형변환합니다. 이것은 비 generic개체를 generic type으로 변환할때 유용하게 사용될 수 있습니다.
Distinct	중복 item을 제거합니다.
DistinctBy, ExceptBy, IntersectBy, UnionBy, MinBy, MaxBy	Item의 전체가 아닌 일부만을 사용해 비교를 수행할 수 있습니다. 예를 들어 전체 Person개체를 비교함으로서 Distinct를 통해 중복 item을 제거하는 대신 LastName과 DateOfBirth만 비교함으로서 DistinctBy를 통해 중복 item을 제거할 수 있습니다.
Chunk	크기가 지정된 batch로 sequence를 분할합니다.
Append, Concat, Prepend	Sequence별 결합동작을 수행합니다.
Zip	Items의 위치를 기반으로 2개 혹은 3개의 sequence에 대한 일치 작업을 수행합니다. 예를 들어 첫번째 sequence에서 position이 1인 item은 두번째 sequence의 position 1인 item과 일치합니다.
ToArray, ToList, ToDictionary, ToHashSet, ToLookup	Sequence를 array나 collection으로 변환합니다. 이들은 지연된 실행을 기다라기 보다는 LINQ표현식의 즉각적인 실행을 강제하는 유일한 method입니다.

As와 To로 시작하는 확장 method의 차이에 대해 확실히 해둘 필요가 있습니다. As로 시작하는, 예를 들어 AsEnumerable method는 sequence를 다른 type으로 변환하기는 하지만 memory를 할당하지 않으므로 빠르게 동작합니다. 하지만 To로 시작하는, 예를 들어 ToList와 같은 method는 새로운 item의 sequence에 대한 memory를 할당하게 되므로 상대적으로 느릴 수 있으며 또한 더 많은 memory resource를 사용하게 됩니다.

Enumerable class는 또한 확장 method가 아닌 아래 표에서 설명한 바와 같이 다른 몇몇 method들도 가지고 있습니다.

Method	Description
Empty<T>	지정된 type T에 대한 빈 sequence를 반환합니다. 대게 IEnumerable<T>를 필요로 하는 method에서 빈 sequence를 전달할때 유용하게 사용될 수 있습니다.
Range	Count item을 통한 시작값으로 부터 정수 sequence를 반환합니다. 예를 들어 Enumerable.Range(start: 5, count: 3)는 정수 5, 6 그리고 7을 포함합니다.
Repeat	Count횟수만큼 반복되는 같은 요소를 포함하는 sequence를 반환합니다. 예를 들어 Enumerable.Repeat(element: "5", count: 3)은 문자열값 "5", "5", "5"를 포함합니다.

(3) 지연된 실행(deferred execution)

LINQ는 지연된 실행을 사용합니다. 이는 위에서 언급한 확장 method 대부분을 호출하면 query를 실행하지 않고 결과를 가져온다는 것을 이해하는데 중요한 부분이며 이때 이들 확장 method의 대부분은 답이 아닌 질문을 나타내는 LINQ 표현식을 반환합니다.

Visual Studio 2022에서 csStudy11 solution을 생성하고 여기에 LinqWithObjects이름의 console app project를 추가합니다.

이제 Program.cs에서 기존의 문을 모두 제거하고 아래와 같이 특정 인물에 대한 문자열값의 sequence를 정의합니다.

string[] names = new[] { "이순신", "이도", "신사임당", "홍길동", "김종서", "박혁거세", "김좌진", "윤봉길" };

// 질문 : 이름이 '이'자로 시작하는 사람은 누구인가?

//확장 method 사용
var query1 = names.Where(name => name.StartsWith("이"));

//LINQ query comprehension syntax 사용
var query2 = from name in names where name.StartsWith("이") select name;

질문에 대한 답을 얻으려면 즉, query를 실행하려면 다음과 같이 ToArray나 ToLookup과 같은 To method 중 하나를 호출하거나 query를 열거해야 합니다.

//질문의 답을 포함하는 문자열 arrary를 반환
string[] result1 = query1.ToArray();
//질문의 답을 포함하는 문자열의 list를 반환
List<string> result2 = query2.ToList();
//결과를 열거함으로서 질문의 답을 반환
foreach (string name in query1)
{
	Console.WriteLine(name);

	names[1] = "유관순"; //이도를 유관순으로 변경 -> 유관순은 '이'자로 시작하지 않는다.
}

위 예제를 실행하면 다음과 같은 결과를 표시하게 됩니다.

지연된 실행때문에 첫 번째 결과인 '이순신'을 출력한 이후 본래 배열의 값이 바뀌게 되면 loop로 다시 돌아갈 때쯤 '이도'가 '유관순'으로 변경되었으므로 더 이상 일치하는 것이 없게 되고 따라서 오로지 '이순신'만 표시되는 것입니다.

(4) Where를 통한 entity filtering

LINQ를 사용하는 가장 일반적인 이유는 Where확장 method를 사용해 sequence안에서 item을 filtering하기 위한 것입니다. 예제를 통해 sequence를 정의하고 여기에 LINQ동작을 적용함으로써 filtering을 사용해 보겠습니다.

우선 Project file(*.csproj)에서 아래와 같이 global로 자동으로 import 되는 System.Linq를 제거하기 위한 요소를 추가합니다.

<ItemGroup>
	<Using Remove="System.Linq" />
</ItemGroup>

그리고 Program.cs에서 names에 Where 확장 method를 호출하도록 합니다. 이때 Where를 입력하기 위해 typing울 시도하면 아래와 같이 IntelliSense에 의해 array에서 사용가능한 member들이 표시되는데

이상한 점은 여기에 표시되는 member들 중에서는 Where가 존재하지 않는다는 것입니다. 이는 Where가 확장 method이기 때문이며 array type에는 기본적으로 존재하지 않는 member이기 때문입니다. 따라서 Where 확장 method를 사용하려면 System.Linq namespace를 import 해야 합니다. .NET 6부터는 암시적으로 import 되는 것이 기본이지만 위에서 우리는 이미 System.Linq가 import 되지 않도록 Remove 했기 때문에 사용할 수 없게 되었습니다.

다시 Project file에서 위에서 추가한 System.Linq Remove요소를 삭제하고 names에서 Where method를 호출하도록 시도하면

IntelliSense는 Enumerable class에 의해 추가된 extension method를 추가한 member들을 표시할 것입니다. 또한 Where method에서 IntelliSense는 Where method를 호출하기 위해 Func<string, bool> delegate의 instance를 전달해야 함을 말해주고 있습니다.

Func<string, bool> delegate의 새로운 instance를 생성하기 위한 표현식을 입력합니다. 하지만 다음 단계에서 method의 이름을 정의할 것이기 때문에 아직까지는 method이름을 제공하지 않았습니다. (오류발생)

var query = names.Where(new Func<string, bool>());

Func<string, bool> delegate는 우리에게 각 string변수에 method로 전달되고 method는 반드시 bool값을 반환해야 함을 말해주고 있습니다. Method가 true를 반환한다면 이것은 결과에서 해당 string을 포함하고 있음을 의미하며 그렇지 않으면 포함하고 있지 않음을 의미합니다.

(5) 명명된 method 사용하기

Project에서 Function.cs 이름의 class file을 추가하고 여기에 partial Program class를 정의한 뒤 아래와 같이 3글자 이상의 이름만을 포함시킬 method를 정의합니다.

partial class Program
{
	static bool NameLongerThanFour(string name)
	{
		return name.Length > 3;
	}
}

그리고 Program.cs로 돌아와 위에서 정의했던 Func<string, bool> delegate로 method의 이름을 전달하고

var query = names.Where(new Func<string, bool>(NameLongerThanFour));

해당 query를 열거하도록 하면

foreach (var name in query)
{
	Console.WriteLine(name);
}

다음과 같은 결과를 표시할 것입니다.

(6) Delegate를 제거하여 code 간소화하기

사실 Func<string, bool> delegate의 instance는 명시적으로 제거할 수 있습니다. 그러면 code를 더욱 간소화할 수 있는데 이는 C# compiler가 편의상 delegate를 instance화 할 수 있기 때문입니다.

이전의 문을 복사한 뒤 그대로 주석처리하고 복사된 code를 다시 넣습니다. 그런 뒤 붙여 넣은 code에서 아래와 같이 method이름만 남겨두고 delegate의 instance를 제거합니다.

//var query = names.Where(new Func<string, bool>(NameLongerThanFour));
var query = names.Where(NameLongerThanFour);

예제를 실행하면 이전과 동일한 결과를 표시할 것입니다.

(7) Lambda 표현식 사용하기

예제의 code를 더 간소화할 수 있는 방법으로 명명된 method를 사용하는 대신 lambda expression을 사용할 수 있습니다.

비록 이러한 방법이 처음에는 복잡하고 어려워 보일 수 있으나 lambda expression은 이름이 없는 함수로서 => 기호(goes to라고 함)를 사용해 반환값을 표현할 수 있습니다.

위의 예제를 다시 복사하여 기존의 문을 주석처리한 뒤 복사한 code를 붙여 넣어 아래와 같이 변경합니다.

//var query = names.Where(new Func<string, bool>(NameLongerThanFour));
//var query = names.Where(NameLongerThanFour);
var query = names.Where(name => name.Length > 3);

예제를 보면 NameLongerThanFour method의 모든 중요한 부분이 lambda 식에 포함되어 있는 것을 알 수 있고 또 이것이 전부입니다. lambda 식은 크게 아래 2가지를 정의하고 있는데

입력 매개변수의 이름 : name
반환 값 표현식 : name.length > 3

여기서 name 입력 매개변수의 type은 sequence가 포함하고 있는 문자열값으로 추론되며 Where에서 가능한 delegate의 정의에 따라 반환값은 bool이 됩니다. 따라서 => 기호 이후 표현식에서는 반드시 bool값을 반환하도록 해야 합니다.

Compiler는 우리를 위해 대부분의 작업을 수행하므로 code는 가능한 한 간소화할 수 있습니다. 예제를 실행하면 이전과 동일한 결과를 표시할 것입니다.

(8) 매개변수에 기본값 적용하기

C# 12에서는 lambda 표현식에서 기본값을 제공할 수 있게 되었습니다. 따라서 아래 예제와 같이 표현식을 작성할 수 있습니다.

//var query = names.Where(new Func<string, bool>(NameLongerThanFour));
//var query = names.Where(NameLongerThanFour);
//var query = names.Where(name => name.Length > 3);
var query = names.Where((string name = "홍") => name.Length > 3);

(9) Entity 정렬

다른 일반적으로 사용되는 method로 OrderBy와 ThenBy 등이 있으며 이들은 Sequence를 정렬하기 위해 사용됩니다. 또한 확장 method는 이전 method가 IEnumerable<T> interface를 구현하는 type인 다른 sequence를 반환하는 경우라면 연결(method chain)하여 사용할 수 있습니다.

● OrderBy를 사용한 단일 속성으로 정렬하기

아래 예제와 같이 OrderBy method를 query의 마지막에 추가해 줍니다.

var query = names
	.Where(name => name.Length > 1)
	.OrderBy(name => name.Length);

각각의 확장 method마다 line을 분리하여 형식화하면 좀 더 code를 읽기 쉽게 만들 수 있습니다.

예제를 실행하면 이름이 짧은 순서대로 정렬된 결과를 다음과 같이 표시할 것입니다.

반대로 name이 긴 것 순으로 정렬하고자 한다면 OrderByDescending method를 사용할 수 있습니다.

● ThenBy를 사용한 다수의 속성으로 정렬하기

하나 이상의 속성을 통해 정렬하고자 한다면 예를 들어 alphabet이나 가나다순에서 같은 길이의 name으로 정렬하고자 한다면 아래 예제와 같이 ThenBy를 사용할 수 있습니다.

var query = names
	.Where(name => name.Length > 1)
	.OrderBy(name => name.Length)
	.ThenBy(name => name);

예제를 실행하면 이전과 약간 다른 차이를 알 수 있을 것입니다. 같은 길이의 name으로 정렬된 상태에서 가나다순으로 정렬되었으므로 이도를 제외한 김종서와 김좌진이 상위에 있게 됩니다.

(10) Item 자체에서 정렬하기

.NET 7에서는 Order와 OrderDescending라는 확장 method가 도입되었으며 간단하게 item자체에서 졍렬을 수행할 수 있습니다. 예를 들어 string값의 sequence가 있다면 .NET 7이전에 OrderBy method를 호출하고 item자체를 선택하는 lambda식을 전달해야 했지만

var query = names.OrderBy(name => name);

.NET 7부터는 아래와 같이 간단하게 정렬을 수행할 수 있습니다.

var query = names.Order();

OrderDescending 역시 역순으로 정렬한다는 점을 제외하면 Order와 동일하게 사용할 수 있습니다.

(11) var 또는 특정 type을 사용해 query 선언하기

LINQ 표현식을 작성하는 동안 query개체를 선언하기 위해 var keyword를 사용하는 것은 LINQ 표현식이 동작하는 것마다 type이 자주 바뀔 수 있으므로 매우 일반적인 방법입니다. 예를 들어 예제에서의 query는 IEnumerable<string>으로서 시작되었으나 현재는 IOrderedEnumerable<string>이 되었습니다.

Mouse를 var keyword에 올려두면 type이 IOrderedEnumerable<string>이라는 것을 표시할 것입니다.

따라서 var는 실제 type으로 아래와 같이 바꾸는 것이 가능합니다.

IOrderedEnumerable<string> query = names
	.Where(name => name.Length > 1)
	.OrderBy(name => name.Length)
	.ThenBy(name => name);

일단 query에 대한 작업을 끝내고 나면 var에서부터 선언된 type을 실제 type으로 바꿀 수 있고 이는 type이 정확히 어떤 것인지를 명확히 이해하는데 도움이 될 수 있습니다. 또한 compile시 var가 실제 type으로 바뀌게 되므로 성능에는 영향을 주지 않습니다.

(12) Type filtering

Where 확장 method는 text나 숫자와 같이 값을 통해 filtering 할 수 있지만 sequence가 여러 type을 가지고 있고 이때 상속 계정을 따르면서 특정 type으로 filtering 해야 한다면 다른 방법을 사용해야 합니다.

예를 들어 예외에 대한 sequence가 있다고 가정하면 아래 그림과 같이 복잡한 계층구조로 부터 수백 가지의 예외 type이 형성될 수 있습니다.

그럼 실제 type에 대한 filtering을 예제를 통해 구현해 보겠습니다.

Progam.cs에서 아래와 같이 예외별 파생 개체를 정의합니다.

List<Exception> exceptions = new()
{
		new ArgumentException(),
		new SystemException(),
		new IndexOutOfRangeException(),
		new InvalidOperationException(),
		new NullReferenceException(),
		new InvalidCastException(),
		new OverflowException(),
		new DivideByZeroException(),
		new ApplicationException()
};

이 상태에서 OfType<T> 확장 method를 사용해 arithmetic exception이 아닌 예외를 삭제하고 해당 예외만 console에 표시하는 문을 아래와 같이 작성합니다.

IEnumerable<ArithmeticException> arithmeticExceptionsQuery = exceptions.OfType<ArithmeticException>();
foreach (ArithmeticException exception in arithmeticExceptionsQuery)
{
	Console.WriteLine(exception);
}

위 예제를 실행하면 ArithmeticException 혹은 ArithmeticException으로부터 파생된 type만이 표시됨을 볼 수 있습니다.

(13) LINQ를 사용한 set과 bag

집합은 수학에서 가장 기본적인 개념 중의 하나이며 set은 하나 또는 그 이상의 중복되지 않은 개체의 collection입니다. 반면 Bag라고 하는 multiset(중복집합)은 중복되는 하나 또는 그 이상의 개체에 대한 collection에 해당합니다.

이와 관련하여 학교에서 우리는 이미 Venn diagram이라는 것을 배운 적이 있는데 공통집합 연산에는 집합 간의 교집합 또는 합집합을 포함합니다.

아래 예제에서는 취미별 학생들에 대한 3개의 문자열 값의 array를 정의하고 이들에 대한 공통집합과 합집합을 수행합니다.

우선 project에서 Helpers.cs이름의 class file을 partial class Program으로 추가하고 여기에 아래와 같이 method를 정의합니다. 해당 method는 문자열 변수의 모든 sequence를 comma(,)로 분리한 단일 문자열을 선택적으로 전달하는 설명과 함께 console에 출력하도록 합니다.

partial class Program
{
	static void Output(IEnumerable<string> cohort, string description = "")
	{
		if (!string.IsNullOrEmpty(description))
		{
			Console.WriteLine(description);
		}

		Console.Write(" ");
		Console.WriteLine(string.Join(", ", cohort.ToArray()));
		Console.WriteLine();
	}
}

Program.cs에서는 학생이름에 대한 3개의 문자열 array를 정의하고 이들을 출력한 뒤 다양한 집합연산을 수행하는 문을 아래와 같이 작성합니다.

string[] reading = new[] { "홍길동", "박남일", "김신영", "조정석" };
string[] music = new[] { "윤태진", "박길영", "서만진", "윤태진", "김영수" };
string[] exercise = new[] { "최동만", "이해영", "이해영", "윤태진", "한봉남" };

Output(reading, "독서");
Output(music, "음암감상");
Output(exercise, "운동");

Output(music.Distinct(), "music.Distinct()");
Output(music.DistinctBy(name => name.Substring(0, 2)), "music.DistinctBy(name => name.Substring(0, 2)):");
Output(music.Union(exercise), "music.Union(exercise)");
Output(music.Concat(exercise), "music.Union(exercise)");
Output(music.Intersect(exercise), "music.Intersect(exercise)");
Output(music.Except(exercise), "music.Union(exercise)");
Output(reading.Zip(music, (c1, c2) => $"{c1} matched with {c2}"), "reading.Zip(music)");

예제를 실행하면 다음과 같은 결과를 표시할 것입니다.

예제에서 Zip은 2개의 sequences에서 item의 수가 동일하지 않다면 일부 item에서 mathing 되지 않을 수 있습니다. 따라서 music에 '김영수'는 결과에 포함되지 않았습니다.

DistinctBy는 전체이름을 비교하여 중복을 제거하는 대신 이름에서 처음 2글자만 비교하여 제거하기 위해 lambda key selector를 정의하였고 따라서 2명의 '윤태진'중 하나는 제거되었습니다.

지금까지 우리는 LINQ to Objects 공급자를 사용하여 in-memory 개체를 대상으로 예제를 구현하였습니다. 이후부터는 LINQ to Entities 공급자를 사용하여 database에 저장된 entity를 대상으로 예제를 구현해 볼 것입니다.

3. EF Core와 LINQ

위에서는 LINQ query를 통해 filter와 sort를 수행해 보았습니다. 하지만 sequence의 item 형태는 어떤 것도 변함이 없습니다. 이것은 projection이라고 하는 것으로 어떤 형태의 item을 다른 형태로 projecting 하는 것이기 때문입니다.

Projection에 관해 더 알아보려면 좀 더 복잡한 type을 가지고 해 보는 것도 좋은 방법이므로 다음 project에서는 string sequences를 사용하는 대신 이전에 설치했었던 Northwind sample database의 entity sequences를 사용할 것입니다.

(1) EF Core model build

일단 작업의 대상이 될 database와 table을 표현하기 위해 EF Core model을 정의해야 합니다. 따라서 우선은 Categories와 Categories table사이에 자동적으로 관계가 정의되는 것을 막고 완전한 제어권을 가져오기 위해 model을 수동적으로 정의할 것입니다. 그런 다음 LINQ를 사용하여 이 둘의 entity를 join 해 보고자 합니다.

csStudy11 solution에서 LinqWithEFCore이름의 console app project를 생성합니다. 그리고 LinqWithEFCore project에서 SQL Server에 대한 EF Core provider package를 설치합니다. 실제 database는 아래 글에서 이미 설치하였으므로 database를 생성하는 과정은 다루지 않을 것입니다.

[.NET/C#] - [C# 12와 .NET 8] 10. Entity Framework Core

이제 project에 Northwind.cs, Category.cs, Product.cs라는 3개의 class file을 추가할 것입니다. 우선 Northwind.cs file은 아래와 같이 추가합니다.

public class Northwind : DbContext
{
	public DbSet<Category> Categories { get; set; } = null!;

	public DbSet<Product> Products { get; set; } = null!;

	protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
	{
		string connection = "Server=localhost;user id=sa;password=!123;Database=Northwind;MultipleActiveResultSets=true;TrustServerCertificate=true";
		optionsBuilder.UseSqlServer(connection);
	}

	protected override void OnModelCreating(ModelBuilder modelBuilder)
	{
		if ((Database.ProviderName is not null))
		{
			modelBuilder.Entity<Product>().Property(product => product.UnitPrice).HasConversion<double>();
		}
	}
}

Category.cs는 아래와 같이 추가하고

public class Category
{
	public int CategoryId { get; set; }

	[Required]
	[StringLength(15)]
	public string CategoryName { get; set; } = null!;

	public string? Description { get; set; }
}

Product.cs는 아래와 같이 추가합니다.

public class Product
{
	public int ProductId { get; set; }

	[Required]
	[StringLength(40)]
	public string ProductName { get; set; } = null!;
	public int? SupplierId { get; set; }
	public int? CategoryId { get; set; }

	[StringLength(20)]
	public string? QuantityPerUnit { get; set; }

	[Column(TypeName = "money")]
	public decimal? UnitPrice { get; set; }
	public short? UnitsInStock { get; set; }
	public short? UnitsOnOrder { get; set; }
	public short? ReorderLevel { get; set; }
	public bool Discontinued { get; set; }
}

(2) Sequence filtering 하고 sorting 하기

Table로부터 sequence를 filtering 하고 sorting 하기 위해 project에 Functions.cs이름의 class를 file을 추가하고 partial Program class를 정의한 뒤 product를 filter 하고 sort 하는 method를 아래와 같이 추가합니다.

static void FilterAndSort()
{
	using (Northwind db = new())
	{
		DbSet<Product> allProducts = db.Products;

		IQueryable<Product> filteredProducts = allProducts.Where(product => product.UnitPrice < 10M);

		IOrderedQueryable<Product> sortedAndFilteredProducts = filteredProducts.OrderByDescending(product => product.UnitPrice);

		Console.WriteLine("Products that cost less than $10:");

		foreach (Product p in sortedAndFilteredProducts)
		{
			Console.WriteLine("{0}: {1} costs {2:$#,##0.00}", p.ProductId, p.ProductName, p.UnitPrice);
		}

		Console.WriteLine();
	}
}

예제에서 DbSet<T>는 IEnumerable<T>를 구현하고 있으므로 LINQ는 EF Core를 위해 만들어진 model의 entity를 query 하고 조작하기 위해 사용할 수 있습니다. (실제 T대신 TEntity라고 할 수 있지만 해당 generic type의 이름은 기능적인 면을 가지고 있지 않으며 단지 type이 class라는 것만 필요할 뿐입니다. 이름은 그저 class가 entity model이 될 것이라는 예상을 나타낼 뿐입니다.)

Sequence는 또한 IEnumerable<T>혹은 IOrderedEnumerable<T>대신 IQueryable<T> (또는 정렬 LINQ method를 호출하고 나면 IOrderedQueryable<T>)를 구현하고 있습니다. 이는 표현식 tree를 사용해 query를 build 하는 LINQ provider를 사용한다는 것을 나타냅니다. 이들은 tree와 같은 data구조를 나타내고 있으며 동적 query의 생성을 가능하게 하는데 SQLite와 같은 외부 data 공급자를 위해 LINQ query를 build 하는데 유용하게 사용될 수 있습니다.

LINQ표현식은 SQL과 같은 다른 query언어로 변환될 수 있습니다. foreach나 ToArray와 같은 method를 호출하여 query를 열거하게 되면 query를 실행하게 되고 결과를 구체화하게 됩니다.

Program.cs에서 FilterAndSort method를 아래와 같이 호출합니다.

비록 해당 query가 목적한 바에 대한 결과를 표시하고 있기는 하지만 우리가 필요한 3개의 column대신 product table로부터 모든 column들을 가져오고 있기 때문에 상당히 비효휼적이라고 할 수 있습니다. 실제 생성된 SQL문을 확인해 보기 위해 FilterAndSort method를 아래와 같이 수정하고

IOrderedQueryable<Product> sortedAndFilteredProducts = filteredProducts.OrderByDescending(product => product.UnitPrice);

Console.WriteLine(sortedAndFilteredProducts.ToQueryString());

예제를 다시 실행해 보면 product에 대한 filtering결과를 표시하기 전에 실행된 SQL을 다음과 같이 확인할 수 있습니다.

(3) Sequence를 새로운 type으로 projecting 하기

실제 projection을 구현하기 전에 우선은 개체 초기화 구문을 다시 검토해 볼 필요가 있습니다. 정의된 class가 있다면 class명이나 new()를 사용해 해당 개체의 instance를 생성할 수 있으며 괄호를 통해 field나 속성의 초기값을 설정할 수 있습니다.

public class Person
{
    public string Name { get; set; }
    public DateTime DateOfBirth { get; set; }
}

Person knownTypeObject = new()
{
    Name = "dongjunkim",
    DateOfBirth = new(year: 1976, month: 11, day: 14)
};

C# 3.0 이부터는 instance에서 익명 type을 허용하고 있으므로 var keyword를 아래와 같이 사용할 수 있습니다.

var knownTypeObject = new()
{
    Name = "dongjunkim",
    DateOfBirth = new(year: 1976, month: 11, day: 14)
};

비록 type을 명시하지는 않았지만 compiler는 Name과 DateOfBirth라는 이름의 2개의 속성에 대한 설정으로부터 익명 type을 추론할 수 있습니다.

이러한 기법은 특히 새로운 type을 명시적으로 정의하지 않고 기존 type에서 새로운 type으로 project 하기 위해 LINQ query를 작성할 때 도움이 될 수 있습니다. Type은 익명이기에 var 선언된 지역변수에서만 작동할 수 있습니다.

아래 예제는 Product class의 instance를 새로운 익명 type으로 투영하기 위한 select method의 호출을 추가함으로써 database table을 상대로 SQL명령을 더 효휼적으로 실행하는 방식을 보여주고 있습니다.

Functions.cs의 FilterAndSort method에서 실제 필요로 하는 세 개의 속성(table의 column에 해당하는)만을 반환하는 Select method를 사용하기 위해 LINQ query를 확장하는 문을 아래와 같이 추가하고 var keyword와 projection LINQ 표현식을 사용하도록 아래와 같이 foreach문을 변경합니다.

IOrderedQueryable<Product> sortedAndFilteredProducts = filteredProducts.OrderByDescending(product => product.UnitPrice);

var projectedProducts = sortedAndFilteredProducts.Select(product => new { product.ProductId, product.ProductName, product.UnitPrice });

Console.WriteLine(projectedProducts.ToQueryString());

Console.WriteLine("Products that cost less than $10:");

foreach (var p in projectedProducts)
{
	Console.WriteLine("{0}: {1} costs {2:$#,##0.00}", p.ProductId, p.ProductName, p.UnitPrice);
}

이때 Select method에서 new keyword와 foreach문의 var keyword에 mouse를 올려두면 이것이 익명 type임을 다음과 같이 표시할 것입니다.

예제를 실행하면 이전과 같은 결과를 표시하지만 생성된 SQL은 더 효휼적으로 바뀌었음을 알 수 있습니다.

(4) Sequence에 대한 join과 grouping

Joining과 grouping을 위해 사용할 수 있는 확장 method로 아래와 같은 3가지가 있습니다.

Join : 해당 method는 join 하고자 하는 sequence 및 연결시킬 left sequence와 right sequence에 해당하는 속성, 그리고 projection인 4개의 매개변수를 필요로 합니다.
GroupJoin : 해당 method 역시 같은 매개변수를 필요로 하지만 일치하는 항목들을 일치하는 값에 대한 key속성과 다중 일치항목에 대한 IEnumerable<T> type을 가진 group개체로 결합합니다.
ToLookup : 해당 method는 기존의 sequence에서 key를 통해 group화된 것을 토대로 새로운 data구조를 생성합니다.

● Sequence Join

예를 들어 Categories와 Products라는 2개의 table을 join 하고자 하는 경우 Functions.cs에서 categories와 products를 select 하고 이들을 join 하여 출력하는 method를 아래와 같이 추가할 수 있습니다.

static void JoinCategoriesAndProducts()
{
	using (Northwind db = new())
	{
		//Products를 Categories와 join함
        var queryJoin = db.Categories.Join(
			inner: db.Products,
			outerKeySelector: category => category.CategoryId,
			innerKeySelector: product => product.CategoryId,
			resultSelector: (c, p) => new { c.CategoryName, p.ProductName, p.ProductId }
		);
        foreach (var item in queryJoin)
        {
            Console.WriteLine("{0}: {1} is in {2}.", arg0: item.ProductId, arg1: item.ProductName, arg2: item.CategoryName);
        }
    }
}

Join에서는 outer와 inner라는 2개의 sequence가 존재합니다. 위의 예제에서 categories는 outer sequence가 되고 products는 inner sequence가 됩니다.

Program.cs에서는 JoinCategoriesAndProducts method를 호출하도록 한 뒤 예제를 실행하면 다음과 같은 결과를 표시할 것입니다.

query의 끝에서 CategoryName에 대한 정렬을 위해 OrderBy method를 아래와 같이 호출할 수 있습니다.

var queryJoin = db.Categories.Join(
	inner: db.Products,
	outerKeySelector: category => category.CategoryId,
	innerKeySelector: product => product.CategoryId,
	resultSelector: (c, p) => new { c.CategoryName, p.ProductName, p.ProductId }
).OrderBy(cp => cp.CategoryName);

결과를 실행해 보면 처음에는 Beverages category에 대한 모든 product들이 나오고 그다음 Condiments category에 대한 것들 등.. 의 순서로 결과가 표시됨을 알 수 있습니다.

● Sequence group-Joining

위에서 join 하기에 사용했던 Categories와 Products 이 2개의 table에 대해 group-joining을 해봄으로써 약간의 차이를 비교해 볼 수 있습니다.

Functions.cs에서 group과 join을 수행하고 group name과 각 group에서의 모든 item을 표시하는 method를 아래와 같이 추가합니다.

static void GroupJoinCategoriesAndProducts()
{
	using (Northwind db = new())
	{
        var queryGroup = db.Categories.AsEnumerable().GroupJoin(
			inner: db.Products,
			outerKeySelector: category => category.CategoryId,
			innerKeySelector: product => product.CategoryId,
			resultSelector: (c, matchingProducts) => new
			{
				c.CategoryName,
				Products = matchingProducts.OrderBy(p => p.ProductName)
			});

        foreach (var category in queryGroup)
        {
            Console.WriteLine("{0} has {1} products.", arg0: category.CategoryName, arg1: category.Products.Count());
            foreach (var product in category.Products)
            {
                Console.WriteLine($" {product.ProductName}");
            }
        }
    }
}

만약 예제에서처럼 AsEnumerable method를 호출하지 않는다면 다음과 같은 runtime 예외가 발생할 것입니다.

이는 모든 LINQ 확장 method가 표현식 tree로부터 SQL과 같은 일부 다른 query문으로 변환되지 않기 때문입니다. 이 경우 예제는 application으로 data를 가져오기 위한 LINQ to EF Core사용을 위해 query처리를 강제하고 memory에서 더 복잡한 처리를 실행하기 위한 LINQ to Objects를 사용하는 AsEnumerable method를 호출함으로써 IQueryable<T>에서 IEnumerable<T>로 변환하고 있습니다. 하지만 대게 이러한 처리는 효율성면에서 더 떨어질 수 있습니다.

Program.cs에서 GroupJoinCategoriesAndProducts method를 호출하도록 한 뒤 예제를 실행하면 다음과 같은 결과를 표시할 것입니다.

결과를 보면 각 category에 포함된 product들이 query에서 정의된 것처럼 이름순으로 정렬되어 있음을 알 수 있습니다.

● lookup을 위한 group화

LINQ query 표현식을 통해 join과 group를 작성하는 대신 lookup 확장 method를 통해 entity를 group화한 개체를 생성하고 memory에 개체를 저장할 수 있습니다.

Northwind의 database의 Products table을 보면 category를 위한 일부 column이 포함되어 있음을 알 수 있습니다.

Product	Category
Chai	1
Chang	1
Aniseed Syrup	2
Chef Anton’s Cajun Seasoning	2
Chef Anton’s Gumbo Mix	2

이 상태에서 category별로 product의 entity를 그룹화한 data구조를 생성하고자 한다면 아래와 같이 구현할 수 있습니다.

ILookup<int, Product> productsByCategoryId = db.Products.ToLookup(keySelector: category => category.CategoryId);

ToLookup method에서는 group화에 사용될 값으로서 key selector를 지정해야 합니다. 이를 통해 key와 값을 가진 dictionary형태의 data를 생성하게 되며 이때 key는 category ID가 되고 값은 Product 개체의 collection이 됩니다.

key	value
1	Chai, Chang...
2	Aniseed Syrup, Chef Anton’s Cajun Seasoning, Chef Anton’s Gumbo Mix, ...
...	...

(5) Sequences 집계하기

LINQ 확장 method 중에는 집계기능을 수행하는 Average나 Sum과 같은 것들이 존재합니다. 아래 예제를 통해 이들 method를 사용하여 Products에 대한 집계정보를 확인하는 방법을 알 수 있습니다.

Functions.cs에서 다음과 같이 다양한 집계 확장 method를 사용하는 method를 추가합니다.

static void AggregateProducts()
{
	using (Northwind db = new())
	{
        if (db.Products.TryGetNonEnumeratedCount(out int countDbSet))
        {
            Console.WriteLine("{0,-25} {1,10}", arg0: "Product count from DbSet:", arg1: countDbSet);
        }
        else
        {
            Console.WriteLine("Products DbSet does not have a Count property.");
        }

        List<Product> products = db.Products.ToList();

        if (products.TryGetNonEnumeratedCount(out int countList))
        {
            Console.WriteLine("{0,-25} {1,10}", arg0: "Product count from list:", arg1: countList);
        }
        else
        {
            Console.WriteLine("Products list does not have a Count property.");
        }

        //aggregation extension methods
        Console.WriteLine("{0,-25} {1,10}", arg0: "Product count:", arg1: db.Products.Count());
        Console.WriteLine("{0,-27} {1,8}", arg0: "Discontinued product count:", arg1: db.Products.Count(product => product.Discontinued));
        Console.WriteLine("{0,-25} {1,10:$#,##0.00}", arg0: "Highest product price:", arg1: db.Products.Max(p => p.UnitPrice));
        Console.WriteLine("{0,-25} {1,10:N0}", arg0: "Sum of units in stock:", arg1: db.Products.Sum(p => p.UnitsInStock));
        Console.WriteLine("{0,-25} {1,10:N0}", arg0: "Sum of units on order:", arg1: db.Products.Sum(p => p.UnitsOnOrder));
        Console.WriteLine("{0,-25} {1,10:$#,##0.00}", arg0: "Average unit price:", arg1: db.Products.Average(p => p.UnitPrice));
        Console.WriteLine("{0,-25} {1,10:$#,##0.00}", arg0: "Value of units in stock:", arg1: db.Products.Sum(p => p.UnitPrice * p.UnitsInStock));
    }
}

Count를 확인하는 것은 단순한 동작처럼 보이지만 처리비용이 많이 들 수 있습니다. Products와 같은 DbSet<T>는 Count 속성을 가지고 있지 않으므로 TryGetNonEnumeratedCount는 false를 반환합니다. 하지만 products 같은 List<T>는 ICollection을 구현하므로 Count속성을 가지고 있고 따라서 TryGetNonEnumeratedCount는 true를 반환합니다. (이 경우 그 자체로 비용이 많이 드는 list를 instance화 해야 했지만 이미 list가 있고 item의 수를 알아야 한다면 이것이 더 효율적일 수 있습니다.) DbSet<T>에서 언제나 Count() 호출할 수 있지만 이는 sequence를 열거해야 하므로 느릴 수 있으며 lambda 식을 Count()에 전달하여 sequence의 count되어야할 item을 filter할 수 있지만 Count나 Length는 사용할 수 없습니다.

Program.cs에서 AggregateProducts method를 호출하도록 하고 예제를 실행하면 다음과 같은 결과를 볼 수 있습니다.

(6) 빈 sequence를 확인하는 방법

빈 sequence를 확인하는데는 아래와 같은 방법이 존재합니다.

● Count method

LINQ의 Count method를 호출하여 결과가 0이상인지를 확인합니다. 이 방법은 sequence items 전체를 열거해야 하므로 좋은 방법은 아닙니다. Sequence가 ICollection 혹은 ICollection<T>를 구현하고 있으면 Count 속성이 더 효휼적인 방법일 수 있습니다.

● Any method

LINQ의 Any method를 호출하여 true여부를 확인합니다. Count method보다는 괜찮지만 아래 2가지 방법을 사용할 수 있다면 추천하지 않습니다.

● Count 속성

Sequence의 Count 속성을 사용하여 0이상인지를 확인합니다. ICollection 혹은 ICollection<T>를 구현하는 모든 sequence는 Count속성을 가집니다.

● Length 속성

Sequence의 Length속성을 사용하여 0이상인지를 확인합니다. 기본적으로 모든 array는 Length속성을 가집니다.

해당 Sequence가 Count나 Length속성을 가지고 있다면 해당 속성을 가장 우선적으로 사용하는 것이 좋습니다.

(7) Count에서의 주의점

Amichai Mantinband은 Microsoft의 software engineer로서 C#과 .NET 개발자 stack의 흥미로운 부분에 대한 주목할만한 일을 하고 있습니다.

최근 그는 Twitter, LinkedIn, YouTube에 개발자들이 이 code가 무엇을 할 것이라고 생각하는지를 알아보기 위한 설문과 함께 code teaser를 post 했습니다.

그의 code는 이렇습니다.

IEnumerable<Task> tasks = Enumerable.Range(0, 2).Select(_ => Task.Run(() => Console.WriteLine("*")));
await Task.WhenAll(tasks);
Console.WriteLine($"{tasks.Count()} stars!");

위 code의 결과는 무엇일까요?

**2 stars!
**2 stars!**
****2 stars!
이외 다른 것

그런데 설문결과 대부분 틀린 것을 골랐습니다. 여기서 말하고자 하는 핵심이 바로 이것이며 위와 같은 까다로운 질문에서 task와 함께 multi-threadiing의 세부적인 부분 까지는 아니더라도 LINQ부분을 살펴볼 수 있습니다. 위 code에서는 LINQ부분을 이해하기 위해 아래와 같이 code를 분리해 보겠습니다.

Enumerable.Range(0, 2)	0과 1의 두 정수에 대한 sequence를 반환합니다. code를 좀더 명확히 하기위해 이 부분에서 명명된 매개변수를 아래와 같이 추가할 수도 있을 것입니다. Enumerable.Range(start: 0, count: 2)
Select(_ => Task.Run(...)	두 숫자 각각에서 자체 thread를 가진 task를 생성합니다. 이때 _ 매개변수는 숫자값을 버리게 되며 각각의 task는 console로 *을 표시하게 됩니다.
await Task.WhenAll(tasks);	두 task가 완료될때까지 main thread를 block하게 되며 2개의 *문자가 console에 표시됩니다.
tasks.Count()	해당 scenario에서 LINQ Count() method가 작동하려면 sequence를 열거해야 하며 이렇게 하면 2개의 task를 다시 실행시킬 수 있습니다. 다만 이 2개의 task가 실행될 시점을 알 수 없고 2의 값이 호출한 method로 부터 반환됩니다.
Console.WriteLine( $"... stars!");	'2 stars!'가 console에 출력됩니다.

따라서 우리는 **이 console에 먼저 출력되고 그다음 하나 또는 2개의 task가 *을 출력하고 그 뒤 '2 stars!'가 출력된다는 것을 알 수 있습니다. 마지막으로 하나 또는 2개의 task가 이전에 수행할 시간이 없거나 main thread가 종료되어 task가 *을 출력하기 전에 console app을 종료할 수 있는 경우 *을 출력할 수 있으므로 결과를 다음과 같을 것입니다.

**[각 task는 여기에 *을 출력할 수도 있음]2 starts![각 task는 여기에 *을 출력할 수 있음]

따라서 Amichai의 teaser에 대한 가장 정확한 답은 'Something else'일 것입니다.

반환값을 계산하기 위해 sequence전체를 열거해야 하는 Count 등의 LINQ 확장 method를 호출할 때는 주의가 필요합니다. Task와 같이 실행가능한 개체의 sequence를 사용하지 않는다 하더라도 sequence를 다시 열거하는 것은 비효율적일 수 있습니다.

(8) LINQ를 사용한 paging

Skip과 Take 확장 method를 사용하면 paging을 구현할 수 있습니다.

Functions.cs에서 아래와 같이 array로 전달한 products의 table을 console에 출력하는 method를 추가합니다.

static void OutputTableOfProducts(Product[] products, int currentPage, int totalPages)
{
    string line = new('-', count: 73);
    string lineHalf = new('-', count: 30);

    Console.WriteLine(line);
    Console.WriteLine("{0,4} {1,-40} {2,12} {3,-15}", "ID", "Product Name", "Unit Price", "Discontinued");
    Console.WriteLine(line);

    foreach (Product p in products)
    {
        Console.WriteLine("{0,4} {1,-40} {2,12:C} {3,-15}", p.ProductId, p.ProductName, p.UnitPrice, p.Discontinued);
    }

    Console.WriteLine("{0} Page {1} of {2} {3}", lineHalf, currentPage + 1, totalPages + 1, lineHalf);
}

일반적인 programming세계에서 순서는 0부터 시작합니다. 따라서 currentPage count와 totalPages count에 대한 값을 사용자에게 표시하기 전 1을 더해줄 필요가 있습니다.

계속해서 products에 대한 page를 만드는 LINQ query를 생성하고 여기서 만들어진 SQL을 출력한 뒤 products의 table을 표시하는 method에서 products의 array로 해당 결과를 전달하는 method를 아래와 같이 추가합니다.

static void OutputPageOfProducts(IQueryable<Product> products, int pageSize, int currentPage, int totalPages)
{
    // skip과 take전에 data를 정렬하여 각 page에서 data가 임의의 순서로 나오지 않도록 해야 합니다.
    var pagingQuery = products.OrderBy(p => p.ProductId).Skip(currentPage * pageSize).Take(pageSize);

    OutputTableOfProducts(pagingQuery.ToArray(), currentPage, totalPages);
}

마지막으로 사용자가 왼쪽(left) 혹은 오른쪽(right) 화살표를 눌러 database의 products를 한 번에 한 page씩 표시하도록 순환하는 method를 같이 추가합니다.

static void PagingProducts()
{
	using (Northwind db = new())
	{
		int pageSize = 10;
		int currentPage = 0;
		int productCount = db.Products.Count();
		int totalPages = productCount / pageSize;

		while (true)
		{
            OutputPageOfProducts(db.Products, pageSize, currentPage, totalPages);
            Console.Write("Press <- to page back, press -> to page forward, any key to exit.");

            ConsoleKey key = Console.ReadKey().Key;

            if (key == ConsoleKey.LeftArrow)
                if (currentPage == 0)
                    currentPage = totalPages;
                else
                    currentPage--;
            else if (key == ConsoleKey.RightArrow)
                if (currentPage == totalPages)
                    currentPage = 0;
                else
                    currentPage++;
            else
                break; // loop 탈출

            Console.WriteLine();
        }
    }
}

Program.cs에서는 PagingProducts method를 호출하도록 하고 예제를 실행하면 다음과 같은 결과를 표시할 것입니다.

위 예제의 결과에서 ORDER BY, LIMIT, OFFSET 등을 사용해 products의 page를 효휼적으로 가져오기 위해 사용된 SQL문의 표시는 제외하였습니다.

왼쪽, 오른쪽 key를 누르면 page를 전환할 수 있고 그 외 다른 key를 누르면 program을 빠져나오게 됩니다.

Paging을 위해 Skip과 Take를 호출하는 경우라면 그전에 data를 정렬해야 합니다. 이는 query가 실행될 때마다 ProductId순이나 UnitPrice순 혹은 심지어 random처럼 특정 기준으로의 정렬이 요청될 수 있으므로 LINQ 공급자가 같은 순서의 data가 반환된다는 것을 보증하지 않기 때문입니다. 관계형 database에서 대게는 primary key상의 index순으로 사용하는 경우가 많습니다.

4. LINQ 구문의 향상기법

C# 3.0에서는 2008년에 SQL경험을 가진 개발자가 LINQ query를 더 쉽게 만들기 위한 몇 가지 새로운 언어 keyword를 도입하였으며 이를 LINQ query 이해(comprehension) 구문이라고 합니다.

예를 들어 다음과 같은 문자열형식의 array가 존재할 때

string[] names = new[] { "이순신", "이도", "신사임당", "홍길동", "김종서", "박혁거세", "김좌진", "윤봉길" };

이름별로 filter 하고 정렬하기 위해 아래와 같이 확장 method와 lambda 식을 사용할 수 있습니다.

var query = names
    .Where(name => name.Length > 3)
    .OrderBy(name => name.Length)
    .ThenBy(name => name);

또는 같은 결과를 만들어내기 위해 아래와 같이 query 이해 문을 사용할 수도 있습니다.

var query = from name in names
            where name.Length > 3
            orderby name.Length, name
            select name;

이러한 방식이 작동할 수 있는 이유는 compiler가 query 이해 문을 이전예제와 동일하게 확장 method와 lambda 식으로 변환하기 때문입니다.

select keyword는 LINQ query 이해 구문에서 반드시 필요한 존재합니다. 하지만 Select 확장 method는 확장 method와 lambda 식을 사용할 때 Select를 호출하지 않으면 item전체가 암시적으로 선택되므로 선택적으로 사용할 수 있습니다.

모든 확장 method가 C# keyword와 동일하게 연결되지는 않습니다. 예를 들어 Skip과 Take 확장 method는 일반적으로 많은 data에서 paging을 구현하는 데 사용되곤 합니다. Query comprehense만으로 작성될 수 없는 skip과 take query는 모두 확장 method를 사용해 다음과 같이 작성할 수 있습니다.

var query = names
    .Where(name => name.Length > 3)
    .Skip(80)
    .Take(10);

또는 괄호를 통해 query 이해 문을 감싸고 난 후 이를 확장 method로 연결하여 사용할 수도 있습니다.

var query = (from name in names
                where name.Length > 4
                select name)
                .Skip(80)
                .Take(10);

5. 사용자 LINQ 확장 method 정의하기

아래 글을 통해서 우리는 이미 자신만의 확장 method를 생성하는 방법을 알아보았습니다.

2024.02.20 - [.NET/C#] - [C# 12와 .NET 8] 6. Interface와 Class상속

LINQ 확장 method를 만들기 위해 해야 할 것은 IEnumerable<T> type을 확장하는 것이 전부입니다.

직접 정의한 method는 별도의 class file을 만들어 분리해 두면 자체 assembly나 NuGet package 등으로 배포하기 수훨해 질 수 있습니다.

예를 들어 우리는 평균을 아래 3가지 중 하나가 될 수 있음을 말할 수 있는데

Mean : 수를 합산하고 건수로 나눈 것
Mode : 가장 일반적인 숫자
Median : 정렬되고 난 후의 숫자 중에서 중간값

Microsoft는 Average 확장 method를 mean으로 계산되도록 구현하였으므로 여기서 Average method를 위에서 언급한 Mode와 Median계산이 가능하도록 해야 한다면 다음과 같은 방법으로 method를 정의할 수 있습니다.

Project에 MyLinqExtensions.cs file을 아래와 같이 추가합니다.

namespace LinqWithEFCore
{
    public static class MyLinqExtensions
    {
        // chain LINQ extension method
        public static IEnumerable<T> ProcessSequence<T>(this IEnumerable<T> sequence)
        {
            // you could do some processing here
            return sequence;
        }

        public static IQueryable<T> ProcessSequence<T>(this IQueryable<T> sequence)
        {
            // you could do some processing here
            return sequence;
        }

        // scalar LINQ extension methods
        public static int? Median(this IEnumerable<int?> sequence)
        {
            var ordered = sequence.OrderBy(item => item);
            int middlePosition = ordered.Count() / 2;

            return ordered.ElementAt(middlePosition);
        }

        public static int? Median<T>(this IEnumerable<T> sequence, Func<T, int?> selector)
        {
            return sequence.Select(selector).Median();
        }

        public static decimal? Median(this IEnumerable<decimal?> sequence)
        {
            var ordered = sequence.OrderBy(item => item);
            int middlePosition = ordered.Count() / 2;

            return ordered.ElementAt(middlePosition);
        }

        public static decimal? Median<T>(this IEnumerable<T> sequence, Func<T, decimal?> selector)
        {
            return sequence.Select(selector).Median();
        }

        public static int? Mode(this IEnumerable<int?> sequence)
        {
            var grouped = sequence.GroupBy(item => item);
            var orderedGroups = grouped.OrderByDescending(group => group.Count());

            return orderedGroups.FirstOrDefault()?.Key;
        }

        public static int? Mode<T>(this IEnumerable<T> sequence, Func<T, int?> selector)
        {
            return sequence.Select(selector)?.Mode();
        }

        public static decimal? Mode(this IEnumerable<decimal?> sequence)
        {
            var grouped = sequence.GroupBy(item => item);
            var orderedGroups = grouped.OrderByDescending(group => group.Count());

            return orderedGroups.FirstOrDefault()?.Key;
        }

        public static decimal? Mode<T>(this IEnumerable<T> sequence, Func<T, decimal?> selector)
        {
            return sequence.Select(selector).Mode();
        }
    }
}

Class가 별도의 class library로 분리되어 있다면 LINQ 확장 method를 사용하기 위해서는 그저 class library assembly를 참조하기만 하면 됩니다. 참고로 System.Linq namespace는 이미 암시적으로 import 되는 것이 기본이기 때문에 대부분 별다른 추가작업이 필요 없지만 그렇지 않다면 System.Linq도 import 되어야 합니다.

상기 예제의 모든 method 중 하나를 제외하고 그 외 다른 method는 SQL과 같은 query언어로 변환하는 것까지 구현하지 않았기 때문에 LINQ to SQLite 또는 LINQ to SQL Server에서 사용된 것과 같은 IQueryable sequence와 함께 사용할 수 없습니다.

(1) Chainable extension method

상기 예제에서 처음 2개의 method는 ProcessSequence method와의 chaining이 가능한 method입니다.

Functions.cs의 FilterAndSort method에서 Products에 대한 LINQ query를 아래와 같이 변경하여 예제의 확장 method를 호출하도록 합니다.

DbSet<Product> allProducts = db.Products;

IQueryable<Product> processedProducts = allProducts.ProcessSequence();
				
IQueryable<Product> filteredProducts = processedProducts.Where(product => product.UnitPrice < 10M);

Program.cs에서는 FilterAndSort method를 호출하도록 하고 예제를 실행하면 이전과 같은 결과를 볼 수 있을 것입니다. 여기서는 예제의 ProcessSequence method가 실제 sequence를 변경하는 것은 아니지만 이러한 구현을 통해 LINQ표현식을 위 method처럼 확장할 수 있다는 것을 알 수 있습니다.

● Mode와 median method 구현

다른 종류의 평균을 계산하기 위한 Mode and Median method를 사용하기 위해 Functions.cs에서 products의 UnitPrice와 UnitsInStock에 대한 mean, median, mode를 이전 예제에서 구현한 확장 method와 기본 내장 Average extension method를 사용해 출력하는 method를 아래와 같이 추가합니다.

static void CustomExtensionMethods()
{
	using (Northwind db = new())
	{
        Console.WriteLine("{0,-25} {1,10:N0}", "Mean units in stock:", db.Products.Average(p => p.UnitsInStock));
        Console.WriteLine("{0,-25} {1,10:$#,##0.00}", "Mean unit price:", db.Products.Average(p => p.UnitPrice));
        Console.WriteLine("{0,-25} {1,10:N0}", "Median units in stock:", db.Products.Median(p => p.UnitsInStock));
        Console.WriteLine("{0,-25} {1,10:$#,##0.00}", "Median unit price:", db.Products.Median(p => p.UnitPrice));
        Console.WriteLine("{0,-25} {1,10:N0}", "Mode units in stock:", db.Products.Mode(p => p.UnitsInStock));
        Console.WriteLine("{0,-25} {1,10:$#,##0.00}", "Mode unit price:", db.Products.Mode(p => p.UnitPrice));
    }
}

Program.cs에서는 CustomExtensionMethods를 호출하도록 하고 예제를 실행하면 다음과 같은 결과를 표시할 것입니다.

참고로 $18.00인 products는 4개이고 재고가 0개인 products는 5개입니다.

6. LINQ to XML

LINQ to XML은 query에 대한 결과를 XML로 가져올 수 있도록 하는 LINQ 공급자입니다.

(1) LINQ to XML을 사용한 XML 생성

예를 들어 Products table을 XML로 변환하고자 한다면 products를 XML형식으로 출력하는 method를 다음과 같이 추가할 수 있습니다.

static void OutputProductsAsXml()
{
	using (Northwind db = new())
	{
        Product[] productsArray = db.Products.ToArray();

        XElement xml = new("products",
			from p in productsArray
			select new XElement("product", new XAttribute("id", p.ProductId), new XAttribute("price", p.UnitPrice), new XElement("name", p.ProductName)));
                
		Console.WriteLine(xml.ToString());
    }
}

Program.cs에서 OutputProductsAsXml method를 호출하도록 한 뒤 예제를 실행하면 다음과 같은 결과를 표시할 것입니다.

생성된 XML의 구조는 XML 요소와 위 예제에서 선언적으로 서술된 LINQ to XML문의 attribute와 일치합니다.

(2) LINQ to XML을 사용한 XML parsing

LINQ to XML을 사용하면 XML file을 쉽게 질의하거나 처리할 수 있습니다.

Project에 settings.xml이름의 XML file을 아래와 같이 추가합니다.

<?xml version="1.0" encoding="utf-8" ?>
<memberSettings>
	<add key="Name" value="hong" />
	<add key="Age" value="30" />
	<add key="WorkGroup" value="IT" />
</memberSettings>

Visual Studio 2022는 compile 된 application이 bin\Debug\net7.0 folder에서 실행되므로 추가한 XML을 해당 folder로 복사되도록 해야 합니다. 따라서 XML file을 선택하고 'Copy to Output Directory'의 속성을 'Copy always'로 변경해야 합니다.

Functions.cs에서는 아래와 같은 method를 추가합니다.

static void ProcessSettings()
{
	string path = Path.Combine(Environment.CurrentDirectory, "settings.xml");

	Console.WriteLine($"Settings file path: {path}");

	XDocument doc = XDocument.Load(path);
	var memberSettings = doc.Descendants("memberSettings").Descendants("add")
	.Select(node => new
	{
		Key = node.Attribute("key")?.Value,
		Value = node.Attribute("value")?.Value
	}).ToArray();
	foreach (var item in memberSettings)
	{
		Console.WriteLine($"{item.Key}: {item.Value}");
	}
}

위 method는 XML file을 load 하여 LINQ to XML을 사용해 memberSettings이름의 요소와 하위 add요소를 찾습니다. 그런 다음 XML을 Key와 Value 속성을 가진 익명 type의 array로 구체화한뒤 이를 열거하도록 합니다.

Program.cs에서 ProcessSettings method를 호출하고 예제를 실행하면 다음과 같은 결과를 표시할 것입니다.

[C# 12와 .NET 8] 10. Entity Framework Core

클리엘 — Thu, 7 Mar 2024 16:46:08 +0900

Entity Framework Core (이하 EF Core)는 SQLite나 SQL Server와 같은 관계형 database에 data를 읽고 쓰기 위한 객체-데이터 저장 mapping 기술입니다.

1. Database

Database에는 크게 2가지 종류가 있는데 하나는 RDBMS(Relational Database Management System)으로 SQL Server, PostgreSQL, MySQL, SQLite 등이 있고 다른 하나는 NoSQL로서 Azure Cosmos DB, Redis, MongoDB, Apache Cassandra 등이 있습니다.

관계형 database는 1970년대 개발된 것으로 SQL(Structured Query Language)을 통해 data를 질의합니다. 그 당시 data를 저장하는데는 많은 비용이 소모되었으므로 가능한 한 data의 중복을 최소화해야 했습니다. Data는 행(Row)과 열(Column)로 이루어진 table구조에 저장되었는데 일단 완성되고 나면 refactor 하기에는 까다로운 구조였습니다.

NoSQL은 단순히 SQL이 없음을 의미하지는 않습니다. 다른 뜻으로는 굳이 SQL일 필요가 없다는 의미가 될 수도 있습니다. 2000년대부터 개발되어온 NoSQL은 당시 Internet과 Web이 대중화되고 software에 관한 많은 학습이 이루어지던 시기였으며 또한 막대한 확장성과 고성능을 위해 설계되었고 최대한의 유연성을 제공함으로써 개발자들의 집입장벽을 낮추었습니다. 또한 구조를 강제하지 않음으로써 이들 사이에서는 언제든 schema를 변경할 수 있는 특징이 있습니다.

(1) 과거 Entity Framework

Entity Framework는 2008년 말 Service pack 1과 함께 .NET Framework 3.5의 일부로 처음 출시되었습니다. 그런 후 Entity Framework는 지금까지 계속해서 발전을 거듭하고 있습니다.

ORM은 mapping정의를 사용하여 class의 속성을 table의 column으로 연결합니다. 그러면 개발자는 관계형 table 혹은 NoSQL data store에 의해 제공된 다른 구조로 값을 어떻게 저장해야 할지 알아야 하는 대신 자신에게 친숙한 방식으로 다른 type 간 개체를 통해 상호작용할 수 있습니다.

.NET Framework에 포함된 EF의 version은 Entity Framework 6 (EF6)로서 성숙되고 안정적이며 복잡한 상속 model뿐 아니라 model을 정의하는 EDMX(XML file)와 그 외 몇 가지 향상된 기능을 지원합니다.

EF 6.3부터는 .NET Framework에서 별도의 package로 분리되어 .NET Core 3.0부터 지원이 가능하게 되었습니다. Web application이나 service와 같은 기존 project에서 cross-platform으로 이식하고 동작할 수 있으나 EF6는 cross-platform에서 동작시 일부 제한적이며 더 이상 새로운 기능이 추가되지 않으므로 legacy technology로 간주되고 있습니다.

● Entity Framework의 사용

Legacy technology인 Entity Framework를 .NET Core 3.0이나 이후 project에서 사용하려면 project file에서 아래와 같이 package 참조를 추가해야 합니다.

<PackageReference Include="EntityFramework" Version="6.4.4" />

예전 WPF app을 migration하는 경우와 같은 상황만 필요하다면 EF6를 사용해야 합니다.

(2) Entity Framework Core

진정한 cross-platform version인 EF Core는 Entity Framework와의 가장 큰 차이라고 할 수 있습니다. 비록 EF Core가 이름이 비슷하기는 하지만 EF6와는 분명히 다른 것입니다. 가장 최신의 EF Core version은 8이며 .NET8과 일치합니다.

EF Core 5부터는 .NET5와 그 이후만 지원하며 그 이하 EF Core 3은 .NET Standard 2.1을 지원하는 platform에서만 동작합니다. EF Core 3부터는 .NET Framework 4.8과 같은 .NET Standard 2.0 platform을 지원하지 않습니다.

EF Core 8은 .NET 8부터의 version을 target으로 합니다. 다시 말해 EF Core 8에서의 모든 새로운 기능은 .NET 8혹은 .NET 9에서만 사용할 수 있습니다. 만약 현재 .NET 7을 사용 중이라면 version 8에서 참조하는 EF Core package를 upgrade 할 것을 권장합니다.

전통적인 RDBMS뿐만 아니라 EF Core는 cloud기반의 비관계형 Database인 Azure Cosmos DB와 MongoDB등도 지원하고 있습니다.

EF Core는 많은 개선점을 가지고 있지만 이 모두를 다루지는 않을 것입니다. 예를 들어 EF Core 7과 함께 도입된 새로운 기능에는 JSON 문서를 저장하는 column을 가질 수 있는 database가 해당 문서를 질의하고 filter와 정렬 표현식에서 문서의 요소를 사용하는 JSON column을 지원하지만 EF Core 7에서 JSON column 기능은 단지 SQL Server를 위해서만 구현됩니다. 향후 EF Core version은 SQLite와 같은 다른 database도 추가될 테고 그 시점에 해당 내용을 다루게 될지도 모르지만 현재는 개발자가 알아야 할 기본적인 사항과 일부 유용한 기능을 살펴보는데만 집중할 것입니다.

(3) Database First와 Code First

EF core를 사용하기 위해서는 아래 2가지 방법을 선택할 수 있습니다.

Database First : Database가 이미 존재하는 상태에서 구조및 특징과 일치하는 model을 build 합니다.
Code First : Database가 존재하지 않는다면 model을 build 한 뒤 해당 구조 및 특징과 일치하는 database를 EF Core를 사용해 생성합니다.

(4) EF Core에서의 성능 향상

EF Core team은 EF Core의 성능향상을 위해 많은 노력을 기울여 왔습니다. 예를 들어 EF Core 7이 SaveChanges가 호출될 때 database에 대해 단일문만이 실행된다고 식별하는 경우 이전 version과 마찬가지로 명시적인 transaction을 생성하지 않습니다. 이와 같은 방식은 일반적인 경우에서 약 25% 정도의 성능향상을 기대할 수 있습니다.

이와 같이 내부적으로 적용된 최신의 개선사항들은 이들이 어떻게 동작하는가에 대한 이해가 없이도 사용하는 것만으로 그에 대한 혜택을 얻을 수 있습니다. 만약 이러한 세부적인 사항에 관심이 있다면(특히 일부 멋진 SQL Server 기능을 활용한 방식에 대해) EF Core team이 작성한 아래 글을 읽어보시길 바랍니다.

Announcing Entity Framework Core 7 Preview 6: Performance Edition (microsoft.com)

Announcing Entity Framework Core 7 Preview 6: Performance Edition - .NET Blog

Announcing Entity Framework Core 7 Preview 6 with update performance optimizations.

devblogs.microsoft.com

Announcing Entity Framework Core 6.0 Preview 4: Performance Edition (microsoft.com)

Announcing Entity Framework Core 6.0 Preview 4: Performance Edition - .NET Blog

EF Core 6.0 Preview 4 is here and has the best performance ever. Read this post to learn how the team boosted speed by 70% over EF Core 5.0!

devblogs.microsoft.com

(5) EF Core를 사용한 console app 만들기

우선 console app을 만들기 위해 csStudy10 solution을 생성하고 그 안에 WorkingWithEFCore이름의 Console App project를 추가합니다.

(6) Sample database

.NET을 통해 RDBMS를 어떻게 사용할 수 있을지를 알아보기 위해서는 적당한 수의 record와 적당한 수준의 복잡도를 가진 sample database가 필요합니다. 이를 위해 Microsoft는 몇 가지 sample database를 제공하고 있는데 너무 복잡한 것을 제외하고 사용가능한 가장 적합한 database로 1990년대 가장 먼저 생성된 database인 Northwind를 사용할 것입니다.

원격지나 로컬에 MSSQL Server를 설치하고 Northwind Database를 아래 script file로 생성합니다. MSSQL에 관한 제사한 사항은 아래 link를 참고하시기 바랍니다.

[Server/SQL Server] - [MSSQL] MS SQL Server 다운로드 및 설치/설정

[MSSQL] MS SQL Server 다운로드및 설치/설정

해당 포스팅에서 설명하는 MS SQL Server는 2019 Developer Edtion입니다. 인터넷에서 아래 주소로 이동합니다. SQL Server 다운로드 | Microsoft SQL Server 다운로드 | Microsoft 지금 Microsoft SQL Server 다운로드를 시

lab.cliel.com

참고로 해당 Database의 전체 구조는 아래와 같습니다.

위 구조를 보면 다음과 같은 사항을 알 수 있습니다.

각 category는 고유한 식별자, 이름, 설명, 이미지를 갖고 있습니다.
각 product는 고유한 식별자, 이름, 단위 단가, 재고 단위 및 기타 field를 갖고 있습니다.
각 product는 category의 고유한 식별자를 통해 특정 category에 할당됩니다.
Category와 product의 관계는 각 category가 product를 0개 이상 가질 수 있는 1대다의 관계입니다.

northwnd.sql

1.01MB

2. EF Core 설정

EF Core를 사용하기 전 간단히 어떤 EF Core database 공급자를 선택할 수 있는지를 알아보도록 하겠습니다..

(1) ADO.NET database provider

Entity Framework이전에는 ADO.NET이 사용되었습니다. ADO.NET은 EF와 비교해 database를 대상으로한 더 단순하면서도 더 효휼적인 API인데 DbConnection, DbCommand, and DbReader같은 추상화 class와 SqlConnection과 SqlCommand같은 공급자별 구현을 제공합니다.

만약 application에 대한 database로 MS SQL Server를 사용하기로 했다면 SqlConnectionStringBuilder class를 통해 정확한 연결문자열을 사용해야 합니다. 해당 class에는 database 연결 문자열에 대한 모든 가능한 속성을 가지고 있고 이를 개별적으로 설정하여 완성된 연결문자열을 얻을 수 있습니다. 또한 비밀번호와 같은 민감한 정보의 경우에는 source code에 직접 작성하는 대신 환경변수나 별도의 관리 system에서 가져올 수 있도록 해야 합니다.

다만 SQLite라면 연결문자열은 굳이 SqlConnectionStringBuilder class를 사용하지 않아도 될만큼 간단하므로 굳이 class를 사용할 필요는 없습니다.

SQLite와 SQL Server에 대한 EF Core database 공급자는 항상 ADO.NET Library위에 구현되므로 본질적으로 ADO.NET보다 더 느립니다. 게다가 ADO.NET은 더 나은 성능을 위해 독립적으로 사용될 수 있지만 EF Core database 공급자는 ORM의 특징에 더 중심을 두기 때문에 성능면에서 ADO.NET이 유리할 수 있습니다.

또한 EF Core은 아직 AOT 배포를 지원하지 않으므로 만약 AOT를 사용하기로 했다면 EF Core대신 ADO.NET Library를 사용해야 합니다. 물론 EF Core team은 EF Core를 native AOT에 어떻게 지원할지를 살펴보고 있지만 시간적으로 꽤 걸릴것으로 보입니다.

ADO.NET에 관한 더 자세한 내용은 아래 link를 참고하시기 바랍니다.

Microsoft ADO.NET - ADO.NET Provider for SQL Server | Microsoft Learn

(2) EF Core database provider (공급자)

특정한 database의 data에 접근하기 위해서는 어떻게 database와 효휼적으로 data를 주고받을지를 알고 있는 class를 사용해야 합니다.

EF Core database 공급자는 이러한 일련의 class들을 말하며 특정한 database에 최적화되어 있습니다. 이러한 공급자들 중에는 심지어 현재 process의 memory에 data를 저장하는 공급자도 존재하며 특히 외부 system과의 충돌을 피할 수 있기 때문에 고성능 단위 test에서 사용하기 적합합니다.

아래표는 저장소별 NuGet package에 배포된 package를 나타내고 있습니다.

용도	NuGet Package
SQL Server 2012 부터	Microsoft.EntityFrameworkCore.SqlServer
SQLite 3.7 부터	Microsoft.EntityFrameworkCore.SQLite
In-memory	Microsoft.EntityFrameworkCore.InMemory
Azure Cosmos DB SQL API	Microsoft.EntityFrameworkCore.Cosmos
MySQL	MySQL.EntityFrameworkCore
Oracle DB 11.2	Oracle.EntityFrameworkCore
PostgreSQL	Npgsql.EntityFrameworkCore.PostgreSQL

필요하다면 하나의 project에서 다수의 EF Core database 공급자를 설치할 수 있으며 각 package는 공급자별 type뿐만 아니라 필요한 여러 공유 type을 포함하고 있습니다.

(3) Database 연결

Database연결을 위해서는 연결을 위한 연결문자열을 설정해야 합니다. 위에서 MSSQL Server를 설치했다는 가정하에 해당 server IP 및 login 계정 등의 정보를 묶어 하나의 연결문자열을 만들어줍니다.

(4) Northwind database context class 정의

Northwind class는 database를 표현하는 데 사용될 것입니다. 여기에 EF core를 사용하기 위해서 class는 DbContext로부터 상속받아야 합니다. 해당 class는 database와 어떻게 소통할지를 알고 있으며 data의 질의와 수정/삭제등의 조작을 위해 동적으로 SQL문을 생성합니다.

DbContext로 부터 파생된 class는 OnConfiguring라는 이름의 override 된 method를 갖게 되는데 해당 method를 통해 database 연결 문자열을 설정합니다.

우선은 project에서 MSSQL을 위한 EF Core 공급자인 Microsoft.EntityFrameworkCore.SqlServer NuGet package를 설치하고 Northwind.cs 이름의 class file을 추가합니다.

Northwind.cs file에서는 EF Core에 대한 namespace를 import한뒤 Northwind class를 정의하고 DbContext부터 상속받도록 합니다. 그리고 OnConfiguring method에서 MSSQL Server를 사용하기 위한 option builder를 아래와 같이 구성해 줍니다.

public class Northwind : DbContext
{
    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        string connection = "Server=localhost;user id=sa;password=!123;Database=Northwind;MultipleActiveResultSets=true";
        Console.WriteLine($"Connection: {connection}");
        optionsBuilder.UseSqlServer(connection);
    }
}

Program.cs에서는 기존의 문을 모두 삭제하고 사용하는 database 공급자를 확인할 수 있는 구문을 아래와 같이 작성합니다.

Northwind db = new();
Console.WriteLine($"Provider: {db.Database.ProviderName}");

예제를 실행하면 다음과 같은 결과를 표시할 것입니다. 이를 통해 database 연결문자열과 사용 중인 database 공급자를 확인할 수 있습니다.

3. EF Core model 정의

EF Core는 규칙과 annotation attribute의 결합 및 Fluent API 문을 사용하여 runtime에서 entity model을 build 합니다. 따라서 class상에서 수행되는 모든 동작은 나중에 자동적으로 실제 database에서 수행되는 동작으로 변환될 수 있습니다. entity class는 table의 구조를 나타내며 class의 instance는 table의 row로서 표현됩니다.

우선 예제를 통해 model을 정의하기 위한 3가지 방식을 검토하고 이러한 기술을 구현하는 몇 가지 class를 만들어볼 것입니다.

(1) model을 정의하기 위한 EF Core 규칙

예제로 작성될 code는 아래 규칙을 사용할 것입니다.

Table의 이름은 예를 들어 Products와 같이 DbContext class안에 있는 DbSet<T> 속성의 이름과 연결된다고 간주합니다.
Column의 이름은 예를 들어 ProductId와 같이 entity model class에 있는 속성의 이름과 연결된다고 간주합니다.
string .NET type은 database의 nvarchar type이 된다고 간주합니다.
int .NET type은 database의 int type이 된다고 간주합니다.
Primary key는 Id 혹은 ID이름의 속성이 된다고 간주합니다. 그런데 속성의 이름은 entity model class가 Product로 명명될 때 ProductId 혹은 ProductID로 명명될 수 있습니다. 해당 속성이 integer type 이거나 Guid type이라면 이것은 또한 IDENTITY column(insert시 자동적으로 값이 부여됨)이 될 수 있다고 간주합니다.

이외에 알아야 할 많은 규칙들이 존해하며 자신만의 것을 정의할 수도 있습니다. 이와 관련해서는 아래 link를 참고하시기 바랍니다.

Creating and Configuring a Model - EF Core | Microsoft Learn

Creating and Configuring a Model - EF Core

Overview of creating and configuring a Entity Framework Core model via Fluent API, Data Annotations and conventions.

learn.microsoft.com

(2) Model을 정의하기 위한 EF Core annotation attribute 사용하기

물론 위에서 언급한 규칙만으로는 database개체와 class를 완전히 연결시키에 충분하지 못할 수 있습니다. 이때 model을 더욱 database에 근접시키기 위한 가장 간단한 방법은 annotation attribute를 적용하는 것입니다.

아래 표는 일반적으로 사용되는 몇 가지 attribute를 나타내고 있습니다.

Attribute	Description
[Required]	값은 null이 될 수 없습니다. .NET 8에서는 DisallowAllDefaultValues 매개변수를 통해 예를 들어 int가 0이 되는 것처럼 type이 그에 따른 기본값이 되는것을 방지할 수 있습니다.
[StringLength(50)]	값은 50문자길이를 넘을 수 없습니다.
[Range(1, 10)]	값이 지정된 범위에 있도록 합니다. 이와 관련하여 .NET 8에서는 MinimumIsExclusive와 MaximumIsExclusive라는 매개변수가 존재합니다.
[RegularExpression(표현식)]	값은 지정한 정규표현식과 일치해야 합니다.
[Column(TypeName = "money", Name = "UnitPrice")]	Column의 이름(Name)과 Type(TypeName)을 지정합니다.

예를 들어 database에서 product name의 최대 길이는 40이며 값은 null일 수 없습니다. 이와 같은 사실은 어떻게 Products라는 table이 지정한 data type, key와 기타 제약사항을 가진 column과 함께 생성될지를 정의하는 DDL(Data Definition Language) 문을 통해 알 수 있는데

CREATE TABLE [dbo].[Products](
	[ProductId] [int] IDENTITY(1,1) NOT NULL,
	[ProductName] [nvarchar](40) NOT NULL,
	[SupplierId] [int] NULL,
	[CategoryId] [int] NULL,
	[QuantityPerUnit] [nvarchar](20) NULL,
	[UnitPrice] [money] NULL,
	[UnitsInStock] [smallint] NULL,
	[UnitsOnOrder] [smallint] NULL,
	[ReorderLevel] [smallint] NULL,
	[Discontinued] [bit] NOT NULL,
 CONSTRAINT [PK_Products] PRIMARY KEY CLUSTERED 
(
	[ProductId] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]
GO

...

이러한 사항을 Product class에 반영하려면 아래와 같이 attribute를 적용할 수 있습니다.

[Required]
[StringLength(40)]
public string ProductName { get; set; }

어떤 경우에는 .NET type과 database type사이를 연결시키는 데 사용가능한 attribute가 분명하지 않을 수 있습니다. 예를 들어 database에서 Products의 UnitPrice column type이 money인데 .NET은 money라는 type이 존재하지 않으므로 이런 경우에는 아래와 같이 data범위가 유사한 decimal을 대신 사용하고 Column attribute를 통해 database의 type을 명시합니다.

[Column(TypeName = "money")]
public decimal? UnitPrice { get; set; }

(3) Model을 정의하기 위한 EF Core Fluent API 사용하기

Model을 정의할 수 있는 또 다른 방법은 Fluent API를 사용하는 것입니다. API는 attribute대신 사용할 수 있으며 뿐만 아니라 속성 외에도 사용할 수 있습니다. 예를 들어 ProductName속성을 정의하기 위해 속성에 2개의 attribute를 적용하는 대신 동등한 Fluent API문을 database context class의 OnModelCreating method에 아래와 같이 작성할 수 있습니다.

modelBuilder.Entity<Product>()
 .Property(product => product.ProductName)
 .IsRequired()
 .HasMaxLength(40);

위와 같이 하면 entity model class를 단순하게 유지할 수 있습니다.

● Fluent API를 사용한 data 제공

Fluent API를 사용함으로써 생기는 또 다른 이점은 database를 채우기 위해 초기 data를 제공할 수 있다는 것입니다. EF Core는 반드시 실행되어야 하는 insert, update, delete와 같은 동작을 자동으로 실행합니다.

예를 들어 새로운 database에서 Product table은 최소 하나의 행을 가져야 한다면 HasData method를 아래와 같이 호출할 수 있습니다.

modelBuilder.Entity<Product>().HasData(new Product {
    ProductId = 1,
    ProductName = "Chai",
    UnitPrice = 8.99M
});

예제에서 사용할 model은 이미 data가 존재하는 database와 연결하게 될 것이므로 위와 같은 방법은 사용하지 않을 것입니다.

(4) Northwind table에 대한 EF Core model 구축

위에서 EF Core model을 정의하는 방법을 알게 되었으므로 이를 통해 Northwind database에 대한 2개 table을 표현하는 model을 만들 것입니다.

2개 entity class는 서로를 참조할 것이므로 compiler error를 피하기 위해 처음에는 어떠한 member도 없이 class를 만들 것입니다.

WorkingWithEFCore project에서 Category.cs와 Product.cs이름의 class file을 추가합니다. 그리고 Category.cs에서 Category class를 정의하고 Product.cs에서 Product class를 정의합니다.

namespace WorkingWithEFCore
{
    public class Category
    {
    }
}

namespace WorkingWithEFCore
{
    public class Product
    {
    }
}

● Category와 Product entity class정의하기

Entity model인 Category class는 Categories table의 row를 나타내는 데 사용될 것입니다. 이 table은 아래와 같이 4개의 column을 가지고 있습니다.

CREATE TABLE [dbo].[Categories](
	[CategoryId] [int] IDENTITY(1,1) NOT NULL,
	[CategoryName] [nvarchar](15) NOT NULL,
	[Description] [ntext] NULL,
	[Picture] [image] NULL,
 CONSTRAINT [PK_Categories] PRIMARY KEY CLUSTERED 
(
	[CategoryId] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO

따라서 model을 정의하기 위한 다음의 규칙을 감안해야 합니다.

3~4개의 속성 (Picture column은 사용하지 않을 것입니다.)
Primary key
Products table과의 1:N 관계

Description column을 database type과 정확히 연결시키기 위해서는 string 속성에 Column attribute에 대한 적용이 필요합니다. 나중에는 Fluent API를 사용하여 CategoryName이 null일 수 없고 최대 15자로 제한됨을 정의할 것입니다.

Category entity model class를 아래와 같이 변경합니다.

using System.ComponentModel.DataAnnotations.Schema; // [Column] attribute

namespace WorkingWithEFCore
{
    public class Category
    {
        public Category()
        {
            // products를 Cateogry로 추가시킬 수 있도록 하기 위해서는 navigation 속성을 빈 collection으로 초기화 해야 합니다.
            Products = new HashSet<Product>();
        }

        //아래 속성은 database의 column과 일치합니다.
        public int CategoryId { get; set; }

        public string? CategoryName { get; set; }

        [Column(TypeName = "ntext")]
        public string? Description { get; set; }

        //Table간의 관계를 나타내기 위해 정의하는 navigation속성입니다.
        public virtual ICollection<Product> Products { get; set; }
    }
}

Product class도 역시 아래와 같이 변경합니다.

using System.ComponentModel.DataAnnotations; // [Required], [StringLength]
using System.ComponentModel.DataAnnotations.Schema; // [Column]

namespace WorkingWithEFCore
{
    public class Product
    {
        public int ProductId { get; set; } // primary key

        [Required]
        [StringLength(40)]
        public string ProductName { get; set; } = null!;

        [Column("UnitPrice", TypeName = "money")]
        public decimal? Cost { get; set; } // Column attribute를 적용함으로서 여기서 속성의 이름은 column의 이름으로 사용되지 않습니다.

        [Column("UnitsInStock")]
        public short? Stock { get; set; }

        public bool Discontinued { get; set; }

        // 이 2개의 속성은 Categories table에 대한 외래key를 정의합니다.
        public int CategoryId { get; set; }
        public virtual Category Category { get; set; } = null!;
    }
}

위 예제에서는 다음 사항에 주목합니다.

Product class는 Products table의 row를 표현하는 데 사용되며 10개 정도의 column을 가지고 있습니다.
Table로부터의 모든 column을 class의 속성으로 포함시킬 필요는 없습니다. 예제에서도 단지 ProductId, ProductName, UnitPrice, UnitsInStock, Discontinued, CategoryId에 대한 6개의 속성만을 일치시키고 있습니다.
속성으로 일치되지 않는 column은 class를 통해 읽거나 설정할 수 없습니다. 새로운 개체를 생성하는데 class를 사용한다면 table의 새로운 row에서 일치되지 않는 column은 NULL이 되거나 다른 기본값이 됩니다. 누락된 column이 생기는 경우 이들 column은 선택적이거나 database에서 기본값을 설정했거나 runtime에서 예외가 발생하는지를 확인해야 합니다. 지금 예제의 경우에 row는 이미 data값을 가지고 있으며 application에서 해당 값들을 읽을 필요가 없으므로 무시하기로 합니다.
예제에서 Cost속성처럼 Column의 이름과는 다른 이름으로 속성을 정의할 수도 있습니다. 이런 경우 속성에 [Column] attribute를 적용하고 여기에 UnitPrice처럼 column의 이름을 지정할 수 있습니다.
마지막 속성인 CategoryId는 각 product에서 부모 category와 일치시키는 데 사용되는 Category 속성과 연결됩니다.

2개의 entity를 연결시키는 2개의 속성인 Category.Products와 Product.Category는 둘 다 virtual로 수식되었습니다. 이는 EF Core가 lazy loading과 같이 추가 기능을 제공하기 위해 해당 속성을 상속하고 override 할 수 있도록 합니다.

(5) Northwind database context class에 table추가하기

DbContext로부터 파생된 class에서는 최소 하나의 DbSet<T> type에 대한 속성을 정의해야 합니다. 이 속성은 table을 의미합니다. EF Core에게 table의 가진 각 column이 어떤 것인지를 말해주기 위해 DbSet<T>속성은 generic을 사용하여 table의 row를 나타내는 class를 지정하고 해당 class는 column을 나타내는 속성을 가지게 됩니다.

DbContext 파생 class는 선택적으로 OnModelCreating이름의 override method를 가질 수 있습니다. 여기에 Fluent API를 class에 attribute를 적용하는 대신 작성할 수 있습니다.

Northwind class에서 Categories와 Products에 대한 2개의 table과 OnModelCreating method를 정의하는 문을 아래와 같이 추가합니다.

public class Northwind : DbContext
{
    public DbSet<Category>? Categories { get; set; }
    public DbSet<Product>? Products { get; set; }

    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        string connection = "Server=localhost;user id=sa;password=!123;Database=Northwind;MultipleActiveResultSets=true";
        Console.WriteLine($"Connection: {connection}");
        optionsBuilder.UseSqlServer(connection);
    }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        // Fluent API를 사용해 CategoryName의 최대 길이를 15자로 제한합니다.
        // 이는 attribute를 적용하는 것으로도 가능합니다.
        modelBuilder.Entity<Category>()
        .Property(category => category.CategoryName)
        .IsRequired() // NOT NULL
        .HasMaxLength(15);
    }
}

(6) dotnet-ef 도구 설정

dotnet이라는 .NET CLI 도구는 EF Core사용에 유용한 기능으로 확장될 수 있습니다. 이 기능은 이전 model에서 새로운 model로 migration을 생성하고 적용하는 것과 같은 design-time작업을 수행할 수 있으며 기존 database로부터 code를 생성할 수도 있습니다.

dotnet ef 명령줄 도구는 자동적으로 설치되지 않으므로 global이나 local도구를 통해 package를 설치해야 합니다. 만약 해당 도구의 이전 version이 이미 설치된 경우라면 기존 version을 모두 삭제해야 합니다.

Terminal에서 우선 dotnet-ef가 global도구로 설치되어 있는지를 확인합니다.

dotnet tool list --global

위와 같이 이전 version이 이미 설치되어 있다면 아래와 같은 방식으로 도구를 제거할 수 있습니다.

dotnet tool uninstall --global dotnet-ef

예제의 화면상으로 version은 7.0.4인데 아래 명령을 통해 최신 version으로 update할 수 있습니다.

dotnet tool update --global dotnet-ef

설치는 uninstall대신 install을 사용합니다.

dotnet tool install --global dotnet-ef

필요하다면 OS별 지침에 따라 PATH 환경 변수에 dotnet tools directory를 추가할 수 있습니다.

(7) 기존 database를 사용한 Scaffolding model

기존 database에서 model을 표현하기 위한 class를 생성하는 것을 reverse engineering이라고 하며 이때 도구를 사용하는 처리를 Scaffolding이라고 합니다. 좋은 Scaffolding 도구는 자동적으로 생성된 class를 확장하고 확장된 class의 손실 없이 이들 class를 재생성할 수 있도록 합니다.

도구를 사용해 class를 재생성할 일이 없다고 하더라도 원하는 만큼 자동적으로 생성된 class에서 code를 자유롭게 변경할 수 있습니다. 도구에 의해 생성된 code는 그저 최상의 근사치일 뿐입니다.

도구를 사용하지 않고도 최상의 결과를 얻을 수 있다면 굳이 도구사용을 시도할 필요는 없습니다.

위에서 수동적으로 생성했던 것처럼 도구가 같은 model을 생성하는지 확인해 보도록 하겠습니다.

우선 WorkingWithEFCore project에서 최신의 Microsoft.EntityFrameworkCore.Design package를 설치하고 project를 build 합니다. 그런 뒤 terminal에서 WorkingWithEFCore folder(csproj project file이 있는)로 찾아 들어가고 아래 명령을 통해 AutoGenModels라는 folder에 Categories와 Products에 대한 model을 생성하도록 합니다.

dotnet ef dbcontext scaffold "Server=localhost;user id=sa;password=!123;Database=Northwind;TrustServerCertificate=true" Microsoft.EntityFrameworkCore.SqlServer --table Categories --table Products --output-dir AutoGenModels --namespace WorkingWithEFCore.AutoGen --data-annotations --context Northwind

위 명령줄에 사용된 것 중 server주소와 id 및 암호는 귀하의 server에 따라 다릅니다.

위 명령줄에 사용된 각 항목의 의미는 아래와 같습니다.

명령어는 dbcontext scaffold입니다.
연결문자열은 Server=localhost;user id=sa;password=!123;Database=Northwind;TrustServerCertificate=true 입니다.
Database 공급자는 Microsoft.EntityFrameworkCore.SqlServer 입니다.
Model로 생성하기 위한 table은 --table Categories --table Products로 지정합니다.
Model은 --output-dir AutoGenModels로 지정한 경로에 생성합니다.
Model의 namespace는 --namespace WorkingWithEFCore로 지정합니다.
Fluent API와 data annotation 사용을 위해 --data-annotations를 지정합니다.
context명칭을 --context Northwind로 지정합니다.

위 명령을 실행하면 정상적으로 처리되는 경우 아래와 같은 결과를 표시하게 됩니다.

생성이 완료되면 AutoGenModels folder를 열어 아래 3개 file이 생성되어 있는지를 확인합니다.

Northwind.cs
Product.cs
Category.cs

이 중에서 Category file을 열어 이전에 수동으로 작성한 file과의 차이점을 확인합니다.

using System;
using System.Collections.Generic;
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;
using Microsoft.EntityFrameworkCore;

namespace WorkingWithEFCore.AutoGen;

[Index("CategoryName", Name = "CategoryName")]
public partial class Category
{
    [Key]
    public int CategoryId { get; set; }

    [StringLength(15)]
    public string CategoryName { get; set; } = null!;

    [Column(TypeName = "ntext")]
    public string? Description { get; set; }

    [Column(TypeName = "image")]
    public byte[]? Picture { get; set; }

    [InverseProperty("Category")]
    public virtual ICollection<Product> Products { get; set; } = new List<Product>();
}

Entity class에는 [Index] attribute가 적용되어 있습니다. 이는 EF Core 5.0에서 도입된 것으로 index가 있어야 하는 속성을 나타냅니다. 이전 version에서는 단지 Fluent API를 통해서만 index를 정의할 수 있었습니다. 기존 database로의 작업에서는 이것이 필요하지 않았지만 code를 통해 초기 database를 재생성하고자 한다면 해당 정보가 필요할 것입니다.
Database에서 table의 이름은 Categories이지만 dotnet-ef 도구는 Humanizer third-party library를 사용하여 class의 이름을 Category로 단수화 하였습니다. 이는 단일 entity를 생성할 때 이름을 더욱 자연스럽게 만들기 위한 것입니다.
Entity class는 partial keyword를 사용하여 선언되었으므로 여기에 추가적인 code가 필요할 때 일치하는 partial class를 생성할 수 있습니다. 이를 통해 신규로 추가한 code의 손실 없이 도구를 사용해 entity class를 재생성할 수 있습니다.
CategoryId속성은 [Key] attribute가 적용되었습니다. 이는 해당 entity가 primary key임을 나타냅니다. 속성의 data type은 SQL Server에서의 int입니다.
Products 속성은 [InverseProperty] attribute를 사용하여 Product entity class상에서 Category 속성으로 외래 key의 관계를 정의하고 있습니다.

Product.cs file도 열어 이전에 수동적으로 생성한 것과의 차이를 확인합니다.

Northwind.cs file도 역시 이전에 수동적으로 생성한 것과의 차이를 확인합니다.

using System;
using System.Collections.Generic;
using Microsoft.EntityFrameworkCore;

namespace WorkingWithEFCore.AutoGen;

public partial class Northwind : DbContext
{
    public Northwind()
    {
    }

    public Northwind(DbContextOptions<Northwind> options)
        : base(options)
    {
    }

    public virtual DbSet<Category> Categories { get; set; }

    public virtual DbSet<Product> Products { get; set; }

    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
#warning To protect potentially sensitive information in your connection string, you should move it out of source code. You can avoid scaffolding the connection string by using the Name= syntax to read it from configuration - see https://go.microsoft.com/fwlink/?linkid=2131148. For more guidance on storing connection strings, see http://go.microsoft.com/fwlink/?LinkId=723263.
        => optionsBuilder.UseSqlServer("Server=localhost;user id=sa;password=!123;Database=Northwind;TrustServerCertificate=true");

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Entity<Product>(entity =>
        {
            entity.Property(e => e.ReorderLevel).HasDefaultValueSql("((0))");
            entity.Property(e => e.UnitPrice).HasDefaultValueSql("((0))");
            entity.Property(e => e.UnitsInStock).HasDefaultValueSql("((0))");
            entity.Property(e => e.UnitsOnOrder).HasDefaultValueSql("((0))");

            entity.HasOne(d => d.Category).WithMany(p => p.Products).HasConstraintName("FK_Products_Categories");
        });

        OnModelCreatingPartial(modelBuilder);
    }

    partial void OnModelCreatingPartial(ModelBuilder modelBuilder);
}

Northwind data context class는 parital이므로 code를 확장하고 이후에 재생성할 수 있습니다.
위의 결과를 보면 2개의 생성자를 갖고 있음을 알 수 있는데 매개변수가 없는 기본 생성자와 options 매개변수를 가진 생성자가 그것입니다. 이는 runtime에서 연결문자열을 지정하고자 할 때 유용하게 사용될 수 있습니다.
위 결과에는 나타나지 않았지만 Categories와 Products table을 나타내는 2개의 DbSet<T>속성이 null-forgiving연산자값으로 설정될 수 있습니다. 이는 static compiler analysis가 compile time에서 경고가 발생되는 것을 방지하기 위함이며 runtime에서는 영향을 주지 않습니다.
위 결과에는 나타나지 않았지만 OnConfiguring method안에서는 options가 생성자에서 지정되지 않은 경우를 대비한 다음과 같은 code가 만들어질 수 있습니다.

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
    if (!optionsBuilder.IsConfigured)
    {
        //#warning To protect potentially sensitive information in your connection string, you should move it out of source code. You can avoid scaffolding the connection string by using the Name= syntax to read it from configuration - see https://go.microsoft.com/fwlink/?linkid=2131148. For more guidance on storing connection strings, see http://go.microsoft.com/fwlink/?LinkId=723263.
        optionsBuilder.UseSqlServer("Server=localhost;user id=sa;password=!123;Database=Northwind;TrustServerCertificate=true");
    }
}

또한 연결 문자열에 민감한 정보를 hardcode 하지 말 것을 알리기 위한 compiler 경고를 포함하고 있습니다.
OnModelCreating method안에서는 Fluent API가 Product에 대한 entity class를 구성하기 위해 사용되었으며 OnModelCreatingPartial이름의 partial method를 호출합니다. 이를 통해 별도의 Fluent API configuration을 추가하기 위해 partial Northwind class를 따로 만들어 partial method method를 구현할 수 있고 model class를 재생성한다고 하더라도 추가한 code에는 영향을 주지 않을 수 있습니다.

(8) Reverse engineering template 사용자 정의하기

EF Core 7에서 새롭게 도입된 기능 중 하나이며 dotnet-ef scaffolding tool에 의해 자동적으로 생성되는 code를 개별적으로 정의할 수 있습니다. 해당 내용에 관해서는 아래 link를 참고하시기 바랍니다.

Custom Reverse Engineering Templates - EF Core | Microsoft Learn

Custom Reverse Engineering Templates - EF Core

Using T4 text templates to customize the scaffolded code when reverse engineering an Entity Framework Core model from a database

learn.microsoft.com

(9) 사전 규칙 model 구성하기

Entity type과 그들의 속성에 의존하는 규칙에서 model이 더 복잡해질수록 이들을 table과 column에 성공적으로 연결시키기는 더욱 어려워집니다. 따라서 model을 분석하고 생성하기 전에 스스로에 대한 규칙을 정의할 수 있다면 해당 기능은 매우 유용하게 사용될 수 있습니다.

예를 들어 모든 string 속성은 최대 문자길이가 기본적으로 50까지만 허용된다거나 사용자 interface를 구현하는 모든 속성은 연결에서 제외되어야 한다는 규칙을 정의하고자 한다면 다음과 같이 구현할 수 있습니다.

protected override void ConfigureConventions(ModelConfigurationBuilder configurationBuilder)
{
    configurationBuilder.Properties<string>().HaveMaxLength(50);
    configurationBuilder.IgnoreAny<IUserInterface>();
}

4. EF Core model 질의하기

위 과정을 통해 Northwind database와 2개의 table에 연결되는 model을 만들게 되었습니다. 이로서 이제는 해당 table에서 data를 가져오기 위해 LINQ query를 작성할 수 있습니다. LINQ query를 작성하는 자세한 사항은 추후에 알아보기로 하고 이번예제에서는 간단하게만 사용해 보도록 하겠습니다.

project에 Queries.cs class file을 추가하고 그 안에 QueryingCategories method와 함께 partial Program class를 아래와 같이 정의합니다.

partial class Program
{
    static void QueryingCategories()
    {
        using (Northwind db = new())
        {
            IQueryable<Category>? categories = db.Categories?.Include(c => c.Products);

            if ((categories is null) || (!categories.Any()))
            {
                Console.WriteLine("Failed");
                return;
            }
                
            foreach (Category c in categories)
            {
                Console.WriteLine($"{c.CategoryName} has {c.Products.Count} products.");
            }
        }
    }
}

예제에서는 다음 사항에 주목합니다.

예제에서는 database를 관리할 Northwind class의 instance를 생성하고 있습니다. Database context instance는 작업단위 짧은 생명주기를 위해 설계되었으며 가능한 한 빨리 dispose 되어야 하므로 using문을 사용하였습니다.
관련된 projects를 포함한 전체 category를 위한 query를 생성합니다. 여기서 Include는 확장 method이며 사용을 위해서는 Microsoft.EntityFrameworkCore namespace를 import 해야 합니다.
가져온 category를 열거하면서 해당 category의 이름과 포함된 project의 수를 표시합니다.

if 문에서 || 사이의 순서는 중요한 부분입니다. categories가 null인지를 우선적으로 확인해야 하는데 만약 그 결과가 true라면 두 번째 문을 실행되지 않을 것이며 따라서 Any() member에 접근할 때 NullReferenceException 예외가 발생하지 않을 것입니다.

Program.cs에서는 Northwind instance를 생성하고 database provider의 이름을 출력하는 두 문을 주석처리하고 QueryingCategories method를 아래와 같이 호출합니다.

QueryingCategories();

위 예제를 실행하면 다음과 같은 결과를 표시할 것입니다.

(1) 포함된 entity filtering

EF Core 5에서는 filtered include를 도입하여 결과에서 반환된 entity를 filter 하기 위해 호출하는 Include method안에서 lambda 식을 명시할 수 있게 되었습니다.

Queries.cs에서 FilteredIncludes method를 아래와 같이 정의하고 아래 작업을 수행하는 문을 추가합니다.

Database를 다룰 Northwind class의 instance를 생성합니다.
사용자에게 재고의 최솟값을 입력받을 수 있도록 요청합니다.
재고가 입력된 값보다 같거나 그 보다 많은 product를 가진 Category를 가져오기 위해 query를 생성합니다.
Category와 Product를 열거하면서 각각에 대한 이름과 재고를 출력합니다.

static void FilteredIncludes()
{
    using (Northwind db = new())
    {
        string? input;
        int stock;

        do
        {
            Console.Write("Enter a minimum for units in stock: ");
            input = Console.ReadLine();

        } while (!int.TryParse(input, out stock));

        IQueryable<Category>? categories = db.Categories?.Include(c => c.Products.Where(p => p.Stock >= stock));

        if ((categories is null) || (!categories.Any()))
        {
            Console.WriteLine("No categories found.");
            return;
        }

        foreach (Category c in categories)
        {
            Console.WriteLine($"{c.CategoryName} has {c.Products.Count} products with a minimum of {stock} units in stock.");

            foreach (Product p in c.Products)
            {
                Console.WriteLine($"{p.ProductName} has {p.Stock} units in stock.");
            }
        }
    }
}

Program.cs에서 위의 FilteredIncludes method를 호출하면 다음과 같은 결과를 표시할 것입니다.

Windows 10 Fall Creators Update이전 Windows version에서 제공하는 console에는 하나의 제한사항이 있습니다. 기본적으로 console은 Unicode문자를 표시할 수 없습니다. 만약 예제를 실행하는 computer가 그렇다면 임시로 character set으로 알려진 code page를 console에서 아래 명령으로 Unicode UTF-8로 변경함으로써 해결할 수 있습니다.(예제를 실행시키기 전에)

chcp 65001

혹은 source에서 unicode문자를 표시하기전 아래 문을 넣어두면 정상적으로 unicode문자를 표시할 수 있게 됩니다.

Console.OutputEncoding = System.Text.Encoding.UTF8;

(2) Product filtering 하고 sorting 하기

Data를 filtering 하고 sorting 하기 위해 Queries.cs에서 QueryingProducts method를 정의하고 그 안에 아래의 동작을 위한 구문을 추가합니다.

Database를 다룰 Northwind class의 instance를 생성합니다.
사용자에게 products에 대한 가격을 입력하도록 요청합니다.
LINQ를 통해 입력한 가격보다 더 높은 products를 가져오는 query를 생성합니다.
결과를 순회하면서 ID, name, cost(예제에서의 단위는 dollar입니다.)와 재고를 표시하도록 합니다.

static void QueryingProducts()
{
    using (Northwind db = new())
    {
        string? input;
        decimal price;
        do
        {
            Console.Write("Enter a product price: ");
            input = Console.ReadLine();
        } while (!decimal.TryParse(input, out price));

		IQueryable<Product>? products = db.Products?.Where(product => product.Cost > price).OrderByDescending(product => product.Cost);

		if ((products is null) || (!products.Any()))
		{
			Console.Write("No products found.");
			return;
		}

		foreach (Product p in products)
		{
			Console.WriteLine("{0}: {1} costs {2:$#,##0.00} and has {3} in stock.", p.ProductId, p.ProductName, p.Cost, p.Stock);
		}
	}
}

예제에서의 '!products.Any()'는 'products.Count() == 0'과 같이 count를 확인하는 것보다 더 효휼적으로 작동합니다.

Program.cs에서 QueryingProducts method를 호출하면 사용자에게 price입력을 요청하고 그 결과를 다음과 같이 표시할 것입니다.

만약 위 입력요청에서 price를 500과 같이 입력하면 결과는 다음처음 달라질 수 있습니다.

(3) 생성된 SQL 확인하기

위와 같은 상황에서 C# code가 실제 어떤 SQL문을 생성하는지 궁금할 수 있습니다. EF Core 5부터는 생성된 SQL문을 보기 위한 빠르고 편리한 다음 방법을 도입하였습니다.

FilteredIncludes method에서 foreach문을 사용해 query를 열거하기 전에 생성된 SQL문을 출력하는 다음 문을 추가합니다.

if ((categories is null) || (!categories.Any()))
{
    Console.WriteLine("No categories found.");
    return;
}

Console.WriteLine($"ToQueryString: {categories.ToQueryString()}");

예제를 실행하면 다음과 같이 생성된 SQL문을 확인해 볼 수 있습니다.

(4) EF Core Logging

EF Core와 database간상호작용을 살펴보기 위해 logging을 사용할 수 있습니다. 이때 logging은 console이나 Debug, Trace 또는 file이 될 수 있습니다.

기본적으로 EF Core logging은 민감한 data는 제외합니다. 만약 이러한 data도 모두 포함하고자 한다면(특히 개발과정 동안에는) EnableSensitiveDataLogging method를 호출할 수 있습니다. 반대로 완성된 Application을 출시하는 경우 해당 기능을 disable 해야 합니다.

Northwind.cs의 OnConfiguring method아래에 console로의 log를 위한 아래 문을 추가합니다.

optionsBuilder.UseSqlServer(connection);
optionsBuilder.LogTo(Console.WriteLine).EnableSensitiveDataLogging();

LogTo는 Action<string> delegate를 필요로 하며 EF core는 각 log message에 대한 문자열값을 전달함으로써 해당 delegate를 호출할 것입니다. 따라서 위 예제처럼 Console class의 WriteLine method를 전달하는 것은 logger에게 각 method를 console에 쓰도록 하는 것입니다.

예제를 실행하면 다음과 같이 각 log를 상세하게 표시할 것입니다.

Log는 사용 중인 database 공급자와 code 편집기 및 향후 EF Core의 개선점에 따라 달라질 수 있습니다. 일반적으로 연결을 열거나 명령 실행과 같은 다른 event마다 다음과 같이 다른 event ID를 가지고 있습니다.

RelationalEventId.ConnectionOpening[20000] : 원격 server 혹은 file 경로를 포함
RelationalEventId.ConnectionOpened[20001] : 원격 server 혹은 file 경로를 포함
RelationalEventId.CommandExecuting[20100] : 실행하는 SQL문 포함

● 공급자별 값을 통한 log filtering

event ID값과 그 의미는 EF Core 공급자에 따라 달라질 수 있습니다. LINQ query가 SQL 문으로 어떻게 변환되고 실행되는지를 알고자 한다면 20100의 Id값을 가진 event ID를 확인하면 됩니다.

이를 위해 아래에서와 같이 Northwind.cs에서 LogTo method를 변경하여 Id가 20100인 event만 출력하도록 합니다.

optionsBuilder.LogTo(Console.WriteLine, new[] { RelationalEventId.CommandExecuting }).EnableSensitiveDataLogging();

예제를 실행하면 다음과 같이 log 된 SQL문을 확인할 수 있습니다.

● Query tag를 통한 logging

LINQ query를 logging 할 때 복잡한 상황에서 log message를 서로 관련시키기가 어려울 수 있습니다. EF Core 2.2에서는 query tag 기능을 도입하여 SQL 문을 log에 추가시키기 한결 편리해졌습니다.

아래와 같이 TagWith method를 사용해 LINQ query에 적용합니다.

IQueryable<Category>? categories = db.Categories?.TagWith("*****Category*****").Include(c => c.Products.Where(p => p.Stock >= stock));

위와 같이 하면 log에 SQL comment를 다음과 같이 추가하게 됩니다.

(5) Like를 사용한 pattern matching

EF Core에서는 pattern matching을 위한 Like와 같이 일반적인 SQL문을 지원하고 있습니다.

Queries.cs에서 다음과 같이 QueryingWithLike이름의 method를 추가합니다.

static void QueryingWithLike()
{
    using (Northwind db = new())
    {
        Console.Write("Enter part of a product name: ");
        string? input = Console.ReadLine();

        if (string.IsNullOrWhiteSpace(input))
        {
            Console.WriteLine("You did not enter part of a product name.");
            return;
        }

        IQueryable<Product>? products = db.Products?.Where(p => EF.Functions.Like(p.ProductName, $"%{input}%"));

        if ((products is null) || (!products.Any()))
        {
            Console.WriteLine("No products found.");
            return;
        }

        foreach (Product p in products)
        {
            Console.WriteLine("{0} has {1} units in stock. Discontinued? {2}", p.ProductName, p.Stock, p.Discontinued);
        }
    }
}

위 예제에서는 logging을 사용하고 있으며 사용자에게 product에 대한 이름 중 일부에 대한 입력을 요구하고 있습니다. 사용자가 입력을 완료하면 EF.Functions.Like method를 사용해 입력된 내용을 ProductName 속성으로 검색을 시도합니다.

여기서 일치하는 product가 존재하면 각 product에 대한 이름과 재고 그리고 생산여부등을 출력합니다.

Program.cs에서 기존의 method 호출을 주석처리하고 위에서 추가한 QueryingWithLike method를 호출하도록 합니다. 그런 뒤 예제를 실행하면 다음과 같은 결과를 표시할 것입니다.

(6) Query를 통한 임의 숫자 생성하기

EF Core 6에서는 한 가지 유용한 기능인 EF.Functions.Random을 도입하여 0과 1 사이에 배타적인 의사난수를 반환하는 database기능과 연결할 수 있습니다. 예를 들어 table에서 임의의 row를 선택하기 위해 전체 row 수에서 임의의 숫자를 곱할 수 있습니다.

Queries.cs에서 GetRandomProduct이름의 method를 아래와 같이 추가합니다.

static void GetRandomProduct()
{
    using (Northwind db = new())
    {
        int? rowCount = db.Products?.Count();

        if (rowCount == null)
        {
            Console.WriteLine("Products table is empty.");
            return;
        }

        Product? p = db.Products?.FirstOrDefault(p => p.ProductId == (int)(EF.Functions.Random() * rowCount));

        if (p == null)
        {
            Console.WriteLine("Product not found.");
            return;
        }

        Console.WriteLine($"Random product: {p.ProductId} {p.ProductName}");
    }
}

Program.cs에서 GetRandomProduct method를 호출하면 아래와 같은 결과를 표시할 것입니다.

(7) Global filter 정의하기

Northwind의 products, 즉 제품은 단종될 수 있을 것입니다. 따라서 단종된 product는 결과에 반영되지 않도록 하는 것이 합리적일 수 있는데 products를 조회하는 모든 곳에 where를 사용하여 이러한 사항을 filtering 하기보다는 global로 filter를 적용하여 where를 사용하지 않고 해당 filtering을 products를 조회하는 모든 곳에 적용할 수 있습니다.

Northwind.cs의 OnModelCreating method아래에 아래와 같이 단종된(discontinued) product를 제거하는 global filter를 추가합니다.

modelBuilder.Entity<Category>()
            .Property(category => category.CategoryName)
            .IsRequired() // NOT NULL
            .HasMaxLength(15);
modelBuilder.Entity<Product>().HasQueryFilter(p => !p.Discontinued);

Program.cs에서 QueryingWithLike method를 호출하고 product name으로 che를 입력합니다. 다음 결과에서 보듯 'Chef Anton’s Gumbo Mix'는 반영되지 않았습니다. 생성된 SQL문을 확인해 보면 Discontinued column에 대한 filter를 포함하고 있기 때문입니다.

5. EF Core의 loading pattern

EF Core에서 일반적으로 사용되는 3가지 loading pattern이 존재합니다.

Eager loading : 사전 data load
Lazy loading : 필요하기 직전에 자동적으로 data load
Explicit loading : 수동으로 data load

(1) 확장 method 포함을 사용한 eager loading

QueryingCategories method에서 현재 code는 각 category를 순회하기 위해 Categories 속성을 사용하며 category name과 category에 속한 products 수를 출력하고 있습니다.

이것은 이전에 query를 작성할 때 관련된 products에 대한 Include method를 호출함으로써 eager loading를 사용했기 때문입니다.

이때 Include를 사용하지 않으면 어떤 현상이 발생하는지 확인해 보겠습니다.

QueryingCategories method에서 아래와 같이 Include method의 호출 부분을 주석처리합니다.

IQueryable<Category>? categories = db.Categories;//?.Include(c => c.Products);

Program.cs에서 QueryingCategories method를 호출하면 다음과 같은 결과가 표시됩니다.

foreach안에서 각 item은 Products 속성을 갖고 있는 Category class의 instance인데 Products 속성은 category에서의 products list를 의미합니다. 위 예제에서 query는 단지 Categories table만을 select 하고 있으므로 해당 속성은 각 category에서 비어있게 됩니다.

(2) Lazy loading 사용

Lazy loading은 EF Core 2.1에서 도입된 것으로 누락된 관계 data를 자동으로 load 할 수 있습니다. lazy loading을 사용하기 위해서는 우선 proxy를 위한 NuGet package를 참조해야 하며 해당 proxy사용을 위한 lazy loading을 구성해야 합니다.

Visual Studio 2022에서 Microsoft.EntityFrameworkCore.Proxies NuGet package를 찾아 이를 참조합니다. 그리고 Northwind.cs의 OnConfiguring method아래에 UseLazyLoadingProxies 확장 method를 호출하도록 합니다.

optionsBuilder.LogTo(Console.WriteLine, new[] { RelationalEventId.CommandExecuting }).EnableSensitiveDataLogging();
optionsBuilder.UseLazyLoadingProxies();

이렇게 하면 loop를 열거하면서 Products 속성을 읽으려고 시도할 때마다 lazy loading proxy는 data가 load 되었는지를 확인합니다. 그렇지 않다면 SELECT문을 실행하여 현재 category에 대한 products만을 load 하게 됩니다. 다시 말해 속성에 대한 접근이 있으면 그때 data를 database server에서 가져와야 할지를 판단하고 필요하면 그렇게 한다는 것입니다. 이렇게 되면 정확한 count를 출력에 반환할 수 있습니다.

예제를 다시 실행하면 이번에는 정확한 product count가 표시될 것입니다. 다만 모든 data를 가져오기 위해 database server와 여러 번 통신해야 하는 과정이 필요하다는 단점이 있습니다. 예를 들어 모든 categories를 가져온 다음 첫 번째 category인 Beverages에 대한 products를 가져오기 위해 아래와 같이 두 번의 SQL 명령을 실행하고 있습니다.

(3) Load method를 사용해 명시적으로 entity loading 하기

명시적 loading은 lazy loading과 비슷하지만 관계 data가 load 되는 것과 언제 load 될지를 정확히 제어한다는 차이가 있습니다. lazy loading은 해당 속성에 접근하면 처리되지만 explicit loading은 처리시점과 대상을 개발자가 결정합니다.

Queries.cs에서 우선 ChangeTracking namespace를 import 합니다. 해당 namespace는 관계 entity를 수동적으로 load 하도록 하는 CollectionEntry class를 사용하기 위한 것입니다.

using Microsoft.EntityFrameworkCore.ChangeTracking;

QueryingCategories안에서 아래와 같이 lazy loading을 위해 변경한 부분을 주석처리한 다음 사용자에게 eager loading과 explicit loading 중 어느 것을 사용할지를 선택하도록 요청하는 문을 아래와 같이 추가합니다.

IQueryable<Category>? categories;// = db.Categories;//?.Include(c => c.Products);

db.ChangeTracker.LazyLoadingEnabled = false;

Console.Write("Enable eager loading? (Y/N): ");
bool eagerLoading = (Console.ReadKey(intercept: true).Key == ConsoleKey.Y);
bool explicitLoading = false;
Console.WriteLine();

if (eagerLoading)
{
    categories = db.Categories?.Include(c => c.Products);
}
else
{
    categories = db.Categories;
    Console.Write("Enable explicit loading? (Y/N): ");
    explicitLoading = (Console.ReadKey(intercept: true).Key == ConsoleKey.Y);
    Console.WriteLine();
}

foreach loop안에서는 WriteLine method를 호출하기 전 explicit loading을 사용하는지 확인하고 그렇다면 사용자에게 명시적으로 각각의 개별 category를 명시적으로 load 할지를 결정하도록 합니다.

예제를 실행하고 eager loading를 비활성화하기 위해 N을 누릅니다. 그런 다음 explicit loading을 위해 Y를 누르고 각 category에서 products를 load 할지에 대한 선택을 진행합니다.

위 예제에서는 처음 2건에 대한 products만을 load 하도록 하였습니다.

사용하고자 하는 loading pattern을 선택할 때는 주의해야 합니다. loading pattern에 관해서는 아래 link를 참고하시기 바랍니다.

(4) Entity 추적 제어

우선은 entity의 identity resolution을 정의하는 것으로 시작해야 합니다. EF Core는 entity instance에서 각각의 고유한 primary key값을 읽음으로서 resolve를 수행하는데 이런 과정을 통해 entity 혹은 entity 사이의 관계를 식별하는데 모호함을 제거할 수 있게 됩니다.

EF Core는 기본적으로 appliction이 실행되는 memory안에서 entity를 추적합니다. 따라서 새로운 entity를 추가하거나 수정하거나 삭제하는등의 변경사항이 발생하면 꼭 SaveChanges method를 호출하여 해당 변경사항이 실제 database에 반영되도록 해야 합니다.

EF Core는 key가 database에서 entity를 식별할 수 있는 고유값에 해당하므로 이를 통해서만 entity를 추적할 수 있습니다.

Northwind database에서 Customer table을 보면 여기에 다음과 같은 고객 정보가 존재함을 알 수 있습니다.

CustomerId: ALFKI
CompanyName: Alfreds Futterkiste
Country:Germany
Phone: 030-0074321

만약 해당 data context에서 Germany에 해당하는 모든 customer를 불러오는 query를 실행한 뒤 같은 data context안에서 이름이 A로 시작하는 모든 customer를 불러오는 또 다른 query를 실행한다면, 해당 context안에서 특정 customer가 이미 존재한다면 성능향상을 이는 다시 load하지 않습니다.

하지만 이전에 위 설명과 같은 2개의 query를 실행하는 사이 customer의 telephone정보가 update됐다면 data context에서 추적된 entity는 변경된 telephone 정보를 반영하지 않게 되므로 이를 최신의 customer정보로 인정할 수 없게 됩니다.

만약 지역적 변경사항에 대한 추적이 필요하지 않거나 매번 query를 실행할때 마다 최신의 data값을 가진 entity의 instance를 새롭게 load하고자 한다면 추적기능 자체를 비활성화할 수 있습니다.

각각의 query에서 추적을 끄려면 해당 query에서 AsNoTracking method를 호출하거나

var products = db.Products
 .AsNoTracking()
 .Where(p => p.UnitPrice > price)
 .Select(p => new { p.ProductId, p.ProductName, p.UnitPrice });

data context의 instance자체에서 추적을 끄려면 ChangeTracker의 QueryTrackingBehavior설정을 아래와 같이 NoTracking으로 설정해 주면 됩니다.

db.ChangeTracker.QueryTrackingBehavior = QueryTrackingBehavior.NoTracking;

혹은 각각의 query에서 추적을 끄지만 identity resolution을 그대로 유지하고자 한다면 AsNoTrackingWithIdentityResolution method를 대신 호출합니다.

var products = db.Products
 .AsNoTrackingWithIdentityResolution()
 .Where(p => p.UnitPrice > price)
 .Select(p => new { p.ProductId, p.ProductName, p.UnitPrice });

물론 같은 원리로 data context의 instance에도 같은 설정을 적용할 수 있습니다.

db.ChangeTracker.QueryTrackingBehavior = QueryTrackingBehavior.NoTrackingWithIdentityResolution;

모든 새로운 data context에서 일관되게 같은 설정을 적용해야 한다면 OnConfiguring method에서 UseQueryTrackingBehavior method를 호출해 줍니다.

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
    optionsBuilder.UseSqlServer(connectionString).UseQueryTrackingBehavior(QueryTrackingBehavior.NoTracking);
}

● 추적이 발생하는 3가지 사례

첫번째로 identity resolution을 통한 default tracking을 사용하는 경우 입니다. Entity가 일단 data context로 load되면 실제 database에 대한 변경사항은 적용되지 않으며 지역적으로 하나의 복사본이 생성됩니다. Entity는 지역적으로 변경된 사항을 추적하고 SaveChanges method를 호출하여 database를 update합니다.

동작	Entity	Database Table Row
불러오기	A	A
Database 변경	A	B
Entity 변경	C	B
SaveChanges	C	C

두번째는 변경사항에 대한 추적을 하지 않고 identity resolution을 사용하지 않는 경우 입니다. 모든 질의는 다른 table row의 instance를 load하며 변경과 중복을 허용합니다.

동작	Entity	Database Table Row
불러오기	A	A
Database 변경	A	B
불러오기	A B	B
SaveChanges	A B	B

마지막 세번째는 변경사항에 대한 추적을 하지 않으면서 identity resolution을 사용하는 경우입니다. 일단 entity가 data context로 load되고 나면 Database에 대한 변경사항은 적용되지 않으며 오로지 복사본만 존재합니다. 변경사항을 추적하지 않으므로 두번째 경우와 마찬가지로 SaveChanges method는 어떠한 동작도 수행하지 않습니다.

동작	Entity	Database Table Row
불러오기	A	A
Database 변경	A	B
불러오기	A	B
Entity 변경	C	B
SaveChanges	C	B

● 추적없는 query에 대한 Lazy loading

EF Core 7과 그 이전에서는 추적을 사용하지 않도록 설정하면 lazy loading pattern은 사용할 수 없었고 만약 그러한 시도를 하게 되면 System.InvalidOperationException예외가 발생합니다.

그러나 EF Core 8에 들어서 추적을 활성화하지 않더라도 entity에 대한 lazy loading을 지원하기 시작했습니다.

private static void LazyLoadingWithNoTracking()
{
    using NorthwindDb db = new();
 
    IQueryable<Product>? products = db.Products?.AsNoTracking();
    
    if (products is null || !products.Any())
    {
        Console.WriteLine("No Products.");
        return;
    }

    foreach (Product p in products)
    {
        Console.WriteLine("{0} is in category {1}.", p.ProductName, p.Category.CategoryName);
    }
}

위 예제는 Product에 대한 query에서 추적을 사용하지 않도록 하고 있으며 Product를 열거할때 lazy loading을 사용하여 관련된 Category이름을 가져오도록 하고 있습니다. EF Core 7이나 6에서 위 code를 실행하면 예외가 발생합니다.

● AsNoTracking에 대한 오해.

인터넷의 여러 community에서는 간혹 AsNoTracking이 성능향상을 위한 좋은 선택임을 강조하는 경우가 있습니다. 하지만 상상해 보십시오. 수십, 수백개의 entity를 가져오는 query를 AsNoTracking으로 실행한 뒤 다시 같은 data context안에서 동일한 query를 수행하게 되면 memory에는 수백개의 중복된 entity가 저장되는 상황을 맞이하게 될 것입니다.

이는 memory낭비를 초래하며 당연히 성능에도 부정적인 영향을 줄 수 밖에 없을 것입니다. 다시 말해 성능향상을 위해 AsNoTracking을 호출하라는 조언은 모든 상황에서 해당되지 않을 수 있으므로 주의가 필요합니다.

6. EF Core를 사용한 data변경

EF Core를 사용해 entity를 Insert, update, delete 하는 데는 큰 어려움이 없습니다.

DbContext는 변화에 대한 추적관리를 자동으로 하게 되므로 local entity에 새로운 entity를 추가하거나 기존 entity를 수정하거나 혹은 삭제하는 것을 포함해 추적된 여러 변화를 가질 수 있습니다.

그리고 이러한 변경된 사항들을 database에 반영하려면 SaveChanges method를 호출하기만 하면 되고 경우에 따라 성공적으로 변경된 entity의 수가 반환될 것입니다.

(1) Entity Insert

Table에 새로운 row를 추가해 보기 위해 Modifications.cs file을 추가하고 여기에 가장 비싼 순으로 정렬된 각 product에 대한 ID, name, cost, stock, 그리고 discontinued속성을 출력하고 method에 선택적으로 전달된 int값의 array와 일치하는 모든 것을 가종하는 ListProducts이름의 method와 함께 partial Program class를 생성합니다.

partial class Program
{
    static void ListProducts(int[]? productIdsToHighlight = null)
    {
        using (Northwind db = new())
        {
            if ((db.Products is null) || (!db.Products.Any()))
            {
                Console.WriteLine("There are no products.");
                return;
            }

            Console.WriteLine("| {0,-3} | {1,-35} | {2,8} | {3,5} | {4} |", "Id", "Product Name", "Cost", "Stock", "Disc.");

            foreach (Product p in db.Products)
            {
                ConsoleColor previousColor = System.Console.ForegroundColor;

                if ((productIdsToHighlight is not null) && productIdsToHighlight.Contains(p.ProductId))
                {
                    System.Console.ForegroundColor = ConsoleColor.Green;
                }

                Console.WriteLine("| {0:000} | {1,-35} | {2,8:$#,##0.00} | {3,5} | {4} |", p.ProductId, p.ProductName, p.Cost, p.Stock, p.Discontinued);

                System.Console.ForegroundColor = previousColor;
            }
        }
    }
}

위 예제에서 '{숫자1, 숫자2}'는 숫자 1번째의 인수를 숫자 2만큼의 문자열 넓이로 정렬함을 의미합니다. 이때 숫자 2가 -면 왼쪽 정렬을 양수이면 오른쪽 정렬입니다.

이어서 Modifications.cs에 AddProduct method를 아래와 같이 추가합니다.

static (int affected, int productId) AddProduct(int categoryId, string productName, decimal? price)
{
    using (Northwind db = new())
    {
        if (db.Products is null) return (0, 0);

        Product p = new()
        {
            CategoryId = categoryId,
            ProductName = productName,
            Cost = price,
            Stock = 72
        };

        // Insert 추가
        EntityEntry<Product> entity = db.Products.Add(p);
        Console.WriteLine($"State: {entity.State}, ProductId: {p.ProductId}");

        // 변경된 추적사항을 database에 반영
        int affected = db.SaveChanges();
        Console.WriteLine($"State: {entity.State}, ProductId: {p.ProductId}");

        return (affected, p.ProductId);
    }
}

Program.cs에서는 기존의 문을 모두 주석처리하고 위의 AddProduct와 ListProducts를 호출하는 문을 아래와 같이 추가합니다.

var resultAdd = AddProduct(categoryId: 6, productName: "Apple2 Computer", price: 1200M);

if (resultAdd.affected == 1)
{
    Console.WriteLine($"Add product successful with ID: {resultAdd.productId}.");
}
                         
ListProducts(productIdsToHighlight: new[] { resultAdd.productId });

예제를 실행하면 새로운 product를 추가한 다음과 같은 결과를 표시할 것입니다.

새로운 product가 처음 memory에 생성되고 EF Core change tracker에 의해 추적되기 시작하면 Added 상태와 0인 ID를 가지게 됩니다. 그런 후 SaveChanges가 호출되면 상태는 UnChanged로 바뀌게 되고 ID값은 78로 database에 의해 할당됩니다.

(2) Entity Update

기존에 존재하는 table의 row를 변경하기 위해 update 할 product를 product name의 시작을 지정하여 검색한 다음 가장 먼저 일치하는 것만 반환하도록 하는 예제를 작성할 것입니다.(실제로는 ProductId와 같이 고유한 식별자를 사용해 update할 product를 지정하는 것이 일반적입니다.)

Product를 추가할 때는 실제 어떤 product ID가 할당될지 알 수 없습니다. 다만 현재 Northwind database에 'Apple2'로 시작하는 product가 없다는 것만 알고 있을 뿐입니다. name을 사용해 update 할 product를 찾으면 이전에 추가한 product의 ID를 알아내야 하는 것을 피할 수 있습니다. 물론 database에는 77까지의 ID가 존재하므로 새로운 product의 ID가 78이 될 수 있음을 유추할 수 있지만 product를 추가한 뒤 삭제한다고 해도 다음 product의 ID는 79가 될 수 있으며 이때부터 번호순서 예상에 맞지 않을 수 있습니다.

Modifications.cs에서는 name이 지정된 값으로 시작하는 product에 대해 $20과 같이 지정한 만큼 price를 증가시키는 method를 추가합니다.

static (int affected, int productId) IncreaseProductPrice(string productNameStartsWith, decimal amount)
{
    using (Northwind db = new())
    {
        if (db.Products is null) return (0, 0);

        Product updateProduct = db.Products.First(p => p.ProductName.StartsWith(productNameStartsWith));

        updateProduct.Cost += amount;

        int affected = db.SaveChanges();

        return (affected, updateProduct.ProductId);
    }
}

Program.cs에서는 IncreaseProductPrice method를 호출한 다음 다시 ListProducts method를 호출하는 문을 아래와 같이 추가합니다.

var resultUpdate = IncreaseProductPrice(productNameStartsWith: "Apple", amount: 30M);

if (resultUpdate.affected == 1)
{
    Console.WriteLine("Increase price success for ID: {resultUpdate.productId}.");
}

ListProducts(productIdsToHighlight: new[] { resultUpdate.productId });

예제를 실행하면 다음과 같은 결과를 표시할 것입니다. 이전에 추가한 'Apple2 Computer'에 대한 price가 $30만큼 증가되었습니다.

(3) Entity Delete

각각의 entity들은 Remove method를 사용함으로써 삭제할 수 있습니다. RemoveRange는 여러 entity를 제거하고자 할 때 더 적합한 method입니다.

Modifications.cs에서 지정한 값으로 시작하는 모든 product를 삭제하는 method를 아래와 같이 추가합니다.

static int DeleteProducts(string productNameStartsWith)
{
    using (Northwind db = new())
    {
        IQueryable<Product>? products = db.Products?.Where(p => p.ProductName.StartsWith(productNameStartsWith));

        if ((products is null) || (!products.Any()))
        {
            Console.WriteLine("No products found to delete.");

            return 0;
        }
        else
        {
            if (db.Products is null) return 0;
            db.Products.RemoveRange(products);
        }

        int affected = db.SaveChanges();
        return affected;
    }
}

Program.cs에서는 아래와 같이 DeleteProducts method를 호출하는 문을 추가합니다.

Console.WriteLine("About to delete all products whose name starts with Apple.");
Console.Write("Press Enter to continue or any other key to exit: ");

if (Console.ReadKey(intercept: true).Key == ConsoleKey.Enter)
{
    int deleted = DeleteProducts(productNameStartsWith: "Apple");

    Console.WriteLine($"{deleted} product(s) were deleted.");
}
else
{
    Console.WriteLine("Delete was canceled.");
}

예제를 실행하고 Enter key를 누르면 다음과 같은 결과를 표시하게 됩니다.

만약 Apple로 시작하는 product가 여러 건이라면 해당되는 모든 product는 삭제될 것입니다.

(4) 더욱 효율적인 Update와 Delete

지금까지의 방법은 EF Core를 사용한 비교적 전통적인 data수정 방식으로 과정을 다음과 같이 요약할 수 있습니다.

Database context를 생성합니다. (변경추적은 기본으로 사용됩니다.)
Insert를 위해 entity class에 대한 instance를 생성하고 Add method의 매개변수로 collection을 db.Products.Add(product) 처럼 전달합니다.
Update를 위해서는 update 하고자 하는 entity를 가져와 이들에 대한 속성을 변경합니다.
Delete를 위해서는 delete 하고자 하는 entity를 가져와 Remove 또는 RemoveRange method의 매개변수로 db.Products.Remove(product) 처럼 전달합니다.
database context의 SaveChanges method를 호출하면 change tracker는 insert, update, delete수행에 필요한 SQL 문을 생성해 실행하고 적용된 entity의 수를 반환합니다.

EF Core 7에서는 사전에 load 해야 할 entity와 이들에 대한 변경점을 필요로 하지 않음으로써 더 효휼적으로 update와 delete를 수행할 수 있는 ExecuteDelete와 ExecuteUpdate(Async method도 동일함) 2개의 method를 도입하였습니다. 이들은 LINQ query상에서 호출되어 query 결과에 대한 entity에 영향을 주게 됩니다. query가 entity를 검색하는 데 사용되지 않으므로 어떠한 entity도 data context로 load 되지 않습니다.

예를 들어 table의 모든 row를 삭제하고자 한다면 ExecuteDelete 혹은 ExecuteDeleteAsync method를 모든 DbSet속성으로 아래와 같이 호출합니다.

await db.Products.ExecuteDeleteAsync();

위의 code는 database에서 다음과 같은 SQL문을 실행할 것입니다.

DELETE FROM Products

만약 50보다 더 높은 UnitPrice를 가진 product를 삭제하고자 한다면 아래와 같이 LINQ를 작성할 수 있습니다.

await db.Products.Where(product => product.Cost > 50).ExecuteDeleteAsync();

위의 code는 database에서 다음과 같은 SQL문을 실행할 것입니다.

DELETE FROM Products p WHERE p.Cost > 50

ExecuteUpdate와 ExecuteDelete는 단지 단일 table상에서만 동작할 수 있습니다. 만약 다수의 table에 걸친 꽤 복잡한 LINQ query를 작성했다고 하더라도 단일 table에서만 update나 delete가 수행됩니다.

또 다른 예로 Discontinued가 false인 모든 product의 UintPrice값을 10% 인상으로 update 하고자 한다면 LINQ는 아래와 같이 작성될 수 있습니다.

await db.Products.Where(product => !product.Discontinued).ExecuteUpdateAsync(s => s.SetProperty(
p => p.Cost, //update할 속성 선택
p => p.Cost * 0.1m)); //속성 update

위 예제와 같은 경우 하나의 LINQ안에서 다수의 속성을 update 하기 위해 같은 query에서 다수의 SetProperty를 호출해 연

결할 수 있습니다.

Modifications.cs에서 ExecuteUpdate를 사용해 name이 지정한 값으로 시작하는 모든 product를 update 하는 method를 아래와 같이 추가합니다.

static (int affected, int[]? productIds) IncreaseProductPricesBetter(string productNameStartsWith, decimal amount)
{
    using (Northwind db = new())
    {
        if (db.Products is null)
            return (0, null);

        IQueryable<Product>? products = db.Products.Where(p => p.ProductName.StartsWith(productNameStartsWith));

        int affected = products.ExecuteUpdate(s => s.SetProperty(
        p => p.Cost,
        p => p.Cost + amount));

        int[] productIds = products.Select(p => p.ProductId).ToArray();

        return (affected, productIds);
    }
}

Program.cs에서는 IncreaseProductPricesBetter method를 호출하는 문을 아래와 같이 추가합니다.

var resultUpdateBetter = IncreaseProductPricesBetter(productNameStartsWith: "Apple", amount: 20M);

if (resultUpdateBetter.affected > 0)
{
    Console.WriteLine("Increase product price successful.");
}

ListProducts(productIdsToHighlight: resultUpdateBetter.productIds);

다만 위 예제를 실행하기 전 Apple로 시작하는 product를 이전에 삭제하였으므로 위에서 구현했던 새로운 product를 추가하는 문을 먼저 실행하도록 해야 합니다.

예제를 실행하면 현재 'Apple'로 시작하는 product에 대해 다음과 같이 cost를 변경하였음을 확인할 수 있습니다.

다시 Modifications.cs로 돌아와 ExecuteDelete를 사용해 지정한 값으로 시작되는 모든 product를 삭제하는 method를 아래와 같이 추가합니다.

static int DeleteProductsBetter(string productNameStartsWith)
{
    using (Northwind db = new())
    {
        int affected = 0;
        IQueryable<Product>? products = db.Products?.Where(p => p.ProductName.StartsWith(productNameStartsWith));

        if ((products is null) || (!products.Any()))
        {
            Console.WriteLine("No products found to delete.");
            return 0;
        }
        else
        {
            affected = products.ExecuteDelete();
        }

        return affected;
    }
}

Program.cs에서 DeleteProductsBetter method를 호출하도록 하고 예제를 실행하면 다음과 같은 결과를 표시할 것입니다.

Console.WriteLine("About to delete all products whose name starts with Apple.");
Console.Write("Press Enter to continue or any other key to exit: ");

if (Console.ReadKey(intercept: true).Key == ConsoleKey.Enter)
{
    int deleted = DeleteProductsBetter(productNameStartsWith: "Apple");
    Console.WriteLine($"{deleted} product(s) were deleted.");
}
else
{
    Console.WriteLine("Delete was canceled.");
}

만약 기존 방식인 변경 추적과 ExecuteUpdate, ExecuteDelete method를 섞어서 사용하게 되는 경우라면 이들은 서로 동기화되지 않음에 주의해야 합니다. Change tracker는 이들 method를 통해 update 하고 delete 한 사항을 알지 못합니다.

(5) Database context pooling

DbContext class는 일회용이며 단일 작업 단위 원칙에 따라 설계되었습니다. 이전 예제에서는 DbContext에서 파생된 Northwind instance를 using안에서 생성했으므로 Dispose속성은 각 작업에서의 종료시점에 호출됩니다.

EF Core와 관련된 ASP.NET Core의 특징 중 하나는 website와 service를 구축할 때 database context를 pooling 함으로써 code를 더욱 효휼적으로 만든다는 것입니다. 이때 따라 가능한한 더 효휼적으로 원하는 만큼의 DbContext에서 파생된 다수의 개체를 생성하고 소멸할 수 있습니다.

7. Transaction

SaveChanges method를 호출할 때마다 암시적으로 transaction이 시작되므로 무엇인가 잘못된 상황이 발생하면 자동적으로 변경사항이 rollback 됩니다. Transaction이내에서 다수의 변경사항이 성공적으로 수행된다면 transaction은 모든 변경사항을 commit 합니다.

Transaction은 일련의 변경사항들을 처리하는 동안 해당 data에 대한 읽기/쓰기를 방지하지 위해 lock을 적용함으로써 database에 대한 무결성을 관리합니다.

Transaction은 아래 설명에 따른 약자로 ACID라고 말하기도 합니다.

A는 원자성(atomic)입니다. Transaction에 대한 모든 동작이 commit 되거나 commit 되지 않습니다.
C는 일관성(consistent)입니다. Transaction전후에 대한 database의 상태는 일관되며 이는 code의 logic에 의존합니다. 예를 들어 은행 계좌 간 돈이 송금될 때 하나의 계정에서 100만 원이 인출되면 다른 계정에서 100만원이 입금되어야 하는데 이를 보장하는 것은 business loginc에 달려있습니다.
I는 격리성(isolated)입니다. Transaction동안 변경사항은 다른 process로부터는 감춰지는데 여기에 선태가능한 여러 격리 수준이 존재합니다(아래 표 참고). 수준이 높을수록 data의 원자성은 더 나아지지만 더 많은 lock이 적용되고 이는 다른 process에 부정적인 영향을 줄 수 있습니다. Snapshot은 lock을 회피하기 위해 row의 여러 복사본을 생성하므로 좀 더 특별한 경우라고 할 수 있지만 transaction이 발생하는 동안 database의 크기를 증가시킬 수 있습니다.
D는 지속성(durable)입니다. Transaction이 실패하면 원상태로 복구될 수 있습니다. 이는 대게 2단계 commit과 transaction log로 구현됩니다. 일단 transaction이 commit 되면 후속 오류가 발생하더라도 data의 보존을 보증합니다. 지속성의 반대는 휘발성(volatile)입니다.

(1) 격리 수준을 통한 transaction 제어

Transaction은 격리 수준을 설정함으로써 아래 표의 설명과 같이 제어할 수 있습니다.

격리 수준	잠금	허용되는 무결성 문제
ReadUncommitted	해당없음	Dirty read, non-repeatable read와 phantom data
ReadCommitted	data변경시 data에 접근하는 다른 사용자를 transaction이 종료될때까지 차단하기 위해 읽기 잠금을 적용합니다.	Non-repeatable read와 phantom data
RepeatableRead	data를 읽을때 data에 접근하는 다른 사용자를 transaction이 종료될때까지 차단하기 위해 변경 잠금을 적용합니다.	Phantom data
Serializable	Insert나 delete를 포함해 결과에 영향을 줄 수 있는 모든 동작을 차단하기 위해 key-range잠금을 적용합니다.	해당없음
Snapshot	해당없음	해당없음

(2) 명시적인 transaction 정의

Database context에는 Database 속성이 있으며 이를 통해 transaction을 명시적으로 실행시킬 수 있습니다.

Modifications.cs에서 아래와 같이 namespace를 import 합니다. 이는 IDbContextTransaction interface를 사용하기 위한 EF Core storage namespace입니다.

using Microsoft.EntityFrameworkCore.Storage;

그리고 DeleteProducts method에서 db 변수의 instance를 생성한 직후 transaction을 명시적으로 시작하고 격리 수준을 출력하는 문을 추가합니다. Method의 끝에서는 transaction을 commit 하도록 합니다.

static int DeleteProducts(string productNameStartsWith)
{
    using (Northwind db = new())
    {
        using (IDbContextTransaction t = db.Database.BeginTransaction())
        {
            Console.WriteLine("Transaction isolation level: {0}", arg0: t.GetDbTransaction().IsolationLevel);

            IQueryable<Product>? products = db.Products?.Where(p => p.ProductName.StartsWith(productNameStartsWith));

            if ((products is null) || (!products.Any()))
            {
                Console.WriteLine("No products found to delete.");

                return 0;
            }
            else
            {
                if (db.Products is null) return 0;
                db.Products.RemoveRange(products);
            }

            int affected = db.SaveChanges();

            t.Commit();

            return affected;
        }
    }
}

예제를 실행하면 다음과 같은 결과를 표시할 것입니다.

[C# 12와 .NET 8] 9. File, Streams, Serialization

클리엘 — Wed, 28 Feb 2024 15:23:06 +0900

Data에 대한 입출력의 대상은 file이나 stream이 될 수 있으며 때로는 text를 encoding 하거나 직렬화할 수 있습니다.

1. File System 관리

Application에서는 종종 다른 환경에서 file이나 directory등으로 입출력 동작을 수행해야 할 경우가 있으며 System 및 System.IO namespace에서는 이러한 목적의 class들을 포함하고 있습니다.

(1) cross-platform 환경및 filesystem

우선 cross-platform환경을 처리하는 방법과 Windows와 Linux 또는 macOS사이의 차이점에 대해 알아보고자 합니다. Windows와 macOS 그리고 Linux에서 경로는 다르게 취급되고 있으므로 .NET이 이를 어떻게 처리하는지를 알아둘 필요가 있습니다.

csStudy08 Solution에서 WorkingWithFileSystems이름의 Console App project를 생성합니다. 그리고 project에 Helpers.cs 이름의 class file을 추가한뒤 아래와 같이 SectionTitle method를 가진 partial Program class를 정의합니다.

static void SectionTitle(string title)
{
	ConsoleColor previousColor = System.Console.ForegroundColor;
	System.Console.ForegroundColor = ConsoleColor.Yellow;
	Console.WriteLine("*");
	Console.WriteLine($"* {title}");
	Console.WriteLine("*");
	System.Console.ForegroundColor = previousColor;
}

Program.cs에서는 기존의 문을 모두 삭제하고 System.IO.Directory, System.Environment, System.IO.Path namespace를 정적 import한뒤

using static System.IO.Directory; 
using static System.IO.Path; 
using static System.Environment;

여기에 경로 및 directory분리문자를 출력하고, 현재 directory에 대한 경로와 system file, 임시 file, document 등 일부 특별한 용도의 directory에 대한 경로를 출력하는 문을 아래와 같이 작성합니다.

Console.WriteLine("{0,-33} {1}", arg0: "Path.PathSeparator", arg1: PathSeparator);
Console.WriteLine("{0,-33} {1}", arg0: "Path.DirectorySeparatorChar", arg1: DirectorySeparatorChar);
Console.WriteLine("{0,-33} {1}", arg0: "Directory.GetCurrentDirectory()", arg1: GetCurrentDirectory());
Console.WriteLine("{0,-33} {1}", arg0: "Environment.CurrentDirectory", arg1: CurrentDirectory);
Console.WriteLine("{0,-33} {1}", arg0: "Environment.SystemDirectory", arg1: SystemDirectory);
Console.WriteLine("{0,-33} {1}", arg0: "Path.GetTempPath()", arg1: GetTempPath());

Console.WriteLine("GetFolderPath(SpecialFolder)");
Console.WriteLine("{0,-33} {1}", arg0: " .System)", arg1: GetFolderPath(SpecialFolder.System));
Console.WriteLine("{0,-33} {1}", arg0: " .ApplicationData)", arg1: GetFolderPath(SpecialFolder.ApplicationData));
Console.WriteLine("{0,-33} {1}", arg0: " .MyDocuments)", arg1: GetFolderPath(SpecialFolder.MyDocuments));
Console.WriteLine("{0,-33} {1}", arg0: " .Personal)", arg1: GetFolderPath(SpecialFolder.Personal));

Environment type에서는 위의 예제에서 사용된 것 이외 GetEnvironmentVariables method와 OSVersion, ProcessorCount속성등 여러 가지 유용한 member들을 가지고 있습니다.

예제를 실행하면 다음과 같은 결과를 표시할 것입니다.

Visual Studio Code에서 dotnet run을 사용해 console app을 실행하는 경우 CurrentDirectory는 bin folder 내부가 아닌 project folder가 될 것입니다.

Windows에서는 directory에 대한 구분문자로 backslash(\)문자를 사용하지만 macOS와 Linux는 slash문자를 사용합니다. 경로를 결합할 때 code에서 어떤 문자가 사용되는지를 미리 가정하지 말고 Path.DirectorySeparatorChar를 사용하는 것이 좋습니다.

(2) Drive

Drive에 관한 것으로는 computer에 연결된 모든 drive에 관한 정보를 반환하는 정적 method를 가진 DriveInfo type을 사용합니다. 이때 각각의 drive는 drive type을 가집니다.

Program.cs에서 모든 drive를 가져와 사용가능한 것들에 대해서만 drive의 이름, type, size, 사용 가능한 용량 그리고 format을 출력하는 문을 작성합니다.

SectionTitle("My drives");
Console.WriteLine("{0,-30} | {1,-10} | {2,-7} | {3,18} | {4,18}", "NAME", "TYPE", "FORMAT", "SIZE (BYTES)", "FREE SPACE");
foreach (DriveInfo drive in DriveInfo.GetDrives())
{
	if (drive.IsReady)
	{
		Console.WriteLine("{0,-30} | {1,-10} | {2,-7} | {3,18:N0} | {4,18:N0}", drive.Name, drive.DriveType, drive.DriveFormat, drive.TotalSize, drive.AvailableFreeSpace);
	}
	else
	{
		Console.WriteLine("{0,-30} | {1,-10}", drive.Name, drive.DriveType);
	}
}

TotalSize와 같은 속성을 읽기 전에 drive가 준비상태인지를 확인해야 합니다. 그렇지 않으면 이동식 drive에 관한 예외를 보게 될 것입니다.

예제를 실행하면 다음과 같은 결과를 확인할 수 있습니다.

Linux에서 일반 사용자 권한으로 예제를 실행하는 경우 Name과 DriveType만 접근이 가능하고 DriveFormat과 TotalSize에서는 UnauthorizedAccessException예외를 일으킬 수 있습니다.이 문제를 해결하기 위해서는 ' sudo dotnet run.'명령을 통해서 관리자 권한으로 예제를 실행해야 합니다.

(3) Directory

Directory와 관련해서는 Directory, Path 그리고 Environment 적정 class를 사용합니다. 이들 type에는 filesystem에 관한 다수의 member들을 가지고 있습니다.

사용자지정 경로를 구성할 때는 예를 들어 directory분리문자를 사용할 때 platform에 대한 가정을 하지 않도록 code작성에 주의해야 합니다.

Program.cs에서 directory 이름에 대한 문자열을 생성하고 Path type의 Combine method를 통해 적절히 이들을 결합하여 사용자의 home directory 아래에 사용자지정 경로를 정의하도록 하는 문을 아래와 같이 작성합니다. 이때 사용자지정 directory에 대한 경로는 Directory class의 Exists method를 통해 존재여부를 확인하고 directory를 생성한 뒤 Directory class의 CreateDirectory method와 Delete method를 사용해 이곳에 포함된 모든 file과 하위 directory를 포함해 삭제하도록 합니다.

SectionTitle("Custom Directory");
			
string newFolder = Combine(GetFolderPath(SpecialFolder.Personal), "NewFolder");

Console.WriteLine($"Working with: {newFolder}");
Console.WriteLine($"Does it exist? {Path.Exists(newFolder)}");
Console.WriteLine("Creating it...");
			
CreateDirectory(newFolder);

Console.WriteLine($"Does it exist? {Path.Exists(newFolder)}");
Console.Write("Confirm the directory exists, and then press ENTER: "); Console.ReadLine();
Console.WriteLine("Deleting it...");
			
Delete(newFolder, recursive: true);

Console.WriteLine($"Does it exist? {Path.Exists(newFolder)}");

예제를 실행한 뒤 결과를 확인합니다. directory를 삭제하기 위해 Enter key를 누르기 전 해당 directory가 정상적으로 만들어졌는지 확인합니다.

.NET 6 이전까지는 Directory class에서만 Exists method가 있었으나 .NET 7 이후부터는 Path에도 Exists method가 존재하며 둘의 역활은 동일합니다.

(4) File

File과 관련해서는 Directory에서 했던 것처럼 file type을 정적으로 가져올 수 있습니다. 다만 아래 예제에서는 directory type에서와 이름이 같은 method를 일부 가지고 있으며 따라서 서로 충돌할 수 있기 때문에 그런 방식을 사용하지 않았습니다. 또한 이 경우 큰 문제가 되지 않을 만큼 짧은 이름을 사용할 수 있습니다.

Program.cs에서 파일존재를 확인한 뒤 text file을 생성하고 해당 file에 text를 기록하는 문을 작성합니다.

SectionTitle("files");

string dir = Combine(GetFolderPath(SpecialFolder.Personal), "OutputFiles");
CreateDirectory(dir);

string textFile = Combine(dir, "Dummy.txt");
string backupFile = Combine(dir, "Dummy.bak");

Console.WriteLine($"Working with: {textFile}");
Console.WriteLine($"Does it exist? {File.Exists(textFile)}");

StreamWriter textWriter = File.CreateText(textFile);
textWriter.WriteLine("Hello, C#!");
textWriter.Close();

Console.WriteLine($"Does it exist? {File.Exists(textFile)}");

File.Copy(sourceFileName: textFile, destFileName: backupFile, overwrite: true);
Console.WriteLine($"Does {backupFile} exist? {File.Exists(backupFile)}");

Console.Write("Confirm the files exist, and then press ENTER: ");
Console.ReadLine();
			
File.Delete(textFile);
Console.WriteLine($"Does it exist? {File.Exists(textFile)}");
			
Console.WriteLine($"Reading contents of {backupFile}:");
StreamReader textReader = File.OpenText(backupFile);
Console.WriteLine(textReader.ReadToEnd());
textReader.Close();

예제에서는 file을 기록하고 나면 system resource와 잠금을 해제하기 위해 file을 닫아줍니다.(이것은 일반적으로 file작성 시 예외가 발생하더라도 file이 닫히는 경우를 확실히 하기 위해 try-finally문에서 이루어집니다.) 그리고 backup을 위해 file을 복사한 뒤 기존의 file은 삭제하고 backup file로부터 내용을 읽어 표시합니다.

예제를 실행하면 다음과 같은 결과를 확인할 수 있습니다.

(5) Path

때로는 경로의 일부만을 확인해야 하는 경우도 있을 것입니다. 예를 들어 경로에서 folder이름이나 file이름, 혹은 확장자와 같은 것만을 추출해야 하는 경우입니다. 또는 임시 folder나 file이름을 생성해야 하는 경우도 있습니다. 이와 같은 작업은 Path class의 정적 method를 사용하면 가능합니다.

Program.cs에서 아래와 같은 구문을 추가합니다.

SectionTitle("Paths");
string dir = Combine(GetFolderPath(SpecialFolder.Personal), "OutputFiles");
string textFile = Combine(dir, "Dummy.txt");

Console.WriteLine($"Folder Name: {GetDirectoryName(textFile)}");
Console.WriteLine($"File Name: {GetFileName(textFile)}");
Console.WriteLine("File Name without Extension: {0}",

GetFileNameWithoutExtension(textFile));

Console.WriteLine($"File Extension: {GetExtension(textFile)}");
Console.WriteLine($"Random File Name: {GetRandomFileName()}");
Console.WriteLine($"Temporary File Name: {GetTempFileName()}");

예제를 실행하면 다음과 같은 결과를 확인할 수 있습니다.

GetTempFileName은 zero-byte file을 생성하여 사용할 수 있도록 준비한 뒤 해당 file의 이름을 반환합니다. 하지만 GetRandomFileName은 file의 이름만 반환할 뿐 실제 생성하지는 않습니다.

(6) File 정보 확인

File이나 directory에 관한 정보, 예를 들어 size나 마지막 접근일자와 같은 정보를 를 확인하려면 FileInfo 혹은 DirectoryInfo class의 instance를 생성해 사용할 수 있습니다.

FileInfo와 DirectoryInfo는 모두 FileSystemInfo class로부터 상속받은 것으로 따라서 둘 다 자신만의 속성과 더불어 LastAccessTime나 Delete와 같은 공통된 member를 가지고 있습니다.

Class	Members
FileSystemInfo	Field : FullPath, OriginalPath Property : Attributes, CreationTime, CreationTimeUtc, Exists, Extension, FullName, LastAccessTime, LastAccessTimeUtc, LastWriteTime, LastWriteTimeUtc, Name Methods: Delete, GetObjectData, Refresh
DirectoryInfo	Property : Parent, Root Method : Create, CreateSubdirectory, EnumerateDirectories, EnumerateFiles, EnumerateFileSystemInfos, GetAccessControl, GetDirectories, GetFiles, GetFileSystemInfos, MoveTo, SetAccessControl
FileInfo	Property : Directory, DirectoryName, IsReadOnly, Length Methods: AppendText, CopyTo, Create, CreateText, Decrypt, Encrypt, GetAccessControl, MoveTo, Open, OpenRead, OpenText, OpenWrite, Replace, SetAccessControl

아래 예제는 하나의 File에 대해 FileInfo instance를 통해 여러 동작을 어떻게 효휼적으로 수행할 수 있는지를 알려주기 위한 것으로 Program.cs에서 backup file에 대한 FileInfo instance를 생성하고 console에 이에 대한 정보를 출력하도록 합니다.

SectionTitle("File information");

string dir = Combine(GetFolderPath(SpecialFolder.Personal), "OutputFiles");
string backupFile = Combine(dir, "Dummy.bak");

FileInfo info = new(backupFile);
Console.WriteLine($"{backupFile}:");
Console.WriteLine($"Contains {info.Length} bytes");
Console.WriteLine($"Last accessed {info.LastAccessTime}");
Console.WriteLine($"Has readonly set to {info.IsReadOnly}");

예제를 실행하면 다음과 같은 결과를 표시하게 됩니다.

byte에 대한 숫자는 OS마다 다른 line ending을 사용할 수 있으므로 다르게 표시될 수 있습니다.

(7) File에 대한 처리방식 제어

File에 대한 어떤 처리를 진행하고자 할 때 경우에 따라 어떤 형태로 file을 open 해야 할지 지정하는 경우가 있으며 이런 경우 File.Open method를 사용할 수 있습니다. Open method는 enum값을 통해 추가적인 option을 지정할 수 있는 overload를 가지고 있습니다.

사용가능한 enum값으로는 다음과 같은 것이 있습니다.

FileMode : CreateNew, OpenOrCreate, Truncate 등 해당 file에 무엇을 할지 지정합니다.
FileAccess : ReadWrite와 같이 필요한 접근 수준을 지정합니다.
FileShare : 다른 process에서 Read와 같이 접근가능한 수준을 지정함으로써 file에 대한 잠금을 조정합니다.

따라서 만약 file을 열고 해당 file로부터 읽기를 수행하면서 다른 process에서도 역시 읽기를 허용하려면 다음과 같이 지정합니다.

FileStream file = File.Open(textFile, FileMode.Open, FileAccess.Read, FileShare.Read);

또한 file에 대한 속성을 위해 사용가능한 아래와 enum값도 존재합니다.

FileAttributes : FileSystemInfo에서 파생된 type의 attrubute 속성에서 Archive와 Encrypted와 같은 값을 확인합니다.

이를 통해 file이나 directory의 속성은 아래와 같이 확인할 수 있습니다.

FileInfo info = new(backupFile);
WriteLine("Is the backup file compressed? {0}", info.Attributes.HasFlag(FileAttributes.Compressed));

2. Stream 읽기/쓰기

Stream은 읽고 쓸 수 있는 일련의 byte입니다. File을 array처럼 처리할 수 있지만 file내 byte의 위치를 알면 random access가 제공되므로 순차적으로 접근할 수 있는 stream으로서 file을 처리하는 것이 유용할 수 있습니다.

Stream은 또한 terminal 입출력 및 random access를 제공하지 않으며 위치를 탐색(즉, 이동)할 수 없는 socket과 port 같은 networking resource를 처리하는 데에도 사용할 수 있습니다. 이에 따라 data stream이 어디서 온 것인지 신경 쓸 필요 없이 임의의 byte를 처리할 수 있는 code를 작성할 수 있으며 이때 code는 단순히 stream을 읽고 쓰기만 하면 다른 한편에서는 실제 byte가 저장된 곳을 처리할 수 있게 됩니다.

(1) Stream의 추상화 및 구체화

Stream이라는 추상화 class는 stream에 대한 모든 type을 표현합니다. 추상화 class자체는 new를 사용해 instance를 생성할 수 없으며 상속만이 가능합니다.

때문에 해당 기반 class로부터 상속된 다수의 구체화 class가 존재하는데 여기에는 FileStream, MemoryStream, BufferedStream, GZipStream 그리고 SslStream과 같은 것이 존재하며 이들은 모두 같은 방식으로 작동합니다. 모든 stream은 IDisposable interface를 구현하고 있으므로 비관리 resource를 해제하기 위한 Dispose method를 가집니다.

Stream class에서 가지고 있는 일부 공통 member에 관해서는 아래 표에서 확인할 수 있습니다.

Member	Description
CanRead, CanWrite	해당 속성은 stream을 읽거나 쓸수 있는지의 여부를 나타냅니다.
Length, Position	해당 속성은 총 byte길이와 stream에서의 현재 위치를 나타냅니다.
Dispose	해당 method는 stream을 닫고 resource를 해제합니다.
Flush	Stream이 bufer를 가지고 있다면 해당 method는 buffer의 byte를 stream에 기록하고 buffer를 비웁니다.
CanSeek	해당 속성은 Seek method가 사용가능한지를 나타냅니다.
Seek	해당 method는 현재 위치를 매개변수로 지정된 곳으로 이동합니다.
Read, ReadAsync	해당 method는 stream으로 부터 지정한 수의 byte를 byte배열로 읽고 위치를 앞당깁니다.
ReadByte	해당 method는 stream으로 부터 다음 byte를 읽고 위치를 앞당깁니다.
Write, WriteAsync	해당 method는 byte array의 내용을 stream으로 작성합니다.
WriteByte	해당 method는 byte를 stream으로 작성합니다.

● Storage stream

아래 표에서는 byte가 저장될 위치를 나타내는 일부 storage stream을 설명하고 있습니다.

Namespace	Class	Description
System.IO	FileStream	filesystem에 저장된 byte
System.IO	MemoryStream	현재 process의 memory에 저장된 byte
System.Net.Sockets	NetworkStream	network 위치에 저장된 byte

File Stream은 Windows상에서 성능과 안정성이 더육 향상되도록 .NET 6에서 재작성되었습니다.

File IO improvements in .NET 6 - .NET Blog (microsoft.com)

● Function stream

아래 표는 자체적으로는 존재하지 않지만 다른 stream에 연결되어 기능을 추가시키는 function stream을 설명하고 있습니다.

Namespace	Class	Description
System.Security.Cryptography	CryptoStream	Stream을 암호화/복호화 합니다.
System.IO.Compression	GZipStream, DeflateStream	Stream을 압축하고 해제합니다.
System.Net.Security	AuthenticatedStream	Stream전역에 자격증명을 보냅니다.

● Stream helper

비록 저수준에서 stream을 사용해야 하는 경우가 있겠지만 대부분은 helper class를 사용하는 것만으로 손쉽게 구현할 수 있습니다. Stream에 대한 모든 helper type은 IDisposable을 구현하고 있으므로 비관리 resource를 해제하기 위한 Dispose method를 가집니다.

일반적인 상황에서 사용가능한 몇몇 helper class는 아래 표에 안내되어 있습니다.

Namespace	Class	Description
System.IO	StreamReader	기본 stream으로 부터 일반 text를 읽습니다.
System.IO	StreamWriter	기본 stream으로 일반 text를 작성합니다.
System.IO	BinaryReader	Stream으로 부터 .NET type을 읽습니다. 예를 들어 ReadDecimal method는 기본 stream에서 decimal 값을 다음 16 byte를 읽고 ReadInt32 method는 int값으로 다음 4 byte를 읽습니다.
System.IO	BinaryWriter	Stream으로 .NET type을 작성합니다. 예를 들어 decimal 매개변수를 가진 Write method는 기본 stream으로 16byte를 작성하며 int 매개변수를 가진 Write method는 4 byte를 작성합니다.
System.Xml	XmlReader	기본 stream으로 부터 XML format을 사용해 읽습니다.
System.Xml	XmlWrite	기본 stream으로 XML format을 사용해 작성합니다.

(2) Stream pipeline 구축

StreamWriter와 같은 helpler와 CryptoStream이나 GZipStream과 같은 여러 기능 Stream을 stream을 저장하는 FileStream과 pipeline으로 결합하는 것은 흔한 경우입니다.

WriteLine method를 통해 hello라는 문자열을 pipeline을 통해서 보내면 이것은 암호화와 압축 stream을 거쳐게 되고 최종목적지에 도달하게 되면 'G7x'라고 쓰여진 file의 결과물을 얻게 됩니다.

(3) Text stream

Stream으로 text를 작성하는 예제를 만들기 위해 csStudy09 solution을 생성하고 이어서 WorkingWithStreams이름의 Console app project를 추가합니다.

Project가 생성되면 Viper.cs라는 이름의 class file을 추가하고 Callsigns이름의 문자열배열값을 가진 Viper이름의 정적 class를 아래와 같이 작성합니다.

Program.cs에서는 기존의 문을 모두 삭제하고 System.Xml namespace와 System.Environment, System.IO.path namespace를 정적 import 합니다. 그리고 Viper call signs를 열거하면서 각각 한 줄씩 text file에 기록하도록 하는 문을 아래와 같이 작성합니다.

string textFile = Combine(CurrentDirectory, "streams.txt");
            
// text file을 생성한 뒤 helper writer를 반환
StreamWriter text = File.CreateText(textFile);
            

foreach (string item in Viper.Callsigns)
{
    text.WriteLine(item);
}

text.Close(); // release resources

// file의 크기와 내용 출력
Console.WriteLine("{0} contains {1:N0} bytes.", arg0: GetFileName(textFile), arg1: new FileInfo(textFile).Length);
Console.WriteLine(File.ReadAllText(textFile));

예제를 실행하면 다음과 같은 결과를 표시할 것입니다.

(4) XML stream

XML 요소를 작성하는 데는 2가지 방식이 존재합니다.

WriteStartElement와 WriteEndElement : 요소가 자식요소를 가지는 경우 같이 사용합니다.
WriteElementString : 요소가 자식요소를 가지지 않는 경우 사용합니다.

읽거나 쓰기 위해 file을 열면 .NET의 외부 resource를 사용하는 것으로 이를 비관리 resouce라고 하며 대상 file에 대한 작업이 종료되면 instance는 반드시 소멸되어야 하며 대게는 resource를 소멸할 때 try ~ finally block안에서 Dispose method를 호출합니다.

아래 예제는 Viper pilot 호출 sign에 대한 문자열 배열값을 XML file로 저장하도록 하는 것으로 Program.cs에서 호출 sign을 열거하고 각각을 단일 XML file의 요소로 작성하도록 합니다.

//작성을 위한 file경로 정의
string xmlFile = Combine(CurrentDirectory, "streams.xml");

// filestream과 XML writer에 대한 변수 선언
FileStream? xmlFileStream = null;
XmlWriter? xml = null;

try
{
    // file stream 생성
    xmlFileStream = File.Create(xmlFile);
    // file stream을 XML writer helper로 wrapping하고 자동적으로 중첩된 요소간 들여쓰기를 적용합니다.
    xml = XmlWriter.Create(xmlFileStream, new XmlWriterSettings { Indent = true });

    xml.WriteStartDocument();
    // root 요소 작성
    xml.WriteStartElement("callsigns");

    //string을 열거하고 각각을 stream에 작성합니다.
    foreach (string item in Viper.Callsigns)
    {
        xml.WriteElementString("callsign", item);
    }

    // 종료 root 요소 작성
    xml.WriteEndElement();
    // helper와 stream닫기
    xml.Close();
    xmlFileStream.Close();
}
catch (Exception ex) {
    //해당 경로가 존재하지 않으면 예외발생
    Console.WriteLine($"{ex.GetType()} says {ex.Message}");
}
finally {
    if (xml != null)
    {
        xml.Dispose();
        Console.WriteLine("비관리 resource 해제");
    }

    if (xmlFileStream != null)
    {
        xmlFileStream.Dispose();
        Console.WriteLine("File stream의 비관리 resource 해제");
    }
}

//File 내용 출력
Console.WriteLine("{0} contains {1:N0} bytes.", arg0: Path.GetFileName(xmlFile), arg1: new FileInfo(xmlFile).Length);
Console.WriteLine(File.ReadAllText(xmlFile));

예제를 실행하면 아래와 같은 결과를 표시합니다.

Dispose method를 호출하기 전 개체가 null인지를 확인해야 합니다.

(5) using문을 사용해 소멸을 단순화하기

위 예제에서는 null 개체에 대한 확인 code를 좀 더 단순화한 다음 using 문을 통해 Dispose method를 호출하도록 바꿀 수 있습니다. 일반적으로는 더 높은 수준에서의 제어가 필요하지 않은 이상에는 수동적으로 Dispose method를 호출하기보다는 using문의 사용을 권장합니다.

using keyword자체가 namespace를 import 하고 IDisposable를 구현하는 개체에 Dispose를 호출할 finally문을 생성하는 2가지로 사용된다는 측면에서 약간 혼란스러울 수 있지만 실제 사용해 보면 이 둘은 아주 명확히 구분된다는 것을 알 수 있을 것입니다.

아래 예제에서 compiler는 using 문 block을 catch문이 없는 try-finally문으로 변경합니다. 물론 여기에서도 try문을 충첩적으로 사용할 수 있으므로 어떤 예외사항을 잡아내야 한다면 아래와 같이 구현할 수 있습니다.

using (FileStream file = File.OpenWrite(Path.Combine(CurrentDirectory, "test.txt")))
{
    using (StreamWriter writer = new StreamWriter(file))
    {
        try
        {
            writer.WriteLine(".NET!");
        }
        catch (Exception ex)
        {
            Console.WriteLine($"{ex.GetType()} says {ex.Message}");
        }
    } // 개체가 null이 아니면 자동적으로 Dispose를 호출
} // 개체가 null이 아니면 자동적으로 Dispose를 호출

게다가 위 예제는 using문을 위한 괄호와 들여 쓰기를 명시하지 않음으로써 아래와 같이 더욱 간소화할 수 있습니다.

using FileStream file = File.OpenWrite(Path.Combine(CurrentDirectory, "test.txt"));
using StreamWriter writer = new(file);

try
{
    writer.WriteLine(".NET!");
}
catch (Exception ex)
{
    Console.WriteLine($"{ex.GetType()} says {ex.Message}");
}

(6) Stream 압축

XML은 상대적으로 장황한 편이라 일반적인 text보다 더 많은 byte공간을 차지하게 됩니다. 이제 GZIP이라는 일반적인 압축 algorithm을 사용하여 XML을 얼마나 압축할 수 있는지를 확인해 볼 것입니다.

.NET Core 2.1에서 Microsoft는 Brotli이라는 압축 algorithm의 구현을 도입하였습니다. 성능면에서 Brotli는 DEFLATE와 GZIP에서 사용된 algorithm과 비슷하지만 20% 정도 더 압축력이 높다고 평가되고 있습니다.

예제를 통해 GZIP과 Brotli 2개의 압축 algorithm을 비교해 보고자 Project에 Compress.cs라는 class file을 추가합니다. Compress.cs에서는 GZipStream과 BrotliStream에 대한 instance를 사용하여 위와 동일한 XML 요소를 포함하는 압축 file을 생성한 다음 읽는 동안 압축을 풀고 console에 해당 내용을 출력하는 문을 아래와 같이 작성합니다.

using System.IO.Compression; // BrotliStream, GZipStream, CompressionMode
using System.Xml; // XmlWriter, XmlReader
using static System.Environment; // CurrentDirectory
using static System.IO.Path; // Combine

namespace WorkingWithStreams
{
    partial class Program
    {
        static void Compress(string algorithm = "gzip")
        {
            //file의 확장자를 통해 algorithm을 사용하는 file 경로 정의
            string filePath = Combine(CurrentDirectory, $"streams.{algorithm}");

            FileStream file = File.Create(filePath);
            Stream compressor;

            if (algorithm == "gzip")
            {
                compressor = new GZipStream(file, CompressionMode.Compress);
            }
            else
            {
                compressor = new BrotliStream(file, CompressionMode.Compress);
            }

            using (compressor)
            {
                using (XmlWriter xml = XmlWriter.Create(compressor))
                {
                    xml.WriteStartDocument();
                    xml.WriteStartElement("callsigns");
                    foreach (string item in Viper.Callsigns)
                    {
                        xml.WriteElementString("callsign", item);
                    }
                }
            }

            Console.WriteLine("{0} contains {1:N0} bytes.", Path.GetFileName(filePath), new FileInfo(filePath).Length);
            Console.WriteLine($"The compressed contents:");
            Console.WriteLine(File.ReadAllText(filePath));
            
            Console.WriteLine("Reading the compressed XML file:");
            file = File.Open(filePath, FileMode.Open);
            Stream decompressor;

            if (algorithm == "gzip")
            {
                decompressor = new GZipStream(file, CompressionMode.Decompress);
            }
            else
            {
                decompressor = new BrotliStream(file, CompressionMode.Decompress);
            }

            using (decompressor)
            {

                using (XmlReader reader = XmlReader.Create(decompressor))
                {

                    while (reader.Read())
                    {
                        //callsign 요소가 있는지 확인
                        if ((reader.NodeType == XmlNodeType.Element) && (reader.Name == "callsign"))
                        {
                            reader.Read(); //요소 내부 text로 이동
                            Console.WriteLine($"{reader.Value}"); //해당 값 읽기
                        }
                    }
                }
            }
        }
    }
}

Program.cs에서는 gzip과 brotli algorithm을 사용하기 위한 매개변수와 함께 Compress method를 호출하는 문을 아래와 같이 작성합니다.

Compress(algorithm: "gzip");
Compress(algorithm: "brotli");

예제를 실행하면 다음과 같이 XML file과 gzip 및 brotli algorithm을 통해 압축된 XML file의 size를 비교하는 결과를 표시하게 됩니다.

당연한 이야기지만 압축된 file은 압축되지 않은 동일한 file size의 size보다 훨씬 적음을 알 수 있습니다.

압축 mode와 더불어 압축 level역시 선택할 수 있습니다. 자세한 사항은 아래 link를 참고해 주시기 바랍니다.

CompressionLevel Enum (System.IO.Compression) | Microsoft Learn

CompressionLevel Enum (System.IO.Compression)

Specifies values that indicate whether a compression operation emphasizes speed or compression size.

learn.microsoft.com

(7) tar 압축

확장자가 .tar인 file은 Unix기반의 압축 application인 tar에 의해 생성된 것입니다. 확장자가 .tag.gz인 file도 존재하는데 이는 tar로 file이 만들어지고 GZIP 압축 algorithm을 사용해 압축되어 생성된 것임을 의미합니다.

.NET 7에서는 System.Formats.Tar assembly를 통해 tar 압축 file을 읽고, 생성하며 압축하거나 풀 수 있습니다.

이와 관련해 TarFile class에서는 아래 표에서의 static public member를 사용할 수 있습니다.

Member	Description
CreateFromDirectory CreateFromDirectoryAsync	지정된 directory로 부터 지정된 모든 filesystem 항목을 포함하는 stream을 생성합니다.
ExtractToDirectory ExtractToDirectoryAsync	지정한 directory에서 tar 압축을 나타내는 stream의 content를 추출합니다.
DefaultCapacity	Windows의 MAX_PATH (260)이 임의 기본 용량으로 사용됩니다.

관련한 예제 작성을 위해 csStudy09 solution에서 WorkingWithTarArchives이름의 Console app project를 생성합니다. 그리고 Helpers.cs라는 class file을 추가하여 error, 경고, 정보 message를 console에 적절한 색상으로 출력하는 3개의 method를 가진 partial Program class를 아래와 같이 작성합니다.

using static System.Console;

namespace WorkingWithTarArchives
{
    partial class Program
    {
        static void WriteError(string message)
        {
            ConsoleColor previousColor = ForegroundColor;
            ForegroundColor = ConsoleColor.Red;
            WriteLine($"FAIL: {message}");
            ForegroundColor = previousColor;
        }

        static void WriteWarning(string message)
        {
            ConsoleColor previousColor = ForegroundColor;
            ForegroundColor = ConsoleColor.DarkYellow;
            WriteLine($"WARN: {message}");
            ForegroundColor = previousColor;
        }
        static void WriteInformation(string message)
        {
            ConsoleColor previousColor = ForegroundColor;
            ForegroundColor = ConsoleColor.Blue;
            WriteLine($"INFO: {message}");
            ForegroundColor = previousColor;
        }
    }
}

이어서 project의 실행 file이 동작하는 bin folder에 images라는 folder를 생성하고 아래 image들을 내려받은 뒤 해당 folder로 복사해 놓습니다.

images.zip

2.48MB

Program.cs에서는 기존의 문을 모두 삭제하고 지정한 folder의 content를 tar로 압축한 다음 이것을 다시 새로운 folder로 추출하는 구문을 아래와 같이 작성합니다.

try
{
    string current = Environment.CurrentDirectory;
    WriteInformation($"Current directory: {current.Split(Path.DirectorySeparatorChar).Last()}");

    string sourceDirectory = Path.Combine(current, "images");
    string destinationDirectory = Path.Combine(current, "extracted");
    string tarFile = Path.Combine(current, "images-archive.tar");

    if (!Directory.Exists(sourceDirectory))
    {
        WriteError($"The {sourceDirectory.Split(Path.DirectorySeparatorChar).Last()} directory must exist. Please create it and add some files to it.");
        return;
    }

    //tar file이 존재한다면 삭제
    if (File.Exists(tarFile))
    {
        File.Delete(tarFile);
        WriteWarning($"{Path.GetFileName(tarFile)} already existed so it was deleted.");
    }

    WriteInformation($"Archiving directory: {sourceDirectory.Split(Path.DirectorySeparatorChar).Last()}\n To .tar file: {Path.GetFileName(tarFile)}");

    TarFile.CreateFromDirectory(sourceDirectoryName: sourceDirectory, destinationFileName: tarFile, includeBaseDirectory: true);

    WriteInformation($"Does {Path.GetFileName(tarFile)} exist? {File.Exists(tarFile)}.");

    //destinationDirectory folder가 존재하지 않으면 새로 생성
    if (!Directory.Exists(destinationDirectory))
    {
        Directory.CreateDirectory(destinationDirectory);
        WriteWarning($"{destinationDirectory.Split(Path.DirectorySeparatorChar).Last()} did not exist so it was created.");
    }

    WriteInformation($"Extracting archive: {Path.GetFileName(tarFile)}\n To directory: {destinationDirectory.Split(Path.DirectorySeparatorChar).Last()}");

    TarFile.ExtractToDirectory(sourceFileName: tarFile, destinationDirectoryName: destinationDirectory, overwriteFiles: true);

    if (Directory.Exists(destinationDirectory))
    {
        foreach (string dir in Directory.GetDirectories(destinationDirectory))
        {
            WriteInformation($"Extracted directory {dir.Split(Path.DirectorySeparatorChar).Last()} containing these files: " + string.Join(',', Directory.EnumerateFiles(dir).Select(file => Path.GetFileName(file))));
        }
    }
}
catch (Exception ex)
{
    WriteError(ex.Message);
}

예제를 실행하면 다음과 같은 결과를 확인할 수 있습니다

만약 반디집과 같이 tar archive의 content를 볼 수 있는 software가 있다면 이 것을 사용해 images-archive.tar file의 content를 다음과 같이 확인합니다.

● tar 항목 읽기 및 쓰기

TarFile class 외에도 tar 압축 file에서 개별적인 항목을 읽고 쓰기 위한 TarEntry, TarEntryFormat, TarReader, TarWriter 등의 class가 존재합니다. 이들은 GzipStream과 결합하여 쓰거나 읽을 때 항목을 압축하거나 해제할 수 있습니다.

.NET에서 지원하는 tar에 관한 더 자세한 사항은 아래 link를 참고하시기 바랍니다.

System.Formats.Tar Namespace | Microsoft Learn

System.Formats.Tar Namespace

Contains types used in reading and writing data in the Tape Archive (TAR) file archiving format.

learn.microsoft.com

(8) Random access handle을 사용한 읽고 쓰기

.NET의 처음 20년 동안은 file을 직접적으로 처리하는 유일한 API는 stream class였습니다. 이들은 data를 순차적으로 처리해야 하는 자동화된 작업에 적합합니다. 하지만 사람이 data와 상호작용하는 경우 종종 같은 위치로 여러번 이동하고 되돌아 와야할 때가 있습니다. 이에 따라 .NET 6부터는 file stream이 필요없이 file에 대해 직접적으로 작동하면서 randome으로 접근할 수 있는 새로운 API를 도입하게 되었습니다.

해당 예제를 만들어 보기 위해 아래와 같이 code를 작성합니다. 이 예제는 myTxt.txt라는 file에 대한 handle을 가져오도록 합니다.

using Microsoft.Win32.SafeHandles;
using System.Text;

using SafeFileHandle handle = File.OpenHandle(path: "myTxt.txt", mode: FileMode.OpenOrCreate, access: FileAccess.ReadWrite);

그런다음 file에 저장할 내용을 아래와 같이 작성합니다. 이 예제는 abcdefg라는 문자열을 byte array로 encoding하여 읽기전용 memory buffer에 담은 다음 file로 저장하는 동작을 수행합니다.

ReadOnlyMemory<byte> buffer = new(Encoding.UTF8.GetBytes("abcdefg"));
await RandomAccess.WriteAsync(handle, buffer, fileOffset: 0);

file을 읽기위해서는 우선 file의 길이(length)값을 가져온 다음 그 값을 통해 읽은 content를 담아둘 memory buffer를 할당합니다.

long length = RandomAccess.GetLength(handle);
Memory<byte> contentBytes = new(new byte[length]);

await RandomAccess.ReadAsync(handle, contentBytes, fileOffset: 0);
string content = Encoding.UTF8.GetString(contentBytes.ToArray());
WriteLine($"파일내용: {content}");

3. Text의 encoding과 decoding

Text 문자는 다양한 방식으로 표현될 수 있습니다. 예를 들어 alphabet은 전신을 통해 전송할 수 있는 일련의 점과 선으로 구성되는 Morse 부호로 encode 될 수 있습니다.

비슷하게 computer에서의 text도 code의 공간 안에서 code point를 나타내는 bit(1과 0)로 저장됩니다. 대부분의 code point는 단일 문자로 표현되지만 형식지정과 같은 다른 의미를 가질 수도 있습니다.

예를 들어 ASCII는 128 code point를 가진 code공간을 가지고 있습니다. .NET은 Unicode라고 하는 표준을 통해 text를 내부적으로 endcode 합니다. Unicode는 백만 code point이상을 가지고 있습니다.

때로는 text를 Unicode를 사용하지 않거나 Unicode의 변형을 사용하는 system에서 사용하기 위해 .NET 외부로 보내야 하는 경우가 있는데 이 때문에 encoding사이에 변환방법을 아는 것은 중요합니다.

아래 표에서는 computer에서 일반적으로 사용되는 text ecoding을 나열하고 있습니다.

Encoding	Description
ASCII	byte중 하위 7bit만을 사용함으로서 문자의 범위가 제한적입니다.
UTF-8	각 Unicode code point를 1~4byte의 sequence로 나타냅니다.
UTF-7	UTF-8보다 7bit channel에서 더 효휼적으로 설계되었지만 보안과 견고함에서 문제점을 가지고 있으므로 UTF-7보다는 UTF-8을 더 권장합니다.
UTF-16	각 Unicode code point를 1~2개의 16bit integer로 표현합니다.
UTF-32	각 Unicode code point를 32bit integer로 표현하므로 가변 길이 encoding의 다른 Unicode encoding과는 달리 고정된 길이의 encoding입니다.
ANSI/ISO encodings	특정 언어 또는 언어의 group을 지원하기 위해 사용되는 다양한 code page에 대한 지원을 제공합니다.

현시점에 대부분의 system은 UTF-8을 기본으로 사용하고 있으며 .NET에서는 Encoding.Default로 나타낼 수 있습니다. 상술하였듯 Encoding.UTF7은 보안에 취약하므로 사용을 피해야 하며 이러한 이유로 C# compiler는 UTF-7 사용을 시도할 때 경고를 띄우고 있습니다. UTF-7은 다른 system과의 호환성을 위해 어쩔 수 없이 text를 encoding 해야 하는 경우를 위해서 선택적으로 사용할 수 있도록 남아있을 뿐입니다.

(1) Byte array로 문자열 encoding 하기

csStudy09 solution에서 WorkingWithEncodings이름의 project를 생성하고 Program.cs에서는 System.Text namespace를 import 한 뒤 사용자로 부터 선택된 encoding을 사용해 문자열을 encode 하는 문을 아래와 같이 작성합니다. 또한 각 byte는 loop를 통해 문자열로 decode 한 다음 이를 출력하도록 합니다.

WriteLine("Encodings");
WriteLine("[1] ASCII");
WriteLine("[2] UTF-7");
WriteLine("[3] UTF-8");
WriteLine("[4] UTF-16 (Unicode)");
WriteLine("[5] UTF-32");
WriteLine("[6] Latin1");
WriteLine("[any other key] Default encoding");
WriteLine();
            
Write("Press a number to choose an encoding.");
ConsoleKey number = ReadKey(intercept: true).Key;
WriteLine(); WriteLine();

Encoding encoder = number switch
{
    ConsoleKey.D1 or ConsoleKey.NumPad1 => Encoding.ASCII,
    ConsoleKey.D2 or ConsoleKey.NumPad2 => Encoding.UTF7,
    ConsoleKey.D3 or ConsoleKey.NumPad3 => Encoding.UTF8,
    ConsoleKey.D4 or ConsoleKey.NumPad4 => Encoding.Unicode,
    ConsoleKey.D5 or ConsoleKey.NumPㄴad5 => Encoding.UTF32,
    ConsoleKey.D6 or ConsoleKey.NumPad6 => Encoding.Latin1,
    _ => Encoding.Default
};

// encode할 문자열
string message = "Café £4.39";
WriteLine($"Text to encode: {message} Characters: {message.Length}");

// 문자열을 byte array로 encode
byte[] encoded = encoder.GetBytes(message);

// encode후 byte 확인
WriteLine("{0} used {1:N0} bytes.", encoder.GetType().Name,
encoded.Length);
WriteLine();

// 각 byte 열거
WriteLine($"BYTE | HEX | CHAR");
foreach (byte b in encoded)
{
    WriteLine($"{b,4} | {b.ToString("X"),3} | {(char)b,4}");
}

string decoded = encoder.GetString(encoded);
WriteLine(decoded);

예제를 실행하고 ASCII선택을 위해 1을 누르면 아래와 같이 결과를 확인할 수 있습니다. 표시된 byte결과를 보면 pound 기호 (£)와 accent e (é)는 ASCII로 표현되지 않았음을 확인할 수 있습니다. 따라서 이때는 ?문자가 대신 사용되었습니다.

다시 예제를 실행하고 이번에는 UTF-8인 3을 입력합니다. UTF-8에서는 위 두 문자를 위해 추가로 2 byte를 더 필요로 하지만(총 12byte) é 과 £ 문자에 대한 encode와 decode가 가능합니다.

UTF-16은 모든 문자에 대해 2byte를 필요로 하므로 총 20byte가 사용되며 é 와 £문자 역시 encode와 decode가 가능합니다. 해당 encoding은 .NET에서 내부적으로 char와 string값을 저장하기 위해 사용됩니다.

(2) File로 text를 encoding 하고 decoding 하기

StreamReader와 StreamWriter 같은 stream helper class를 사용할 때 사용하고자 하는 encoding을 지정할 수 있습니다. helper로 작성하면 text는 자동적으로 encoded 되며 helper로부터 읽으면 byte는 자동적으로 decode 됩니다.

Encoding을 지정하려면 helper type의 생성자로 두 번째 매개변수를 통해 encoding을 다음과 같이 전달합니다.

StreamReader reader = new(stream, Encoding.UTF8); 
StreamWriter writer = new(stream, Encoding.UTF8);

때로는 다른 system에서 사용할 file을 생성하기 때문에 어떤 encoding을 사용할지 선택할 수 없는 경우가 있습니다. 만약 이런 상황이라면 가장 적은 수의 byte를 사용하되 필요한 모든 문자를 저장할 수 있는 것을 선택해 보는 것이 도움이 될 수 있습니다.

4. Random access handle을 가지는 읽기 및 쓰기

.NET 6부터는 file stream이 없이도 file을 대상으로 작업이 가능한 새로운 API를 도입하였습니다.

이를 위해 우선 아래와 같이 file에 대한 handle을 가져와야 합니다.

using Microsoft.Win32.SafeHandles;
using System.Text;

using SafeFileHandle handle = File.OpenHandle(path: "test.txt", mode: FileMode.OpenOrCreate, access: FileAccess.ReadWrite);

이렇게 하고 나면 byte array로 encode 된 text를 읽기 전용 memory buffer에 아래와 같이 작성하고 이를 file로 저장할 수 있습니다.

ReadOnlyMemory<byte> buffer = new(Encoding.UTF8.GetBytes("test123123"));
await RandomAccess.WriteAsync(handle, buffer, fileOffset: 0);

file에서 읽기 위해서는 file의 길이(크기)를 가져와 해당 길이만큼의 공간을 memory buffer에 할당하여 file을 읽어 들입니다.

long length = RandomAccess.GetLength(handle);
Memory<byte> contentBytes = new(new byte[length]);
await RandomAccess.ReadAsync(handle, contentBytes, fileOffset: 0);

string content = Encoding.UTF8.GetString(contentBytes.ToArray());
WriteLine($"Content of file: {content}");

5. Object graph 직렬화

Object graph는 직접 참조 혹은 참조 chain을 통해 간접적으로 서로 연결된 다수의 개체입니다.

직렬화는 지정한 형식을 사용해 실제 object graph를 일련의 byte로 변환하는 처리를 말합니다.(역직렬화는 이런 처리를 반대로 수행합니다.) 직렬화를 통해 우리는 실제 개체의 현재 상태를 저장할 수 있으며 이후에 그 상태 그대로 개체를 다시 재생할 수 있습니다. 예를 들어 대표적으로 game을 들 수 있는데 현재 game의 진행상태를 저장함으로서 우리는 이후에 마지막상태에서 game을 계속 진행할 수 있습니다. 직렬화된 개체는 database나 file로 저장됩니다.

지정할 수 있는 format(형식)에는 수십 가지가 있지만 대부분의 경우 XML(eXtensible Markup Language)나 JSON(JavaScript Object Notation)이 둘 중 하나를 사용합니다.

JSON은 data를 상당히 소형화할 수 있는 것으로 web이나 mobile application에서 최적화되어 있습니다. XML은 JSON보다 훨씬 장황하며 주로 legacy system에서 지원되는 경우가 많습니다. 따라서 직렬화된 개체 graph의 크기를 최소화하려면 JSON을 사용하는 것이 좋습니다. JSON은 태생적으로 JavaScript를 위한 직렬화형식이므로 개체 graph를 web이나 mobile application으로 전송하기에도 적합한 형식이라 할 수 있습니다. mobile app은 대게 제한된 대역폭환경에서 동작하는 경우가 많으므로 byte의 수는 중요한 요소로 작용합니다.

.NET은 XML과 JSON으로 직렬화하고 그 반대를 수행할 수 있는 다수의 class를 가지고 있는데, 그중 XmlSerializer와 JsonSerializer가 가장 대표적인 class에 해당합니다.

(1) XML 직렬화

일반적으로 가장 많이 사용되는 직렬화 형식 중 하나가 바로 XML입니다. 일반적인 예제를 만들어 보기 위해 csStudy09 solution에서 WorkingWithSerialization이름의 project를 생성하고 자체 혹은 파생된 class에서만 접근할 수 있는 protected속성인 Group으로 Student.cs이름의 class file를 아래와 같이 생성합니다.

public class Student
{
    public Student(int group)
    {
        Group = group;
    }

    public string? Name { get; set; }
    public DateTime DateOfBirth { get; set; }
    public HashSet<Student>? Friends { get; set; }
    protected int Group { get; set; }
}

예제에서는 초기 salary값을 설정하기 위해 단일 매개변수를 가진 생성자를 사용하고 있습니다. Program.cs에서는 기존의 문을 모두 삭제하고 XML 직렬화에 필요한 정적 Environment와 Path namespace를 import 합니다.

using static System.Environment;
using static System.IO.Path;

그리고 Student instance의 개체 graph를 생성하는 문을 아래와 같이 추가해 줍니다.

List<Student> students = new()
{
    new(1)
    {
        Name = "홍길동",
        DateOfBirth = new(year: 2014, month: 9, day: 14)
    },
    new(2)
    {
        Name = "홍길영",
        DateOfBirth = new(year: 2014, month: 6, day: 29)
    },
    new(3)
    {
        Name = "장진구",
        DateOfBirth = new(year: 2014, month: 3, day: 7),
        Friends = new()
        {
            new(4)
            {
                Name = "김말순",
                DateOfBirth = new(year: 2014, month: 7, day: 7)
            }
        }
    }
};

// Person의 List를 XML로 형식화할 개체 생성
XmlSerializer xs = new(type: students.GetType());
            
// 작성할 file생성
string path = Combine(CurrentDirectory, "students.xml");
using (FileStream stream = File.Create(path))
{
    // 개체 graph를 stream으로 직렬화
    xs.Serialize(stream, students);
}

Console.WriteLine("Written {0:N0} bytes of XML to {1}", arg0: new FileInfo(path).Length, arg1: path);
Console.WriteLine();
            
Console.WriteLine(File.ReadAllText(path));

예제를 실행하면 아마도 다음과 같은 결과를 표시할 것입니다.

위 오류를 해결하기 위해서는 Student.cs에서 매개변수 없는 생성자를 아래와 같이 추가해줘야 합니다.

public Student() { }

사실 위 생성자는 어디에서도 사용되지 않지만 반드시 존재해야 XmlSerializer가 새로운 Student instance를 역직렬화 처리 중에 호출할 수 있습니다.

예제를 실행하고 결과를 확인해 봅니다.

결과에서는 '<Name>홍길동</Name>'과 같이 XML요소로 개체 graph가 직렬화되었으며 Group속성은 public속성이 아니기에 포함되지 않았습니다.

(2) XML 경량화하기

예제에서 일부 field는 요소대신 attribute를 사용해 더욱 경량화할 수 있습니다.

Student.cs에서 System.Xml.Serialization namespace를 import한뒤

using System.Xml.Serialization;

Name, DateOfBirth속성에 해당 [XmlAttribute] attribute를 적용합니다. 이때 각 attribute에 아래와 같이 줄임말을 적용합니다.

[XmlAttribute("nm")]
public string? Name { get; set; }

[XmlAttribute("dob")]
public DateTime DateOfBirth { get; set; }

위와 같이 적용 후 다시 예제를 실행하면 설정한 줄임말이 사용됨으로써 file공간이 절약됨을 알 수 있습니다. 따라서 생성된 file의 용량이 이전보다 더 줄어들게 됩니다.

(3) XML file 역직렬화

Memory에 실제 개체로 XML file을 역직렬화하기 위해 Program.cs에서 XML file을 열고 역직렬화하는 문을 아래와 같이 작성합니다.

Console.WriteLine();
Console.WriteLine("* Deserializing XML files");

string path = Combine(CurrentDirectory, "students.xml");

List<Student> students = new();
XmlSerializer xs = new(type: students.GetType());

using (FileStream xmlLoad = File.Open(path, FileMode.Open))
{
    List<Student>? loadedStudent = xs.Deserialize(xmlLoad) as List<Student>;
    if (loadedStudent is not null)
    {
        foreach (Student p in loadedStudent)
        {
            Console.WriteLine("{0} has {1} children.", p.Name, p.Friends?.Count ?? 0);
        }
    }
}

위 예제를 실행하면 XML로부터 student개체를 load 하여 아래와 같이 열거할 것입니다.

이 외에도 XML을 생성하는 데 사용할 수 있는 다른 많은 attribute들도 존재합니다.

만약 어떠한 annotation도 사용하지 않는다면 XmlSerializer는 역직렬화에서 속성의 이름에 대소문자를 구분하지 않고 수행합니다.

XmlSerializer를 사용할 때 오로지 public field와 속성만을 포함하며 type은 반드시 매개변수 없는 생성자를 가져야 합니다. 또한 attribute를 사용해 출력을 사용자정의할 수 있습니다.

(4) JSON 직렬화

Newtonsoft.Json는 Json.NET으로 알려져 있으며 JSON 직렬화에 사용할 수 있는 가장 인기 있고 강력한 .NET library 중 하나입니다.

NuGet package manager에서 download를 counter 하는 데 사용되는 단위는 32bit integer인데 Newtonsoft.Json의 인기가 너무 높은 나머지 여기서 수용가능한 숫자의 범위를 넘어설 정도의 download횟수가 기록된 적도 있을 정도입니다.

Json.NET을 사용하기 위해 우선 Nuget Package에서 아래와 같이 Newtonsoft.Json을 검색해 최신 version을 내려받습니다.

그리고 Program.cs에서 text file을 생성하고 file에 JSON으로 student를 직렬화하는 구문을 아래와 같이 추가합니다.

List<Student> students = new()
{
    new(1)
    {
        Name = "홍길동",
        DateOfBirth = new(year: 2014, month: 9, day: 14)
    },
    new(2)
    {
        Name = "홍길영",
        DateOfBirth = new(year: 2014, month: 6, day: 29)
    },
    new(3)
    {
        Name = "장진구",
        DateOfBirth = new(year: 2014, month: 3, day: 7),
        Friends = new()
        {
            new(4)
            {
                Name = "김말순",
                DateOfBirth = new(year: 2014, month: 7, day: 7)
            }
        }
    }
};

string jsonPath = Combine(CurrentDirectory, "student.json");
using (StreamWriter jsonStream = File.CreateText(jsonPath))
{
    Newtonsoft.Json.JsonSerializer jss = new();
    jss.Serialize(jsonStream, students);
}

Console.WriteLine();
Console.WriteLine("Written {0:N0} bytes of JSON to: {1}", arg0: new FileInfo(jsonPath).Length, arg1: jsonPath);

Console.WriteLine(File.ReadAllText(jsonPath));

예제를 실행해 보면 JSON은 요소로 이루어진 XML에 비해 byte의 수가 절반도 안 되는 훨씬 적은 용량만이 필요함을 알 수 있습니다. 심지어 attribute를 사용한 XML에 비해서도 더 작은 용량입니다.

(5) 고성능 JSON 처리

.NET Core 3.0은 JSON처리에 필요한 새로운 namespace인 System.Text.Json를 추가하였으며 Span와 같은 API를 사용하여 성능에 최적화하였습니다.

Json.NET과 같은 이전 library는 UTF-16을 읽음으로써 구현되는데 HTTP를 포함한 대부분의 network protocol이 UTF-8을 사용하고 Json.NET의 Unicode 문자열 값으로 부터 UTF-8로 변환하는 것을 피할 수 있기 때문에 UTF-8을 사용하여 JSON문서를 읽고 쓰는 것이 더 성능이 좋다고 할 수 있습니다.

Micorsoft는 이 새로운 API를 통해 상황에 따라 1.3 ~ 5배까지 성능향상을 달성했습니다.

본래 Json.NET의 제작자인 James Newton-King은 그가 JSON API에 관한 comment에서 'Json.NET은 사라지지 않는다.'라고 언급한 것처럼 Microsoft와 협업하여 새로운 JSON type을 개발하였습니다.

JSON type을 역직렬화하는데 새로운 JSON API를 사용하기 위해 WorkingWithSerialization project의 Program.cs상단에서 직렬화를 수행하기 위한 새로운 JSON class를 별칭을 사용해 Import 합니다. 별칭은 위에서 사용한 Json.NET의 이름과 충돌하는 것을 피하기 위한 것입니다.

using FastJson = System.Text.Json.JsonSerializer;

그리고 JSON file을 열어 역직렬화를 수행한 뒤 Student에 대한 frends의 이름과 수를 출력하도록 하는 문을 아래와 같이 작성합니다.

string jsonPath = Combine(CurrentDirectory, "student.json");

using (FileStream jsonLoad = File.Open(jsonPath, FileMode.Open))
{
	// deserialize object graph into a List of Person
	List<Student>? loadedStudent = await FastJson.DeserializeAsync(utf8Json: jsonLoad, returnType: typeof(List<Student>)) as List<Student>;

	if (loadedStudent is not null)
	{
		foreach (Student s in loadedStudent)
		{
			Console.WriteLine("{0} has {1} children.", s.Name, s.Friends?.Count ?? 0);
		}
	}
}

위 예제를 실행하면 다음과 같은 결과를 표시할 것입니다.

개발 생산성을 위해서는 Json.NET을, 다양한 기능 또는 성능을 위해서는 System.Text.Json을 사용합니다. 아래 link를 통해 이 둘에 대한 차이목록을 확인해 볼 수 있습니다.

Migrate from Newtonsoft.Json to System.Text.Json - .NET | Microsoft Learn

Migrate from Newtonsoft.Json to System.Text.Json - .NET

Learn about the differences between Newtonsoft.Json and System.Text.Json and how to migrate to System.Text.Json.

learn.microsoft.com

(6) JSON 처리 제어

JSON처리 방식에 관해서는 아래와 같이 사용가능한 많은 option들이 존재합니다.

Field의 포함 또는 제외
Casing 정책 설정
대소문자 구분 정책 설정
공백의 처리방식 설정

예제를 위해 csStudy09 solution에서 WorkingWithJson이름의 project를 생성한 뒤 Program.cs에서 기존의 문을 모두 삭제하고 고성능 JSON을 위한 주요 namespace와 System. Environment, System.IO.Path namespace를 정적 import 합니다.

using System.Text.Json; 

using static System.Environment;
using static System.IO.Path;

그다음 Book.cs이라는 새로운 class file을 추가하고 그 안에 Book class를 아래와 같이 정의합니다.

using System.Text.Json.Serialization;

namespace WorkingWithJson
{
	public class Book
	{
		public Book(string title)
		{
			Title = title;
		}

		public string Title { get; set; }

		public string? Author { get; set; }
		
		[JsonInclude]
		public DateTime PublishDate;

		[JsonInclude]
		public DateTimeOffset Created;

		public ushort Pages;
	}
}

다시 Program.cs로 돌아와 Book class의 instance를 생성하고 이를 JSON으로 직렬화하는 문을 아래와 같이 작성합니다.

Book mybook = new(title: "어린왕자")
{
	Author = "생텍쥐페리",
	PublishDate = new(year: 1943, month: 4, day: 6),
	Pages = 250,
	Created = DateTimeOffset.UtcNow,
};

JsonSerializerOptions options = new()
{
	IncludeFields = true, // 모든 field를 포함
	PropertyNameCaseInsensitive = true,
	WriteIndented = true,
	PropertyNamingPolicy = JsonNamingPolicy.CamelCase,
	Encoder = JavaScriptEncoder.Create(UnicodeRanges.All)
};

string filePath = Combine(CurrentDirectory, "mybook.json");

using (Stream fileStream = File.Create(filePath))
{
	JsonSerializer.Serialize<Book>(utf8Json: fileStream, value: mybook, options);
}

Console.WriteLine("{0:N0} byte의 JSON file {1}", arg0: new FileInfo(filePath).Length, arg1: Path.GetFileName(filePath));
Console.WriteLine();
			
Console.WriteLine(File.ReadAllText(filePath));

예제를 실행하면 다음과 같은 결과를 표시할 것입니다.

생성된 JSON file은 총 171byte로 member의 이름은 publishDate와 같이 camelCase가 적용되었습니다. 이는 Javascript를 사용하는 browser를 위한 가장 적합한 방식입니다. 또한 option설정에서 pages를 포함하여 모든 field를 포함하도록 했고 결과를 보면 사람이 읽기 쉽도록 하기 위해 JSON자체에 들여 쓰기 등의 서식이 적용되어 있음을 확인할 수 있습니다. DateTime와 DateTimeOffset값은 단일 표준 문자열 값으로 저장됩니다.

Program.cs에서 JsonSerializerOptions을 설정할 때 PropertNameCaseInsensitive, WriteIndented와 IncludeFields부분을 주서처리하고 예제를 다시 실행해 보면 결과를 다음과 같이 바뀌게 됩니다.

결과를 보면 JSON은 133byte가 되어 이전 171byte보다 용량이 작아졌으며 member의 이름은 normal casing가 사용되어 PublishDate와 같이 되었습니다. Pages field는 포함되지 않았으며 [JsonInclude]와 같은 attribute가 포함된 field는 정상적으로 포함되었습니다.

(7) HTTP응답을 위한 새로운 JSON 확장 method

.NET 5에서 Microsoft는 HttpResponse의 확장 method와 같이 System.Text.Json namespace type을 개선하였습니다.

(8) Newtonsoft에서 신규 JSON으로의 변환

만약 Newtonsoft Json.NET library를 사용하는 code를 신규 System.Text.Json namespace로 변환해야 한다면 아래 link에서 Microsoft가 이를 위해 마련해 둔 문서를 찾아볼 수 있습니다.

Migrate from Newtonsoft.Json to System.Text.Json - .NET | Microsoft Learn

Migrate from Newtonsoft.Json to System.Text.Json - .NET

Learn about the differences between Newtonsoft.Json and System.Text.Json and how to migrate to System.Text.Json.

learn.microsoft.com

6. 환경변수

환경변수는 system및 사용자 정의가능한 값이며 이는 process의 동작을 실행하는 방식에 영향을 줄 수 있습니다. 일반적으로는 ASP.NET Core project에서 개발과 production 설정사이를 전환하기 위한 설정에 사용하거나 database연결 문자열에서 service key와 password같이 process에서 필요한 값을 전달하는데 사용됩니다.

Windows에서 환경변수는 machine(system), user, process라는 3가지 범위에서 설정할 수 있습니다. 환경변수를 가져오거나 설정하는 method는 기본적으로 process의 범위 수준을 가정하며 process, user, machine의 EnvironmentVariableTarget을 지정하는 override를 가집니다.

GetEnvironmentVariables	지정된 수준의 범위 혹은 현재 process에 대한 모든 환경변수의 IDictionary를 반환합니다.
GetEnvironmentVariable	명몇된 환경변수의 값을 반환합니다.
SetEnvironmentVariable	명명된 환경변수의 값을 설정합니다.
ExpandEnvironmentVariables	문자열로 구성된 모든 환경변수, 예를 들어 "Computer name : %COMPUTER_NAME%"에서와 같은 값에서 %%를 해당 식별되는 값으로 변환합니다.

(1) 모든 환경 변수 가져오기

예제를 통해 다양한 범위 수준에서 현재 환경변수를 어떻게 확인할 수 있는지 확인해 보겠습니다. Program.cs를 아래와 같이 작성합니다.

using System.Collections;
using static System.Environment;

IDictionary evs = GetEnvironmentVariables();
IDictionary evm = GetEnvironmentVariables(EnvironmentVariableTarget.Machine);
IDictionary evu = GetEnvironmentVariables(EnvironmentVariableTarget.User);

foreach (var key in evs.Keys)
{
    Console.WriteLine("key : {0}, value : {1}", key, evs[key]!.ToString());
}

Console.WriteLine("-------------------------------------------------------");

foreach (var key in evm.Keys)
{
    Console.WriteLine("key : {0}, value : {1}", key, evs[key]!.ToString());
}

Console.WriteLine("-------------------------------------------------------");

foreach (var key in evu.Keys)
{
    Console.WriteLine("key : {0}, value : {1}", key, evs[key]!.ToString());
}

위 예제는 각각의 범위에 속한 모든 환경변수를 표시하도록 합니다.

(2) 환경변수를 확장하고 설정하고 가져오기

어떤 경우는 내장된 환경변수를 포함하고 있는 문자열을 형식화하여 표시해야 하는 경우가 있을 수 있습니다. 이러한 경우 환경변수는 %문자로 변수를 감싸는 형태로 표시됩니다.

"User : %USERNAME%, Computer : %COMPUTER_NAME%"

필요하다면 환경변수는 Windows상에서 set 혹은 setx 명령을 통해 설정할 수 있습니다.

변수 범위	예제
Session/Shell	set MY_TMP_VAR="me"
User	setx MY_TMP_VAR "me"
Machine	setx MY_TMP_VAR "me" /M

set 명령은 임시 환경변수를 정의하는 것으로 즉시 값을 다시 읽거나 현재 shell 또는 session안에서 읽을 수 있습니다. 다만 해당 범위의 값을 설정할때는 위 표에서 처럼 =문자를 사용해 값을 할당함에 주의해야 합니다.

setx 명령은 영구적인 환경변수를 설정하지만 현재 shell 또는 session을 닫고 재시작해야만 해당 환경변수를 읽을 수 있습니다. 또한 이 명령에서는 값의 할당을 위해 =문자를 사용하지 않음에 주의해야 합니다.

setx명령에 관한 좀더 자세한 사항은 아래 link를 참고해 주시기 바랍니다.

setx | Microsoft Learn

setx

Reference article for the setx command, which creates or modifies environment variables in the user or system environment, without requiring programming or scripting.

learn.microsoft.com

또한 환경변수는 Windows상에서 Settings -> System -> About -> Advanced system settings -> System Properties 순서로 이동하면 해당 화면을 통해 변수항목과 해당 값을 확인할 수 있습니다.

임시적으로 환경변수를 설정하는 것은 아래와 같이 export 명령으로도 가능합니다.

export MY_TMP_VAR=me

export 명령에 대한 자세한 사항은 아래 link를 참고하시기 바랍니다.

export Man Page - Linux - SS64.com

Set an environment variable. The supplied names are marked for automatic export to the environment of subsequently executed commands. If no names are supplied, or if the '-p' option is given, a list of exported names is displayed. To view the environment v

ss64.com

위 예제에서 알아본 방법외에 환경변수를 설정하고 값을 확인하고 확장하는 또 다른 방법이 존재하며 이를 예제를 통해 알아보도록 하겠습니다.

Program.cs에서 환경변수를 포함하고 있는 문자열을 정의한 뒤 이에 대한 값을 출력하도록 아래와 같이 code를 작성합니다.

string comUser = "User name : %USERNAME%, Computer name : %COMPUTERNAME%";

Console.WriteLine(ExpandEnvironmentVariables(comUser));

이번에는 MY_TMP_VAR 이름의 환경변수를 process범위로 설정하고 해당 값을 출력하도록 합니다.

string tmpKey = "MY_TMP_VAR";
SetEnvironmentVariable(tmpKey, "cliel");
string? tmpResult = GetEnvironmentVariable(tmpKey);

Console.WriteLine($"{tmpKey}: {tmpResult}");

이번에는 MY_TMP_VAR 환경변수를 3개의 모든 범위수준에서 읽어오도록 program.cs를 아래와 같이 변경합니다.

string tmpKey = "MY_TMP_VAR";

string tmpValue = GetEnvironmentVariable(tmpKey, EnvironmentVariableTarget.Machine);
Console.WriteLine($"Machine - {tmpKey}: {tmpValue}");

tmpValue = GetEnvironmentVariable(tmpKey, EnvironmentVariableTarget.User);
Console.WriteLine($"User - {tmpKey}: {tmpValue}");

tmpValue = GetEnvironmentVariable(tmpKey, EnvironmentVariableTarget.Process);
Console.WriteLine($"Process - {tmpKey}: {tmpValue}");

그런다음 project folder에서 다음과 같이 launchSettings.json file을 생성합니다.

{
    "profiles": {
        "test": {
            "commandName": "Project",
            "environmentVariables": 
            {
                "MY_TMP_VAR": "me"
            }
        }
    }
}

여기서 test는 project 이름입니다.

terminal이나 command창에서는 다음 명령을 통해 user와 machine 두 범위에서 같은 이름의 환경변수를 설정합니다.

setx MY_TMP_VAR "me1"
setx MY_TMP_VAR "tmp2" /M

권한관련 오류가 발생되는 경우 terminal을 관리자 권한으로 실행시켜야 합니다.

예제를 실행시켜 다음과 같은 결과를 확인합니다.

결과를 통해 알 수 있듯이 launchSettings. json file에서의 설정은 process 수준으로 설정됩니다.

[C# 12와 .NET 8] 8. 공용 .NET Type

클리엘 — Fri, 23 Feb 2024 12:09:55 +0900

.NET에는 일반적인 개발과정에서 사용할 수 있는 숫자, 문자열, collection등과 span, index, range와의 작업, network access 등 몇 가지 공용 type들을 포함하고 있습니다.

1. 숫자 다루기

Data에 관한 가장 일반적인 작업중 하나가 바로 숫자입니다. 아래표는 .NET에서 숫자에 관한 가장 일반적인 type을 나타내고 있습니다.

Namespace	Example Type	Description
System	SByte, Int16, Int32, Int64	정수로서 음수, 양수, 0
System	Byte, UInt16, UInt32, UInt64	기수로서 0, 양수 / 부호가 없으므로 U로 표현
System	Half, Single, Double	실수로서, 부동소수점 수
System	Decimal	실수(accurate real)로서 과학, 공학, 금융분야에서 사용
System.Numbers	BigInteger, Complex, Quaternion	임의의 큰 정수, 복소수, 4차원

.NET은 .NET Framework 1.0부터 32bit float과 64bit double type을 지원해 왔습니다. IEEE 754 명세는 또한 16bit floating-point 표준을 정의하였는데 Machine learning의 일부 algorithm에서 해당 type을 필요로 하므로 Microsoft는 System.Half type을 .NET 5부터 포함하였으며 .NET 7부터는 System.Int128와 System.UInt128 type을 포함하였습니다.

현재 C#언어는 half와 Int128, UInt128에 대한 별칭을 따로 정의하지 않았으므로 System.Half와 System.Int128, Sysem.UInt128을 그대로 사용해야 합니다.

(1) Big integer 사용

C# 별칭이 있는 .NET type에서 저장가능한 가장 큰 정수는 18조 5천억으로 unsigned ulong integer입니다. 만약 이것보다 더 큰 수를 저장해야 한다면 BigInteger를 사용해야 합니다.

Visual Studio에서 csStudy08 solution을 만들고 여기에 WorkingWithNumbers이름의 Console App project를 추가합니다. 그런 뒤 Program.cs에서 기존구문을 모두 삭제하고 ulong type의 최댓값과 BigInteger를 통해 30 자릿수의 표시하는 문을 아래와 같이 추가합니다.

using System.Numerics;

ulong big = ulong.MaxValue;
Console.WriteLine($"{big,40:N0}");

BigInteger bigger = BigInteger.Parse("123456789012345678901234567890");
Console.WriteLine($"{bigger,40:N0}");

예제에서 사용한 format code 40은 오른쪽으로 40자리수 만큼 정렬하고자 하는 것이므로 두 숫자 모두 오른쪽 가장자리로 줄지어 표시하게 되며 N0은 천 단위 분리자와 소수점 0자리 사용을 의미합니다.

예제를 실행하면 다음과 같은 결과를 표시할 것입니다.

(2) 복소수 사용

복소수는 a + bi로 표현될 수 있으며 이때 a와 b는 실수, i는 허수 단위이고 여기서 i² = -1입니다. 실수부 a가 0이면 순허수, 허수부 b가 0이면 이것은 실수입니다.

복소수는 많은 STEM(science, technology, engineering and mathematics)연구분야에서 실질적으로 응용되고 있으며 가수의 실수와 허수 부분이 별도로 더해짐으로써 추가되었습니다.

(a + bi) + (c + di) = (a + c) + (b + d)i

WorkingWithNumbers project의 Program.cs에서 아래와 같이 2개의 복소수를 더하는 문을 추가합니다.

Complex c1 = new(real: 4, imaginary: 2);
Complex c2 = new(real: 3, imaginary: 7);
Complex c3 = c1 + c2;

Console.WriteLine($"{c1} added to {c2} is {c3}");
Console.WriteLine("{0} + {1}i added to {2} + {3}i is {4} + {5}i", c1.Real, c1.Imaginary, c2.Real, c2.Imaginary, c3.Real, c3.Imaginary);

예제를 실행하면 다음과 같은 결과를 표시할 것입니다.

..NET 6이전에는 (4, 2)와 (3, 7)을 더하면 (7, 9)가 되는 다른 형식을 사용했지만 .NET 7이후부터는 꺽쇠 괄호와 semi-colon을 사용하는 다른 기본형식을 사용합니다. 이는 일부 문화권에서 음수를 나타내기 위해 괄호를 사용하고 십진수를 나타내기 위해 commna를 사용하기 때문입니다.

(3) Quaternion(4원수)

Quaternions은 복소수를 확장자는 숫자체계로서 실수를 넘어 4차원 연관 규범 분할 대수를 형성하며 따라서 domain도 형성합니다. 사실 실제 활용해야 할 상황이 아니라면 이런 내용들에 대한 자세한 이해할 필요는 없는데, 이들은 공간을 묘사하는 데 사용되며 따라서 다수의 computer simulation과 비행 제어 system, video game engine에서 많이 사용되고 있습니다.

(4) 난수 생성

난수가 필요하지 않다면 Random class의 instance는 아래와 같이 생성할 수 있습니다.

Random r = new();

Random class는 난수 생성의 초기화에 사용되는 seed 값을 지정하는 매개변수를 가지고 있습니다.

Random r = new(Seed: 46378);

아래 글에서 언급하였지만

[.NET/C#] - [C# 12와 .NET 8] 2. C#

[C# 12와 .NET 8] 2. C#

이번 글에서는 C# programming 언어에 대한 기본적인 사항을 살펴볼 것입니다. 전반적으로 알아야 할 용어와 C#에 대한 기본적인 문법에 대한 것들입니다. 1. C# 언어 C#을 통해 application에 대한 source co

lab.cliel.com

매개변수의 이름은 camel case로 사용하길 권장하고 있습니다. 하지만 예제에서 보듯 해당 class의 생성자를 정의한 개발자가 해당 규칙을 어기는 바람에 seed가 아닌 Seed로 사용되고 있습니다. 다시 말하지만 Seed가 아닌 seed가 되어야 합니다.

Memory를 더 할당하지 않기 위해 .NET 6에서는 Random의 공유 정적 instance를 포함하고 있습니다.

Random r = Random.Shared;

일단 Random 개체를 생성하게 되면 임의의 숫자를 생성하는 method를 아래와 같이 호출할 수 있습니다.

int ranInt = r.Next(minValue: 1, maxValue: 7); // 1에서 6사이값
double randomReal = r.NextDouble(); // 0.0에서 1.0보다 작은값
byte[] arrayOfBytes = new byte[256];
r.NextBytes(arrayOfBytes); //256 random byte array

Random class는 random숫자를 생성하기 위해 일반적으로 사용되는 다음의 method를 갖고 있습니다.

Next	Next method는 minValue와 maxValue 2개의 매개변수를 필요로 합니다. 다만 이때 maxValue값은 method가 반환하는 최댓값을 의미하는 것이 아님에 주의해야 합니다. 이는 'exclusive upper bound(배타적 상한선)'라고 하는 것으로 반환하는 최댓값보다 1 더 많아야 함을 의미합니다.
NextDouble	0.0보다 더 크거나 같으면서 1.0미만의 수를 반환합니다. float type의 값이 필요하다면 NextSingle method를 대신 사용할 수 있습니다.
NextBytes	random byte (0 to 255)값으로 array를 채우는 method로서 00~FF와 같이 16진수로서 byte값을 형식화 하기 위해 사용됩니다.

암호화와 같이 진정한 random값이 필요한 경우를 위해 RandomNumberGenerator와 같은 특별한 type을 사용할 수 있습니다.

.NET 8에서는 다음과 같은 2개의 새로운 method를 포함하였습니다.

GetItems<T, length>	해당 method에는 Type T에 대한 배열 혹은 읽기 전용 span과 생성하고자 하는 item의 수가 전달되며 이것으로 부터 ramdom하게 선택된 item을 반환합니다.
Shuffle<T>	해당 method에는 Type T에 대한 배열 혹은 일기 전용 span이 전달되며 해당 item의 순서가 ramdom하게 변경됩니다.

Random r = Random.Shared;

string[] employees = r.GetItems(
    choices: new[] { "lee", "choi", "kim", "hong" },
    length: 3);

foreach (string employee in employees)
    Console.Write($" {employee}");

Console.WriteLine();

r.Shuffle(employees);

foreach (string emploee in employees)
    Console.Write($" {emploee}");

(5) GUID 생성

GUID (globally unique identifier)는 128bit TEXT 문자열로서 중복되지 않는 고유한 값을 나타냅니다. 따라서 multi-tasking환경에서의 충돌을 방지하는 것과 같은 상황에서 사용될 수 있습니다.

System.Guid type은 값 type(구조체)로서 NewGuid method로 새로운 GUID값을 나타내며 기존 값을 문자열로서 나타내기 위한 Parse와 ParseTry method를 갖추고 있고 그 반대로 문자열을 GUID로 변환하기도 합니다.

예제를 위해 아래와 같이 NewGuid method로 GUID값을 생성하고 그 값을 byte array로 나타내기 위한 문을 아래와 같이 작성합니다.

Guid g = Guid.NewGuid();
Console.WriteLine($"Random GUID: {g}.");

byte[] guidAsBytes = g.ToByteArray();

Console.Write("GUID to byte array: ");
for (int i = 0; i < guidAsBytes.Length; i++)
    Console.Write($"{guidAsBytes[i]:X2} ");

예제를 실행하면 아래와 같이 표시할 것입니다. NewGuid method는 random한 값을 생성합니다.

2. Text

Text는 변수를 통해 사용되는 가장 일반적인 data type이라고 할 수 있습니다. 아래 표는 text와 관련된 .NET의 일반적인 type을 나타내고 있습니다.

Namespace	Type	Description
System	Char	단일 한문자
System	String	text
System.Text	StringBuilder	고성능 문자열 다루기
System.Text.RegularExpressions	Regex	고성능 문자열 pattern-matching

(1) 문자열 길이 확인하기

Text를 다루게 되는 경우 사용되는 몇 가지 일반적인 상황들이 있습니다. 예를 들어 string변수에 저장된 문자열의 길이를 알아내는 경우 등이 그것입니다.

csStudy08 solution에 WorkingWithText console app project를 추가하고 Program.cs에서 기본의 문을 모두 삭제한 뒤 도시 이름을 저장하기 위한 변수를 정의하고 console을 통해 도시이름과 길이를 출력하는 문을 아래와 같이 작성합니다.

string city = "Seoul";
Console.WriteLine($"{city} is {city.Length} characters long.");

예제를 실행하면 다음과 같은 결과를 표시할 것입니다.

(2) 문자열에서 문자 확인하기

String class는 문자열을 저장하기 위해 내부적으로 문자에 대한 array를 사용하며 또한 한문자를 읽기 위해 array 구문을 사용할 수 있는 indexer를 가지고 있습니다. Array indexer는 0부터 시작하므로 세 번째 문자라면 index는 2가 됩니다.

Program.cs에서 string변수의 첫 번째 문자와 네 번째 문자를 표시하는 문을 아래와 같이 작성합니다.

Console.WriteLine($"First char is {city[0]} and fourth is {city[3]}.");

예제를 실행하면 다음과 같은 결과를 표시합니다.

(3) 문자열 분할

문자열은 문자열 안에서 특정 문자(이를 테면 comma(,)와 같은)를 기준으로 array형태의 분리가 가능합니다.

Program.cs에서 comma로 분리된 도시이름을 포함한 단일 문자열 변수를 정의하고 이를 Split method를 통해 분리하는 문을 추가합니다. 이때 분리의 기준을 comma로 지정하며 반환된 문자열값의 array를 열거하도록 합니다.

string cities = "Seoul,Busan,Daegu,Daejeon,Jeju";
string[] citiesArray = cities.Split(',');

Console.WriteLine($"There are {citiesArray.Length} items in the array:");

foreach (string item in citiesArray)
{
    Console.WriteLine(item);
}

예제를 실행하면 다음과 같은 결과를 볼 수 있습니다.

(4) 문자열의 일부 가져오기

문자열의 일부를 가져오는 방법 중의 하나로 IndexOf method를 사용할 수 있습니다. 해당 method는 문자열 안에서 지정한 문자 또는 문자열에 대한 index위치를 반환하는 9개의 overload를 가지고 있습니다.

Substring method는 2개의 다음과 같은 2개의 overload를 가집니다.

Substring(startIndex, length) : startIndex로 시작하고 다음 length 문자만큼을 포함하는 문자열의 일부를 반환합니다.
Substring(startIndex) : startIndex로 시작하고 그다음 끝까지 모든 문자열을 포함하는 문자열의 일부를 반환합니다.

Program.cs에서 사람의 이름을 저장하는 string변수를 추가합니다. 이때 성과 이름은 공백으로 구분합니다. 그리고 해당 공백의 위치를 찾아 성과 이름을 분리하며 다른 순서로도 재결합될 수 있도록 합니다.

string fullName = "hong seojun";
int indexOfTheSpace = fullName.IndexOf(' ');

string firstName = fullName.Substring(startIndex: 0, length: indexOfTheSpace);
string lastName = fullName.Substring(startIndex: indexOfTheSpace + 1);

Console.WriteLine($"Original: {fullName}");
Console.WriteLine($"Swapped: {lastName}, {firstName}");

예제를 실행하면 다음 결과를 볼 수 있습니다.

(5) 내용에서 문자열 확인

문자열에서는 특정 문자열로 시작하는지 혹은 끝나는지, 아니면 어떤 문자열을 포함하고 있는지를 확인할 수 있습니다.

Program.cs에서 문자열 저장을 위한 string변수를 추가하고 특정 문자열로 시작하는지와 포함하는지를 확인하는 문을 아래와 같이 작성합니다.

string company = "Microsoft";
bool startsWithM = company.StartsWith("M");
bool containsN = company.Contains("N");

Console.WriteLine($"Text: {company}");
Console.WriteLine($"Starts with M: {startsWithM}, contains an N: {containsN}");

예제를 실행하면 다음과 같은 결과를 표시할 것입니다.

(6) 문자열 비교

문자열 비교 역시 문자열을 통한 가장 일반적인 작업에 해당합니다. 예를 들어 login해야 하는 사용자가 자신의 ID와 비밀번호를 입력했다면 이것을 저장된 것과 비교해야할 필요가 있습니다.

string class는 IComparable interface를 구현하고 있으므로 CompareTo instance method를 통해 문자열을 비교할 수 있고 이때 문자열 값이 더 큰지, 같은지, 아니면 더 작은지에 따라 method는 -1, 0, 1의 값을 반환하게 됩니다. IComparable interface는 이미 아래 글에게 다루어본바 있습니다.

[.NET/C#] - [C# 12와 .NET 8] 6. Interface와 Class상속

[C# 12와 .NET 8] 6. Interface와 Class상속

이번 글을 통해서는 OOP(Object-Oriented Programming)을 사용한 하나의 개체에서 다른 새로운 type을 상속하는 기본 개념에 대해 알아볼 것입니다. 또한 generic을 사용하여 어떻게 code를 안전하게 만들고

lab.cliel.com

다만 영문 대소문자는 순서에 영향을 줄 수 있고 문자열의 순서규칙은 문화권에 영향을 받습니다. 예를 들어 이중 L은 Spain어에서 하나의 문자로 취급됩니다.

일관성을 위해 때로는 문화권에 영향을 받지 않는 방식으로 비교를 수행해야할 필요가 있으며 이때 Compare라는 정적 method를 사용할 수 있습니다.

using System.Globalization;

Console.OutputEncoding = System.Text.Encoding.UTF8;
CultureInfo.CurrentCulture = CultureInfo.GetCultureInfo("en-US");

string text1 = "abc";
string text2 = "ABC";

Console.WriteLine($"문자열1: {text1}, 문자열2: {text2}");
Console.WriteLine("비교: {0}.", string.Compare(text1, text2));
Console.WriteLine("비교 (대소문자 무시): {0}.", string.Compare(text1, text2, ignoreCase: true));
Console.WriteLine("비교 (문화권및 대소문자 무시): {0}.", string.Compare(text1, text2, StringComparison.InvariantCultureIgnoreCase));

소문자 a는 대문자 A보다 더 작게 판단되므로 비교 결과가 -1이 되지만 대소문자를 무시하도록 하면 또는 더 확실하게 대소문자와 문화권을 무시하도록 설정하면 2개의 문자열을 동등하게 비교할 수 있습니다.

문자열 비교에 관해서는 아래 link를 참고하시기 바랍니다.

Collation, sorting, and string comparison - Globalization | Microsoft Learn

Collation, sorting, and string comparison - Globalization

In world-ready applications, the alphabetical order can vary among languages, and the conventions for sequencing items can also be quite different.

learn.microsoft.com

(7) 문자열 결합, 형식화 그리고 기타

아래 표에서는 string에서 사용할 수 있는 몇 가지 member를 나타내고 있습니다.

Member	Description
Trim, TrimStart, TrimEnd	해당 method는 space나 tab 그리고 carriage return과 같은 공백문자를 제거합니다.
ToUpper, ToLower	대상 문자열을 전부 대문자 혹은 소문자로 변환합니다.
Insert, Remove	특정 문자열을 삽입하거나 제거합니다.
Replace	특정 문자열을 다른 문자열로 대체합니다.
string.Empty	빈문자열를 표시하기 위해 매번 2중쌍따옴표(")를 사용하는 대신 공백을 표현하는데 사용될 수 있습니다.
string.Concat	두 문자열 변수를 연결합니다. +연산자를 피연산자인 문자열 사이에 사용해도 동일한 결과를 얻을 수 있습니다.
string.Join	하나 또는 그 이상의 문자열을 각각의 문자열 변수 사이에 문자를 통해 연결합니다.
string.IsNullOrEmpty	string변수가 null이거나 비어있는지를 확인합니다.
string.IsNullOrWhitespace	string변수가 null이거나 공백인지를 확인합니다. 이때 공백은 tab, space, carriage return, line feed등을 포함합니다.
string.Format	형식화된 문자열변수를 출력하기 위한 보간문자열의 대체 method로 명명된 매개변수대신 위치를 사용합니다.

상기 method 중 'string.'으로 표시된 method는 static method입니다. 즉, instance변수가 아닌 type에서부터 바로 호출될 수 있습니다.

Program.cs에서 문자열값의 배열을 가져와 Join method를 통해 분리 문자열을 사용하여 단일 문자열로 결하는 문을 추가합니다.

string cities = "Seoul,Busan,Daegu,Daejeon,Jeju";
string[] citiesArray = cities.Split(',');
string recombined = string.Join(" => ", citiesArray);

Console.WriteLine(recombined);

예제를 실행하면 다음과 같은 결과를 확인할 수 있습니다.

그리고 위치 매개변수와 보간 문자열 서식 구문을 사용해 같은 세 개의 변수를 두 번 표시하도록 하는 문을 추가합니다.

string fruit = "Apples";
int price = 2000;

DateTime when = DateTime.Today;

Console.WriteLine($"Interpolated: {fruit} cost {price:C} on {when:dddd}.");
Console.WriteLine(string.Format("string.Format: {0} cost {1:C} on {2:dddd}.", arg0: fruit, arg1: price, arg2: when));

예제를 실행하면 다음과 같은 결과를 표시합니다.

JetBrains Rider와 같은 일부 편집기에서는 boxing연산에 대한 경고문구를 표시할 수 있으나 지금 상황에서는 무시해도 딥니다. 만약 이러한 경고문구를 보지 않게 하고자 한다면 price와 when에서 ToString() method를 호출하면 됩니다.

참고로 Console.WriteLine method는 string.Format와 동일한 서식을 지원하고 있기 때문에 좀 더 문을 간소화할 수 있습니다.

Console.WriteLine("WriteLine: {0} cost {1:C} on {2:dddd}.", arg0: fruit, arg1: price, arg2: when);

(8) 문자열을 효휼적으로 다루기

String.Concat method나 혹은 간단히 + 연산자를 사용하면 2개의 문자열을 결합해 새로운 문자열을 만들 수 있습니다. 하지만 이런 식의 문자열결합은 .NET이 memory에 완전히 새로운 문자열을 생성해야 하므로 좋지 않은 방법이라 할 수 있습니다.

물론 대게는 단순히 2개의 문자열을 결합하는 경우라면 큰 문제가 없을 테지만 반복문안에서 많은 수의 반복으로 문자열결합을 구현하는 경우라면 성능면에서 부정적인 영향을 줄 수 있으며 memory낭비 역시 초래할 수 있습니다.

따라서 다수의 문자열을 많이 결합해야 하는 경우라면 StringBuilder type을 사용하는 것이 좋습니다. 이에 관한 내용은 아래 link을 참고해 주시기 바랍니다.

StringBuilder Class (System.Text) | Microsoft Learn

StringBuilder Class (System.Text)

Represents a mutable string of characters. This class cannot be inherited.

learn.microsoft.com

3. 정규 표현식을 통한 pattern matching

흔히 정규 표현식은 사용자로부터의 입력을 검증하는 데 사용되곤 합니다. 정규표현식은 아주 강력하지만 동시에 매우 복잡해질 수 있습니다. 거의 모든 programming언어가 정규표현식을 지원하고 있으며 이를 정의하기 위해 공통적인 특별한 문자들을 사용합니다.

표현식의 예를 만들어 보기 위해 csStudy08 solution에서 WorkingWithRegularExpressions이름의 Console App project를 생성합니다.

(1) 문자열로서 입력된 숫자 확인하기

숫자 입력을 검증하는 일반적인 예를 구현하는 것으로 시작해 보고자 합니다.

WorkingWithRegularExpressions project의 Program.cs에서 사용자에게 나이입력을 요청하고 입력된 값에서 숫자문자를 찾는 정규표현식을 아래와 같이 작성합니다.

using System.Text.RegularExpressions;

Console.Write("Enter your age: ");

string input = Console.ReadLine()!;

Regex ageChecker = new(@"\d");

if (ageChecker.IsMatch(input))
{
	Console.WriteLine("Thank you!");
}
else
{
	Console.WriteLine($"This is not a valid age: {input}");
}

위 예제에서는 아래 사항에 주목해야 합니다.

@문자는 문자열 안에서 escape문자를 사용할 수 있는 기능을 끄는데, escape문자 앞에는 backslash가 붙습니다. 예를 들어 \t는 tab을 의미하며 \n은 new line을 의미합니다. 표현식을 사용할 때는 이 기능을 바꿔 사용해야 하므로 disable 해야 합니다.
Escape문자가 @문자를 통해 비활성화되면 정규표현식으로 해석될 수 있습니다. 예를 들어 \d는 숫자를 의미하게 되는 것입니다. 이 부분에 관해서는 잠시 후 더 자세히 알아볼 것입니다.

예제를 실행하면 나이를 묻게 되고 숫자를 입력하면 다음과 같은 결과가 표시될 것입니다.

그런데 숫자가 아닌 다른 형태로 값을 입력하게 되면 결과는 달라지게 됩니다.

이번에는 숫자와 다른 문자를 섞어 입력해 봅니다.

정규표현식에서는 \d를 사용했습니다. 이는 숫자 하나를 의미합니다. 그러나 한자리 숫자 앞뒤에 무엇이 입력될 수 있는지는 명시하지 않았습니다. 해당 정규표현식을 풀어서 설명하면 '하나의 숫자를 입력하는 한 어떤 문자를 입력해도 상관없다.'가 됩니다.

정규표현식에서는 ^문자를 통해 시작되어야 하는 값을 나타낼 수 있고 $문자를 통해서는 끝나냐 하는 값을 나타낼 수 있습니다. 예제에서는 이들 기호문자를 사용해 숫자를 제외하고 입력된 값 앞뒤에 아무것도 없음을 아래와 같이 표시하도록 합니다.

Regex ageChecker = new(@"^\d+$");

이제 예제를 다시 실행하면 어떤 길이든지 0과 정수만 허용하게 됨을 알 수 있습니다.

(2) 정규 표현식 성능 향상

정규표현식 사용을 위한 .NET type은 .NET platform전역에서 사용될 수 있으며 다수의 app이 이를 내장하고 있습니다. 따라서 이들은 성능에 중요한 영향력을 가지고 있지만 Microsoft로 부터의 최적화에 대한 관심을 받지 못했습니다.

.NET 5 이후에 들어와서는 System.Text.RegularExpressions namespace가 최대의 성능을 이끌어 내기 위해 내부적으로 재작성되으며 IsMatch와 같은 method를 사용한 일반적인 정규표현식 benchmark에서는 5배 정도 빠르게 측정되었습니다. 게다가 이러한 성능적 혜택을 누리기 위해 기존에 작성되었던 code를 다시 바꿀 필요가 없습니다.

.NET 7에서 Regex class의 IsMatch method는 성능향상을 위한 ReadOnlySpan<char>을 전달할 수 있는 overload를 갖고 있습니다.

(3) 정규 표현식 문법

아래 표는 정규표현식에서 사용할 수 있는 일반적인 기호문자를 정리한 것입니다.

기호	의미	기호	의미
^	시작값	$	끝값
\d	숫자	\D	비숫자
\s	공백	\S	비공백
\W	단어 문자	\W	비단어 문자
[A-Za-z0-9]	문자의 범위	\^	^(caret) 문자
[aeiou]	가능한 문자집합	[^aeiou]	비가능한 문자집합
.	모든 단일문자	\.	.(dot) 문자

추가적으로 아래는 정규표현식에서 이전 기호에 영향을 주는 일부 정규표현식 한정자를 정리한 것입니다.

기호	의미	기호	의미
+	하나 또는 그 이상	?	하나 아니면 없음
{3}	정확히 3개	{3,5}	3~5
{3,}	최소3개	{,3}	3이상

(4) 정규 표현식 예제

아래 표에서는 정규식을 통한 몇 가지 예를 나타내고 있습니다.

표현식	의미
\d	한자리 숫자
a	문자 a
cliel	단어 cliel
^cliel	cliel로 시작하는 단어
cliel$	cliel로 끝나는 단어
^\d{2}$	정확히 2자리 숫자
^[0-9]{2}$	위와 동일, 정확히 2자리 숫자
^[A-Z]{4,}$	ASCII 문자 set에서의 최소 4개의 영문 대문자
^[A-Za-z]{4,}$	ASCII 문자 set에서의 최소 4개의 영문 대소문자
^[A-Z]{2}\d{3}$	ASCII 문자 set에서의 2개 대문자와 3개의 숫자
^[A-Za-z\u00c0-\ u017e]+$	ASCII 문자 set에서의 최소 1개의 대소문자 혹은 Unicode 문자 set에서의 European 문자
^d.g$	문자 d로 시작, 모든 문자, g로 끝나는 경우이므로 dig, dog처럼 d와 g사이에 단일문자
^d\.g$	문자 d로 시작, ., g로 끝나는 경우이므로 d.g에서만 일치

정규표현식은 거의 공통이므로 한번 사용한 정규표현식은 JavaScript나 Python과 같은 다른 언어에서 재사용이 가능합니다.

(5) 쉼표(,)로 구분된 문자열의 분리

위의 '문자열 분리'에서는 comma(,)로 구분된 문자열 변수에서 문자열을 어떻게 분리할 수 있을지에 대한 예제를 만들어본 바 있습니다. 그런데 아래와 같은 경우는 위에서 처럼 단순하게 처리할 수는 없는 형태입니다.

"aaa,bbb","ccc,ddd","eee,fff"

위 문자열값은 각각에서 큰따옴표(")를 사용하고 있으며 해당 값들은 쉼표(,)로 분리할 필요가 있는지 여부를 확인하기 위해 사용할 것입니다. 문자열 분리를 위한 Split method가 존재하지만 해당 예제에서는 맞지 않으므로 정규표현식을 대신 사용해야 합니다.

아래 link는 해당 예제를 작성하는데 영향을 받게 된 Stack Overflow의 article로서 더 자세한 설명을 확인해 볼 수 있습니다.

string문자열 안에서 큰따옴표(")를 포함시키기 위해 이들 앞에 backslash를 붙여주거나 C# 11부터 도입된 'raw string literal'을 사용할 수 있습니다.

Program.cs에서 comma로 구분된 문자열값을 저장하는 변수를 추가하고 Split method를 통해 문자열을 나누어 봅니다.

string str = """
"aaa,bbb","ccc,ddd","eee,fff"
""";

Console.WriteLine($"Strings to split: {str}");

string[] attrStr = str.Split(',');

Console.WriteLine("Splitting with string.Split method:");
foreach (string s in attrStr)
{
	Console.WriteLine(s);
}

그다음 해당 문자열을 다시 정규표현식을 통해 나누는 문을 아래와 같이 작성합니다.

Regex csv = new("(?:^|,)(?=[^\"]|(\")?)\"?((?(1)[^\"]*|[^,\"]*))\"?(?=,|$)");
MatchCollection colStr = csv.Matches(str);

Console.WriteLine("Splitting with regular expression:");
foreach (Match s in colStr)
{
	Console.WriteLine(s.Groups[2].Value);
}

예제를 실행하면 다음과 같은 결과를 볼 수 있을 것입니다.

(6) 정규표현식 구문강조 사용하기

Visual Studio 2022를 사용한다면 위에서 정규표현식을 사용하고자 생성자값으로 문자열을 전달할 때 색상으로 구문이 강조되어 있음을 확인할 수 있습니다.

일반적인 문자열값을 처리할 때 적용되지 않던 색상 구문 강조가 정규 표현식을 사용할 때 적용된 이유는 무엇일까?

그 이유를 알아보기 위해 생성자에서 mouse오른쪽 button을 click 한 뒤 'Go To Implementation'항목을 선택합니다. 그러면 pattern 문자열 매개변수에 Regex 상수값이 전달된 StringSyntax 이름의 attribute가 적용되어 있음을 알 수 있습니다.

/// <summary>
/// Creates a regular expression object for the specified regular expression.
/// </summary>
public Regex([StringSyntax(StringSyntaxAttribute.Regex)] string pattern) :
this(pattern, culture: null)
{
}

여기서 다시 StringSyntax attribute에 mouse오른쪽 click한뒤 'Go To Implementation'항목을 선택합니다. 결과를 보면 Regex를 포함해 선택가능한 12개의 인식된 문자열 구문형식이 존재함을 알 수 있습니다.

public const string CompositeFormat = nameof(CompositeFormat);

/// <summary>The syntax identifier for strings containing date format specifiers.</summary>
public const string DateOnlyFormat = nameof(DateOnlyFormat);

/// <summary>The syntax identifier for strings containing date and time format specifiers.</summary>
public const string DateTimeFormat = nameof(DateTimeFormat);

/// <summary>The syntax identifier for strings containing <see cref="Enum"/> format specifiers.</summary>
public const string EnumFormat = nameof(EnumFormat);

/// <summary>The syntax identifier for strings containing <see cref="Guid"/> format specifiers.</summary>
public const string GuidFormat = nameof(GuidFormat);

/// <summary>The syntax identifier for strings containing JavaScript Object Notation (JSON).</summary>
public const string Json = nameof(Json);

/// <summary>The syntax identifier for strings containing numeric format specifiers.</summary>
public const string NumericFormat = nameof(NumericFormat);

/// <summary>The syntax identifier for strings containing regular expressions.</summary>
public const string Regex = nameof(Regex);

/// <summary>The syntax identifier for strings containing time format specifiers.</summary>
public const string TimeOnlyFormat = nameof(TimeOnlyFormat);

/// <summary>The syntax identifier for strings containing <see cref="TimeSpan"/> format specifiers.</summary>
public const string TimeSpanFormat = nameof(TimeSpanFormat);

/// <summary>The syntax identifier for strings containing URIs.</summary>
public const string Uri = nameof(Uri);

/// <summary>The syntax identifier for strings containing XML.</summary>
public const string Xml = nameof(Xml);

WorkingWithRegularExpressions project에서 Strings. cs라는 이름의 class file을 추가한 뒤 2개의 문자열 상수를 정의하는 문을 작성합니다.

partial class Program
{
	const string digitsOnlyText = @"^\d+$";
	const string commaSeparatorText = "(?:^|,)(?=[^\"]|(\")?)\"?((?(1)[^\"]*|[^,\"]*))\"?(?=,|$)";
}

Visual Studio 2022에서 위 예제를 작성하면 아직까지는 정규식에 색상 구문 강조가 적용되지 않습니다.

Program.cs에서 literal string을 아래와 같이 digits-only 정규 표현식에 대한 string constant로 바꾸고

Regex ageChecker = new(digitsOnlyText);

WorkingWithText project의 comma 분리 정규표현식에서도 아래와 같이 string constant로 바꾸어 줍니다.

Regex csv = new(commaSeparatorText);

Strings.cs에서는 StringSyntax attribute를 위한 namespace를 추가하고 string상수 둘다에 StringSyntax attribute를 적용합니다.

partial class Program
{
	[StringSyntax(StringSyntaxAttribute.Regex)]
	const string digitsOnlyText = @"^\d+$";

	[StringSyntax(StringSyntaxAttribute.Regex)]
	const string commaSeparatorText = "(?:^|,)(?=[^\"]|(\")?)\"?((?(1)[^\"]*|[^,\"]*))\"?(?=,|$)";
}

이어서 날짜의 서식화를 위한 또 다른 상수를 아래와 같이 추가하고

[StringSyntax(StringSyntaxAttribute.DateTimeFormat)]
const string fullDateTime = "";

fullDateTime문자열 안에 'd'를 typing 하면 IntelliSense가 작동됨을 알 수 있습니다.

fullDateTime변수에 'yyyy-MM-dd'형식의 날짜 format을 지정하고 digitsOnlyText의 끝에는 \문자를 추가합니다. 이때 IntelliSense를 통해 올바른 정규표현식을 입력하는데 도움을 받을 수 있습니다.

[StringSyntax] attribute는 .NET 7에서 새롭게 도입된 기능으로 이를 인식하는 것은 code editor의 몫입니다. .NET 7에는 이뿐만 아니라 해당 attribute에 적용할 수 있는 350개 이상의 매개변수, 속성, field를 갖고 있습니다.

(7) Source generator를 통한 정규표현식의 성능향상

문자열값 혹은 문자열상수를 Regex의 생성자로 전달하면 class는 문자열을 분석하여 정규표현식 번역기에 의해 효휼적으로 실행될 수 있도록 최적화된 방식으로 표현식을 나타내는 내부 tree구조로 변환합니다.

정규 표현식은 RegexOption을 지정함으로써 아래와 같이 compile 할 수 있습니다.

Regex ageChecker = new(digitsOnlyText, RegexOptions.Compiled);

그런데 compiling은 정규표현식의 초기생성 속도를 늦추는 부정적인 효과를 가지고 있습니다. 번역기가 실행할 tree구조가 생성되고 나면 compiler는 이 tree를 IL code로 변환하고 IL code를 native code로 JIT compile 해야 합니다. 정규표현식을 몇 번만 실행시킬 거라면 이것을 굳이 compile 할 필요가 없을 것입니다.

.NET 7에서는 [GeneratedRegex] attribute를 Regex를 반환하는 partial method에 적용하면 이를 인식하는 정규표현식에 대한 source generator를 도입하였는데 이는 정규표현식에 대한 logic을 구현하는 method의 구현을 생성합니다.

WorkingWithRegularExpressions project에서 Regexs.cs라는 새로운 class file을 생성하고 아래와 같이 partial method를 정의합니다.

partial class Program
{
    [GeneratedRegex(digitsOnlyText, RegexOptions.IgnoreCase)]
    private static partial Regex DigitsOnly();
    [GeneratedRegex(commaSeparatorText, RegexOptions.IgnoreCase)]
    private static partial Regex CommaSeparator();
}

그리고 Program.cs에서 아래와 같이 digits-only 정규표현식을 반환하는 partial method를 호출하도록 생성자를 바꿔주고

Regex ageChecker = DigitsOnly();

comma 구분자 정규 표현식을 반환하는 partial method를 호출하도록 하는 생성자도 아래와 같이 바꿔줍니다.

Regex csv = CommaSeparator();

여기에서 각 partial method에 mouse pointer를 올려보면 표현식에 대한 동작을 설명하는 tooltip을 볼 수 있습니다.

그리고 DigitsOnly partial method를 mouse 오른쪽 click 하여 'Go To Definition'을 click 해 보면 자동으로 생성된 partial method의 구현체를 확인해 볼 수 있습니다.

예제를 실행하고 기존의 동작과 같은지를 확인합니다.

아래 link에서는 .NET 7에서 정규 표현식의 구현에 대한 더 많은 내용을 확인할 수 있습니다.

Regular Expression Improvements in .NET 7 - .NET Blog (microsoft.com)

Regular Expression Improvements in .NET 7 - .NET Blog

System.Text.RegularExpressions has improved significantly in .NET 7. In this post, we'll deep-dive into many of its exciting improvements.

devblogs.microsoft.com

4. Collection에서 다중 개체 저장하기

Data와 관련된 또 다른 가장 일반적인 type으로는 collection을 들 수 있습니다. Collection은 다중값을 저장하는 일반적인 type입니다.

Collection은 memory에 있는 data구조로서 모든 collection이 일부 기능을 공유하고 있기는 하지만 나름대로의 방식으로 다중 item을 관리할 수 있습니다.

아래 표는 .NET에서 collection을 사용하기 위한 가장 일반적인 type을 나타낸 것입니다.

Namespace	Example type(s)	Description
System.Collections	IEnumerable, IEnumerable<T>	Collection에서 사용되는 Interface와 기반 class
System.Collections.Generic	List<T>, Dectionary<T>, Queue<T>, Stack<T>	.NET Framework 2.0과 함께 C# 2.0에서 도입된 것으로 generic type 매개변수를 통해 원하는 type을 지정할 수 있는 collection (더 안전하고, 더 빠르며, 더 효휼적인)
System.Collections.Concurrent	BlockingCollection, ConcurrentDictionary, ConcurrentQueue	Multithread scenario에서 사용하기에 안전한 collection
System.Collections.Immutable	ImmutableArray, ImmutableDictionary, ImmutableList, ImmutableQueue	본래 collection의 content가 절대 바뀌지 않는다는 scenario를 위해 설계된 것으로 다만 새로운 instance를 생성함으로서 기존의 collection을 변경할 수 있음

(1) 모든 collection에서의 공통기능

모든 collection은 ICollection interface를 구현하고 있고 때문에 얼마나 많은 개체가 존재하는지를 의미하는 Count속성을 가지고 있습니다.

public interface ICollection : IEnumerable
{
	int Count { get; }
	bool IsSynchronized { get; }
	object SyncRoot { get; }
	void CopyTo(Array array, int index);
}

예를 들어 한 학급의 학생에 대한 collection이 존재한다면 다음과 같이 학생의 수를 구할 수 있습니다.

int howMany = students.Count;

또한 모든 collection은 IEnumerable interface를 구현합니다. 때문에 foreach문을 통해 각 요소를 열거할 수 있습니다. 그리고 이를 위해서는 IEnumerator를 구현하는 개체를 반환하는 GetEnumerator method를 가져야 하며 반환된 개체는 collection을 탐색할 수 있는 MoveNext와 Reset method 그리고 collection에서 현재 item을 가지고 있는 Current 속성을 가져야 합니다.

public interface IEnumerable
{
	IEnumerator GetEnumerator();
}

public interface IEnumerator
{
	object Current { get; }
	bool MoveNext();
	void Reset();
}

이렇게 되면 students collection에서 각 개체에 대해 아래와 같은 동작을 수행할 수 있습니다.

foreach (Student s in students)
{

}

개체 기반 collection interface뿐만 아니라 collection에 저장되는 type을 정의하는 generic type generic interface와 class도 존재합니다.

public interface ICollection<T> : IEnumerable<T>, IEnumerable
{
    int Count { get; }
    bool IsReadOnly { get; }
    void Add(T item);
    void Clear();
    bool Contains(T item);
    void CopyTo(T[] array, int index);
    bool Remove(T item);
}

(2) Collection의 가용성을 지정하여 성능 향상하기

.NET 1.1부터 StringBuilder와 같은 type은 EnsureCapacity라는 이름의 method를 가지고 있어서 이를 통해 array를 저장하는 size를 미리 지정할 수 있었고 따라서 string의 마지막 size를 예상할 수 있었습니다. 이 것은 문자가 추가됨으로서 array의 size를 반복적으로 증가시키지 않아도 되므로 성능에 도움이 될 수 있습니다.

.NET 6부터 List<T>, Queue<T>, Stack<T>와 같은 collection은 같은 역할로 EnsureCapacity이름의 method를 가지게 되었으며 아래와 같이 사전 size를 지정할 수 있게 되었습니다.

List<string> names = new();
names.EnsureCapacity(10000);

(3) Collection의 종류

Collection은 사용하고자 하는 목적에 따라 lists, dictionaries, queues, sets 등 선택가능한 여러 가지가 존재합니다.

● Lists

IList<T>를 구현하는 List는 정렬된 collection입니다.

[DefaultMember("Item")]
public interface IList<T> : ICollection<T>, IEnumerable<T>, IEnumerable
{
    T this[int index] { get; set; }
    int IndexOf(T item);
    void Insert(int index, T item);
    void RemoveAt(int index);
}

DefaultMember attribute는 member의 이름이 지정되지 않았을 경우 기본적으로 접근될 member를 지정합니다. 따라서 만약 IndexOf를 기본 member로 지정하고자 한다면 [DefaultMember("IndexOf")]와 같이 사용할 수 있습니다. 예제에서 Item은 Indexer를 의미합니다.

IList<T>는 ICollection<T>로 부터 파생되므로 Count속성을 가지고 있으며 collection끝에 item을 추가하기 위한 Add method와 특정한 위치에 item을 추가하는 Insert method, 지정한 위치에 item을 제거하는 RemoveAt method를 가지고 있습니다.

따라서 List는 수동적으로 collection의 item 순서를 조정할 수 있습니다. List의 각 item은 자동적으로 할당된 고유한 index(또는 위치값)를 가지고 있으며 또한 T에 의해 어떠한 type으로도 item이 정의될 수 있고 필요하다면 중복으로 item을 저장시킬 수 있습니다. Index는 int type으로서 0부터 시작하므로 list의 첫 번째 item의 index값은 0이 됩니다.

Index	Item
0	apple
1	banana
2	orange

만약 위 상태에서 banana와 orange사이에 lemon이라는 새로운 item이 삽입되면 orange의 index는 자동적으로 증가됩니다. 따라서 item의 index는 다른 item의 삽입이나 제거로 인해 바뀔 수 있음에 주의해야 합니다.

Index	Item
0	apple
1	banana
2	lemon
3	orange

때로는 Array가 더 나은 상황임에도 굳이 List<T>나 다른 collection을 사용하는 경우가 있습니다. 그러나 이는 좋지 않은 습관입니다. Data의 size가 instance화 된 이후에 바뀌는 않는 경우라면 array를 사용하는 것이 좋습니다. 먕갸 data의 조작이 필요한 경우라면 처음에는 list를 사용하여 필요한 변경을 수행하고 그 다음 array로 변환하여 사용합니다.

● Dictionary

Dictionary는 각 값(또는 개체)이 고유한 하위 값을 가질 수 있으며 이는 collection에서 빠르게 값을 찾는 key로 사용될 수 있습니다. 여기서 key는 고유해야 합니다. 예를 들어 사람에 대한 list를 저장하는 경우라면 주민등록번호를 key로서 사용할 수 있을 것입니다. Dictionary는 Python과 Java와 같은 다른 언어에서는 hashmaps라고도 합니다.

Key는 실제 사전에서 index항목과 같이 생각할 수 있습니다. 단어(즉, key)는 정렬된 상태로 유지되므로 빠르게 단어의 정의를 찾을 수 있게 하며 만약 manatee단어에 대한 정의를 찾는다고 하면 사전의 중간쯤부터 시작할 수 있을 것입니다. 왜냐하면 문자 M은 alphabet의 중간쯤에 위치해 있기 때문입니다.

Programming에서 Dictionary는 무엇인가를 찾을 때 위와 비슷하게 동작할 수 있습니다. Dictionary는 IDictionary<TKey, TValue> interface를 구현합니다.

[DefaultMember("Item")] // aka this indexer
public interface IDictionary<TKey, TValue> : ICollection<KeyValuePair<TKey, TValue>>, IEnumerable<KeyValuePair<TKey, TValue>>, IEnumerable
{
    TValue this[TKey key] { get; set; }
    ICollection<TKey> Keys { get; }
    ICollection<TValue> Values { get; }
    void Add(TKey key, TValue value);
    bool ContainsKey(TKey key);
    bool Remove(TKey key);
    bool TryGetValue(TKey key, [MaybeNullWhen(false)] out TValue value);
}

Dictionary의 item은 값 type인 KeyValuePair<TKey, TValue> struct의 instance로서 TKey는 key의 type이며 TValue는 value의 type입니다.

public readonly struct KeyValuePair<TKey, TValue>
{
    public KeyValuePair(TKey key, TValue value);
    public TKey Key { get; }
    public TValue Value { get; }
    
    [EditorBrowsable(EditorBrowsableState.Never)]
    public void Deconstruct(out TKey key, out TValue value);
    public override string ToString();
}

예를 들어 Dictionary<string, Person>는 key로서 string을, 값(value)으로서 Person instance를 사용하는 것입니다. 아래 예제 Dictionary<string, string>은 값과 key로서 둘 다 string을 사용합니다.

key	value
801201-1	홍길동
750405-2	홍길남
820712-1	홍길석

● Stack

Stack는 LIFO(last-in, first-out) 동작을 구현하기에 적합합니다. 따라서 stack에서는 전체 item을 열거할 수는 있지만 stack의 가장 상위에 있는 하나의 item에 대한 직접적인 접근 및 제거만이 가능합니다. Stack에 대한 두 번째나 세 번째 등의 접근 불가능합니다.

Stack의 가장 대표적인 사례로는 word process를 들 수 있습니다. Stack을 통해 우리가 한 동작을 순서대로 기억하고 있다가 Ctrl + Z key를 누르게 되면 stack에서 마지막 동작을 읽어 되돌리게 되는 것입니다.

● Queue

Queue는 FIFO(first-in, first-out)동작을 구현하기에 적합합니다. 따라서 queue에서는 전체 item을 열거할 수는 있지만 queue의 가장 앞에 있는 item에 대한 직접적인 접근및 제거만이 가능하며 두번째나 세번째등의 접근은 불가능합니다.

Queue의 가장 대표적인 사례로는 은행에서 줄을 서 있는 사람들처럼 들어온 순서대로 작업 item을 처리할 때 queue를 사용한 경우를 들 수 있습니다.

.NET 6에서는 queue의 각 item에 position과 우선순위값이 할당된 PriorityQueue를 도입하였습니다.

Program.cs에 queue를 정의하고 사용하는 일반적인 방법을 나타내는 문을 아래와 같이 추가합니다. 예제는 Queue를 통해 음식점에서 손님에게 순서대로 주문한 음식을 제공하는 경우를 나타낸 것입니다.

Queue<string> foods = new();
foods.Enqueue("제육볶음");
foods.Enqueue("된장찌개");
foods.Enqueue("김치찌개");
foods.Enqueue("백반정식");
foods.Enqueue("라면");

Output("Initial queue from front to back", foods);

string served = foods.Dequeue();
Console.WriteLine($"Served: {served}.");

served = foods.Dequeue();
Console.WriteLine($"Served: {served}.");
Output("Current queue from front to back", foods);

Console.WriteLine($"{foods.Peek()} is next in line.");
Output("Current queue from front to back", foods);

예제를 실행하면 다음과 같은 결과를 볼 수 있습니다.

Helpers.cs의 partial Program class에서 OutputPQ라는 이름의 정적 method를 아래와 같이 추가합니다.

static void OutputPQ<TElement, TPriority>(string title, IEnumerable<(TElement Element, TPriority Priority)> collection)
{
    Console.WriteLine(title);

    foreach ((TElement, TPriority) item in collection)
    {
        Console.WriteLine($" {item.Item1}: {item.Item2}");
    }
}

OutputPQ는 generic임에 주목합니다. 이를 통해 collection에 전달되는 tuple에서 사용할 2개의 type을 지정할 수 있습니다.

Program.cs에서는 priority queue를 정의하고 사용하는 일반적인 방법을 나타내는 문을 아래와 같이 추가합니다.

PriorityQueue<string, int> foods = new();
foods.Enqueue("제육볶음", 1);
foods.Enqueue("된장찌개", 4);
foods.Enqueue("김치찌개", 3);
foods.Enqueue("백반정식", 2);
foods.Enqueue("라면", 1);

OutputPQ("Initial queue from front to back", foods.UnorderedItems);
Console.WriteLine($"{foods.Dequeue()} has been served.");
Console.WriteLine($"{foods.Dequeue()} has been served.");

OutputPQ("Current queue :", foods.UnorderedItems);
Console.WriteLine($"{foods.Dequeue()} has been served.");
            
Console.WriteLine("Adding Mark to queue with priority 2");
foods.Enqueue("오무라이스", 2);

Console.WriteLine($"{foods.Peek()} will be next to be served.");
OutputPQ("Current queue :", foods.UnorderedItems);

예제에서 Enqueue method의 두 번째 숫자가 우선순위에 해당합니다. 1이 가장 높은 우선순위를 4가 가장 낮은 우선순위가 됩니다.

예제를 실행하면 다음과 같은 결과를 확인할 수 있습니다.

● Set

Set은 2개의 collection사이에 집합 연산을 수행합니다. 예를 들어 과일에 대한 2개의 collection을 가지고 있을 때 2개 collection모두에서 공통적으로 속해있는(집합 사이에 교차하는) 과일의 이름을 알고 싶은 경우 set을 사용할 수 있습니다. Set에서 item은 고유해야 합니다.

일반적으로 사용되는 Set method는 아래와 같습니다.

Add	Item이 존재하지 않는다면 새롭게 추가합니다. Method의 수행결과로 true라면 Item이 추가된 것이고 false라면 해당 Item이 이미 존재하는 경우입니다.
ExceptWith	매개변수로 전달된 set의 item을 set에서 제거합니다.
IntersectWith	매개변수로 전달된 set이 아닌 item을 set에서 제거합니다.
IsProperSubsetOf IsProperSupersetOf IsSubsetOf IsSupersetOf	Subset은 item이 모두 다른 set에 존재하는 set입니다. 적절한 subset은 item이 모두 다른 set에 존재하는 set이지만 다른 set에 없는 item이 최소 하나이상 있는 set입니다. Superset은 모든 item이 다른 set에 있는 set이고 적절한 superset은 다른 set의 모든 item과 다른 set에 존재하지 않는 하나이상의 item을 포함합니다.
Overlaps	Set와 다른 set는 하나 이상의 공통 item을 공유합니다.
SetEquals	Set와 다른 set는 정확히 같은 item을 공유합니다.
SymmetricExceptWith	매개변수로 전달된 set에 속하지 않은 item을 set에서 제거하고 누락된것을 추가합니다.
UnionWith	매개변수로 전달된 set에 아직 set에 없는 item을 추가합니다.

Set에 대한 일반적인 예제를 작성해 보기 위해 Program.cs를 아래와 같이 변경합니다.

HashSet<String> fruits = new();

foreach(string fruit in new[] { "apple", "banana", "orange", "banana" })
{
    bool result = fruits.Add(fruit);

    Console.WriteLine($"result : {result}, {fruit}");
}

예제를 실행하면 다음과 같은 결과를 표시할 것입니다.

● Collection method

각 collection은 item을 추가하거나 삭제할 때 사용하는 일련의 method가 다르며 아래 표는 collection별로 이러한 method를 정리한 것입니다.

Collection	Add method	Remove method	Description
List	Add, Insert	Remove, RemoveAt	List는 정렬되어 있으므로 item은 int형식의 index position을 갖고 있습니다. Add는 list의 끝에 새로운 item을 추가하며 Insert는 지정한 위치에 새로운 item을 추가하게 됩니다.
Dictionary	Add	Remove	Dictionary는 정렬되어 있지 않으므로 item또한 index position을 갖고 있지 않습니다. ContainsKey method를 호출하면 해당 key가 사용되었는지 여부를 확인할 수 있습니다.
Stack	Push	Pop	Push method는 새로운 item을 stack의 상위에 추가합니다. 따라서 첫번째 item은 맨 마지막에 있게 됩니다. Item이 Pop을 통해 제거될때는 stack의 가장 상위의 것이 제거됩니다. Peek method를 호출하면 해당 값을 삭제하지 않고도 확인할 수 있습니다.
Queue	Enqueue	Dequeue	Enqueue method를 통해 item이 추가될때는 항상 queue의 끝에 추가됩니다. 따라서 첫번째 item은 queue의 앞에 있게 됩니다. Dequeue method를 통해 item이 제거될때는 queue의 가장 앞에 있는 item을 제거합니다. Peek method를 호출하면 해당 값을 삭제하지 않고도 확인할 수 있습니다.

(4) List 사용하기

csStudy08 solution에서 WorkingWithCollections이름의 Console App project를 추가하고 Helpers.cs class를 아래와 같이 추가합니다.

partial class Program
{
    static void Output(string title, IEnumerable<string> collection)
    {
        Console.WriteLine(title);

        foreach (string item in collection)
        {
            Console.WriteLine($" {item}");
        }
    }
}

Program.cs에서는 기존의 문을 모두 삭제하고 list를 정의하고 사용하는 일반적인 방법을 나타내는 문을 아래와 같이 추가합니다.

List<string> cities = new();
cities.Add("Daegu");
cities.Add("Seoul");
cities.Add("Busan");

Output("Initial list", cities);
Console.WriteLine($"The first city is {cities[0]}.");
Console.WriteLine($"The last city is {cities[cities.Count - 1]}.");
            
cities.Insert(0, "Jeju");
Output("After inserting Sydney at index 0", cities);

cities.RemoveAt(1);
cities.Remove("Seoul");
Output("After removing two cities", cities);

예제에서 cities list는 아래 2가지 다른 방식으로도 정의될 수 있습니다.

List<string> cities = new() { "London", "Paris", "Milan" };

List<string> cities = new();
cities.AddRange(new[] { "London", "Paris", "Milan" });

예제를 실행하면 다음과 같은 결과가 표시될 것입니다.

(5) Dictionary 사용하기

Program.cs에서는 Dictionary를 정의하고 사용하며 단어를 찾는 등의 일반적인 방법을 나타내는 문을 아래와 같이 추가합니다.

Dictionary<string, string> keywords = new();

keywords.Add(key: "int", value: "32-bit integer data type");
keywords.Add("long", "64-bit integer data type");
keywords.Add("float", "Single precision floating point number");

Output("Dictionary keys:", keywords.Keys);
Output("Dictionary values:", keywords.Values);

Console.WriteLine("Keywords and their definitions");
foreach (KeyValuePair<string, string> item in keywords)
{
    Console.WriteLine($" {item.Key}: {item.Value}");
}

string key = "long";
Console.WriteLine($"The definition of {key} is {keywords[key]}");

예제에서 첫 번째 Add method는 명명된 매개변수를 사용한 추가방식을 나타내고 있습니다. 또한 Dictionary는 아래와 같은 2가지 다른 방식을 통해 정의될 수 있습니다.

Dictionary<string, string> keywords = new()
{
    { "int", "32-bit integer data type" },
    { "long", "64-bit integer data type" },
    { "float", "Single precision floating point number" },
};

Dictionary<string, string> keywords = new()
{
    ["int"] = "32-bit integer data type",
    ["long"] = "64-bit integer data type",
    ["float"] = "Single precision floating point number",
};

특히 상기예제에서 마지막 comma(,)는 생략할 수 있습니다.

(6) Collection 정렬

List<T> class에서는 Sort method를 호출함으로써 수동적으로 정렬할 수 있습니다(단, 각 item의 index는 바뀔 수 있습니다.). 문자열값 혹은 다른 내장 type의 list를 수동적으로 정렬하는 것은 별도의 구현이 필요 없이 작업이 가능하지만 자신만의 type으로 collection을 생성한 경우라면 해당 type은 IComparable이름의 interface를 구현해야 합니다. 이에 대한 자세한 내용은 아래 글에서 확인하실 수 있습니다.

[.NET/C#] - [C# 12와 .NET 8] 6. Interface와 Class상속

[C# 12와 .NET 8] 6. Interface와 Class상속

lab.cliel.com

Stack<T>또는 Queue<T> collection은 근본적인 특성상 정렬이 불가능하며 Dictionary 혹은 set에서는 정렬이 가능할 수 있습니다.

하지만 때로는 자동적으로 정렬된 collection, 즉, item을 추가하거나 삭제하면 그것대로 순서대로 정렬된 item을 유지하는 것을 사용하는 것이 유용할 때가 있습니다.

이를 위해 선택가능한 여러 자동정렬 collection들이 존재합니다. 이들 정렬된 collection의 차이는 미묘하지만 application에서 사용될 때 필요한 memory와 성능에는 큰 영향이 있을 수 있습니다. 따라서 필요에 따라 가장 적합한 것을 선택할 수 있도록 신중해질 필요가 있습니다.

선택가능한 자동정렬 collection에는 다음과 같은 것들이 있습니다.

Collection	설명
SortedDictionary<TKey, TValue>	key에 의해 정렬된 key/값 쌍의 collection입니다.
SortedList<TKey, TValue>	key에 의해 정렬된 key/값 쌍의 collection입니다. SortedDictionary<TKey, TValue>와 비교하여 열거하는 성능은 비슷하지만 더 적은 memory를 사용하며 정렬되어 있지 않은 상태에서는 insert나 remove동작은 느리지만 정렬되어 있다면 더 빠르게 동작합니다.
SortedSet<T>	순서대로 정렬된 상태를 유지하는 고유한 개체의 collection입니다.

(7) 더 전문화된 collection

위의 collection 외 더 특별한 상황을 위한 다른 collection들이 존재합니다.

● Bit 값을 사용하는 compact array

System.Collections.BitArray collection은 bool형식의 bit값에 대한 array를 관리하며 true라면(값이 1이라면) bit가 on이고 false라면(값이 0이라면) bit가 off임을 의미합니다.

● Efficient list

System.Collections.Generics.LinkedList<T> collection은 이중연결 list를 나타내는 것으로 모든 item은 전의 item과 후의 item에 대한 참조를 갖고 있습니다. 이러한 구조로 list의 중간쯤에 자주 item에 대한 insert나 remove가 이루어지는 상황이라면 List<T>와 비교해 더 우월한 성능을 나타내며 구조의 특성상 LinkedList<T>에서 item은 memory에서 재정렬될 필요가 없습니다.

(8) Read-only , Immutable, frozen collection

Generic collection interface를 보면 IsReadOnly라는 속성이 존재함을 알 수 있습니다. 이 속성은 method에 collection을 전달할때 해당 collection에 어떠한 변경도 허용하지 말아야 할 경우 유용하게 사용할 수 있습니다.

List<T>와 Dictionary<TKey, TValue>와 같은 collection는 AsReadOnly method를 갖고 있는데 이를 통해 본래 collection을 참조하는 ReadOnlyCollection<T>를 생성하게 됩니다. ReadOnlyCollection<T>도 ICollection<T> interface를 구현하고 있기 때문에 Add나 Remove와 같은 method를 갖고 있지만 해당 method의 호출을 시도하면 NotImplementedException을 throw하게 됩니다. ReadOnlyCollection<T>는 참조이므로 본래 collection에서 item의 추가나 삭제와 같은 변경사항이 발생하면 당연히 ReadOnlyCollection<T>에도 그대로 변경사항이 적용됩니다.

Console.OutputEncoding = System.Text.Encoding.UTF8;

void UseDictionary(IDictionary<string, string> dictionary)
{
    try
    {
        dictionary.Add(key: "A7", value: "홍길석"); 
    }
    catch (NotSupportedException)
    {
        Console.WriteLine("collection이 읽기 전용임.(item을 추가할 수 없음).");
    }
    
    Console.WriteLine($"전체 요소 수 : {dictionary.Count}");
}

Dictionary<string, string> employees = new Dictionary<string, string>();
employees.Add("A1", "홍길순");
employees.Add("A2", "홍길동");
employees.Add("A3", "홍길영");

UseDictionary(employees);

위 예제에서는 method에서 dicttionary type을 전달받아 새로운 item을 추가하도록 합니다.

method에서는 IDictionary type의 인수가 정의되어 있습니다. 특정 type보다 interface를 사용하면 program에 더 많은 유연성을 부여할 수 있습니다. 예제에서도 IDictionary interface를 사용해 Dictionary<TKey, TValue>나 ReadOnlyDictionary<TKey, TValue>등 해당 interface를 구현한 모든 type을 잔달받을 수 있습니다.

예제를 실행하면 method안에서 정상적으로 item을 추가하게 되었으므로 Count의 수는 늘어나게 됩니다.

이번에는 AsReadOnly method를 통해 읽기전용 collection을 전달해 봅니다.

UseDictionary(employees.AsReadOnly());

실행결과는 다음과 같습니다.

method에서는 item을 추가할 수 없기 때문에 결과에서의 Count값은 기존과 동일합니다.

Immutable collection은 말 그대로 불변의 collection을 생성합니다. 다시 말해 collection의 member는 바뀔 수 없고 따라서 추가나 삭제도 불가능합니다.

Immutable collection은 System.Collections.Immutable namespace를 import 하게 되면 IEnumerable<T>를 구현하는 모든 collection은 여섯 개의 확장 method가 주어지는데 이를 통해 immutable list나 dictionary, hash, set 등으로 변환하는 것으로 사용할 수 있습니다.

WorkingWithCollections의 Program.cs에서 System.Collections.Immutable namespace를 import 하고 cities list를 immutable list로 변환한 뒤 새로운 item을 아래와 같이 추가하도록 합니다.

List<string> cities = new();
cities.Add("Daegu");
cities.Add("Seoul");
cities.Add("Busan");

ImmutableList<string> immutableCities = cities.ToImmutableList();
ImmutableList<string> newList = immutableCities.Add("Jeju");
Output("Immutable list of cities:", immutableCities);
Output("New list of cities:", newList);

예제를 실행하면 다음과 같은 결과를 볼 수 있습니다.

예제에서 cities의 immutable list는 바뀌지 않음에 주목해야 합니다. Add method를 통해 item을 추가하게 되면 자신을 바꾸는 것이 아닌 기존의 것에서 새로운 것이 추가된 상태의 list가 새롭게 반환됩니다.

성능향상을 위해 많은 application에서는 공통적으로 접근되는 개체의 공유복사본을 cache에 복사하고 여러 thread에서의 안정적인 동작이 필요한 경우 이를 immutable로 만들거나 concurrent collection type을 사용하게 됩니다. 이와 관련해서는 아래 link에서 자세한 내용을 확인할 수 있습니다.

System.Collections.Concurrent Namespace | Microsoft Learn

System.Collections.Concurrent Namespace

Provides several thread-safe collection classes that should be used in place of the corresponding types in the System.Collections and System.Collections.Generic namespaces whenever multiple threads are accessing the collection concurrently. However, access

learn.microsoft.com

Generic collection은 설계된 방식으로 인해 잠재먹인 성능 issue를 갖고 있습니다.

첫번째로는 dictionary에서 key와 값에 사용되는 type이 어떤 것이냐에 따라 성능에 큰 영향을 준다는 것입니다. 거의 모든 type을 다 받아들일 수 있기 때문에 사실상 성능을 최적화하게에는 무리가 있었던 것입니다. 실세 여기에 사용되는 type은 string과 int가 가장 흔한데 만약 .NET team이 type을 이것으로만 한정하게 된다면 아마도 최적화가 가능했을 것입니다.

두번째로 collection은 동적입니다. 이는 collection에 새로운 item이 언제든지 추가될 수 있고, 또 언제든지 제거될 수 있다는 것을 의미합니다. Collection이 더이상 변경되지 않는다는것을 보장할 수 있다면 이 역시 최적화가 가능한 부분이기도 합니다.

이에 따라 .NET 8에서는 frozen collection이라는 새로운 개념을 도입하게 되었습니다. 현재 frozen collection은 향후에 더 추가될 수 있지만 FrozenDictionary<TKey, TValue>와 FrozenSet<T>가 존재합니다.

using System.Collections.Frozen;

Console.OutputEncoding = System.Text.Encoding.UTF8;

Dictionary<string, string> employees = new Dictionary<string, string>();
employees.Add("A1", "홍길순");
employees.Add("A2", "홍길동");
employees.Add("A3", "홍길영");

FrozenDictionary<string, string> frozenEmployee = employees.ToFrozenDictionary();

foreach(var item in frozenEmployee)
{
    Console.WriteLine(item.Key + ":" + item.Value);
}

위 예제는 기존 employees dictionary를 frozen dictionary로 변환한 뒤 각 item을 표시하도록 합니다.

지금까지의 내용에 따라 Add method의 동작은 type에 따라 달라진다는 것을 알 수 있습니다.

List<T> : 새로운 item은 list의 끝에 추가합니다.
Dictionary<TKey, TValue> : 새로운 item은 내부구조에 따라 결정된 위치에 추가합니다.
ReadOnlyCollection<T> : item추가가 지원되지 않으며 추가를 시도하는 경우 예외를 발생시키게 됩니다.
ImmutableList<T> : 새로 추가된 item을 포함한 새로운 list를 반환합니다. 본래 list에는 영향을 주지 않습니다.
ImmutableDictionary<TKey, TValue> : 새로 추가된 item을 포함한 새로운 list를 반환합니다. 본래 list에는 영향을 주지 않습니다.
FrozenDictionary<TKey, TValue> : 해당 method가 존재하지 않습니다.

frozen collection에 관한 더 많은 정보는 아래 link를 참고하시기 바랍니다.

System.Collections.Frozen Namespace | Microsoft Learn

System.Collections.Frozen Namespace

Explore all classes and interfaces of the System.Collections.Frozen namespace.

learn.microsoft.com

(9) Collection 표현식을 사용한 초기화

C# 11이전에는 collection, array, span등을 초기화 할때 int형인 경우 다음과 같은 방식을 사용했었습니다.

int[] myArray = { 1, 2, 3 };
List<int> MyList = new() { 1, 2, 3 };
Span<int> MyySpan = stackalloc int[] { 1, 2, 3 };

이것을 C# 12부터는 collection, array, span등을 초기화 할 수 있는 새로운 문법을 도입하게 되어 대괄호를 사용한 일관성있는 초기화가 가능해쪘습니다.

int[] myArray = [ 1, 2, 3 ];
List<int> MyList =  [ 1, 2, 3 ];
Span<int> MyySpan = [ 1, 2, 3 ];

(10) Collection에 대한 모범사례

Collection을 처리해야 하는 method를 만들어야 한다고 가정해 보면 예를 들어 최대한의 유용성을 활용하기 위해 입력 매개변수를 IEnumerable<T>로 선언하여 method를 generic으로 만들 수 있습니다.

void ProcessCollection<T>(IEnumerable<T> collection)
{
}

이렇게 하면 여기에 int나 string 또는 사용자 type 등 IEnumerable<T>를 구현하는 다른 모든 type을 포함하는 list, queue, stack과 같은 array를 전달할 수 있습니다. 그러나 해당 method로 모든 collection을 전달하고자 하는 이런 유연성은 꽤 많은 처리비용을 요구할 수 있습니다.

IEnumerable<T>로 하면 이에 대한 성능저하의 문제점으로 개체를 heap에 할당해야 하는 것으로 기인합니다. 이러한 memory할당을 피하려면 위의 method에서 아래와 같이 구체적인 type을 명시해야 합니다.

void ProcessCollection<T>(List<T> collection)
{

}

이렇게 하면 IEnumerator<T>에서 참조 type을 반환하는 GetEnumerator method대신 구조체를 반환하는 List<T>의 GetEnumerator method를 사용하게 됩니다. 이것만으로 2~3배 정도의 성능상향을 기대할 수 있으며 그만큼 memory로 더 적게 사용합니다. 성능과 관련된 다른 모든 권장사항들이 그렇듯이 실제 code를 test 함으로써 성능에 관한 이점을 확인해야 합니다.

5. Span, Index 그리고 range

.NET Core 2.1에서 Microsoft의 목표 중 하나는 성능 및 resource의 사용을 개선하는 것이었으며 이에 대한 핵심 .NET 기능이 Span<T> type입니다.

(1) Span을 통한 memory 효율성 증가

Array를 다룰 때 어떤 경우에는 기존의 것에서 일부만 따로 떼어낸 새로운 복사본이 필요할 때가 있습니다. 그런데 실제 이와 같은 복사본을 생성하는 것은 memory안에 동일한 같은 개체를 만들게 되므로 그리 효휼적이라고 할 수는 없습니다.

따라서 만약 기존 array에서 전체 혹은 부분적으로 동일한 array를 대신 사용해야 한다면 본래 array에 대한 거울과 같은 span을 사용할 수 있습니다. Memory사용율과 성능면에서 더 효율적인 span은 오로지 array에 대해서만 사용할 수 있으며 memory가 연속되어야 하므로 collection에서는 사용할 수 없습니다.

(2) Index type을 통한 위치 식별

C# 8.0에서는 array안에서 item의 위치와 2개의 index를 사용해 item의 범위를 식별하기 위한 2가지 기능을 도입했습니다.

list의 개체는 indexer에 int값을 전달함으로써 다음과 같이 접근할 수 있습니다.

int index = 3;
Person p = people[index];
char letter = name[index];

Index type은 아래와 같이 사용할 수 있으며 position을 식별하기 위한 공식적인 방법이고 또한 아래와 같이 끝에서부터 계산할 수 있는 fromEnd를 사용할 수 있습니다.

Index i1 = new(value: 3);
Index i2 = 3;

Index i3 = new(value: 5, fromEnd: true);
Index i4 = ^5;

index를 정의하기 위해서 예제와 같이 명시적으로 숫자를 사용하거나 new(value: 3)과 같이 사용할 수 있습니다. 이때 index는 시작부터 3번째를 의미합니다.

끝에서 부터 counting 되도록 하는 경우 fromEnd를 사용하거나 ^(caret) 문자를 사용합니다.

(3) Range type으로 범위 식별하기

Range type은 범위의 시작과 끝을 나타내기 위해 Index값을 사용하며 생성자 혹은 정적 method를 사용해 생성합니다.

Range r1 = new(start: new Index(3), end: new Index(7));
Range r2 = new(start: 3, end: 7);
Range r3 = 3..7;
Range r4 = Range.StartAt(3);
Range r5 = 3..;
Range r6 = Range.EndAt(3); 
Range r7 = ..3;

기본적으로 range type은 위 예제에서 첫 번째와 두 번째같이 생성자를 통해 생성할 수 있습니다. 세 번째는 C# 8부터 사용가능한 방식이며 네번째는 정적 method를 사용한 것으로 세번째 index부터 끝까지를 의미합니다. 다섯번째는 네번째와 의미가 같고 여섯번째는 끝에서 부터 세번째 index를 의미합니다. 일곱 번째는 여섯 번째와 같습니다.

확장 method는 문자열값(내부적으로 char 배열을 사용), int array 그리고 span에 추가되어 범위를 더 쉽게 다룰 수 있습니다. 이들 확장 method는 매개변수로 범위를 수용하고 Span<T>를 반환함으로써 memory를 더 효휼적으로 사용할 수 있도록 합니다.

(4) Indexe, range, 그리고 span사용하기

Span을 반환하는 index와 range는 아래와 같이 사용할 수 있습니다.

csStudy08 solution에서 WorkingWithRanges이름의 Console app project를 생성하고 Program.cs에서 기존의 문을 모두 삭제한 뒤 string type의 substring method에서 범위를 지정하여 이름을 추출하고 비교하는 문을 추가합니다.

string name = "Gildong hong";

//성과 이름의 길이를 확인합니다.
int lengthOfFirst = name.IndexOf(' ');
int lengthOfLast = name.Length - lengthOfFirst - 1;

//성과 이름을 분리해 가져옵니다.
string firstName = name.Substring(startIndex: 0, length: lengthOfFirst);
string lastName = name.Substring(startIndex: name.Length - lengthOfLast, length: lengthOfLast);

Console.WriteLine($"First name: {firstName}, Last name: {lastName}");

위의 예제를 span을 사용해 구현하면 다음과 같이 할 수 있습니다.

ReadOnlySpan<char> nameAsSpan = name.AsSpan();
ReadOnlySpan<char> firstNameSpan = nameAsSpan[0..lengthOfFirst];
ReadOnlySpan<char> lastNameSpan = nameAsSpan[^lengthOfLast..^0];

Console.WriteLine("First name: {0}, Last name: {1}", arg0: firstNameSpan.ToString(), arg1: lastNameSpan.ToString());

예제를 실행하면 결과를 다음과 같을 것입니다.

5. Network Resource

외부와의 통신이 필요한 application이라면 network와 관련된 여러 가지 작업이 필요합니다. 아래 표는 그런 경우 사용가능한 type을 나열한 것입니다.

Namespace	Type	Description
System.Net	Dns, Uri, Cookie, WebClient, IPAddress	DNS server, URIs, IP address관련및 기타
System.Net	FtpStatusCode, FtpWebRequest, FtpWebResponse	FTP server 관련
System.Net	HttpStatusCode, HttpWebRequest, HttpWebResponse	HTTP server와 관련된 것으로서 website와 service등을 의미
System.Net.Http	HttpClient, HttpMethod, HttpRequestMessage, HttpResponseMessage	HTTP server와 관련된 것으로서 website와 service등을 의미
System.Net.Mail	Attachment, MailAddress, MailMessage, SmtpClient	Mail을 발송하는 SMTP server관련
System.Net .NetworkInformation	IPStatus, NetworkChange, Ping, TcpStatistics	저수준 network protocol관련

(1) URI, DNS, IP 주소

Network resource를 사용하는 예를 작성하기 위해 csStudy08 solution에서 WorkingWithNetworkResources이름의 Console App을 생성하고 Program.cs에서 기존의 문을 모두 삭제한 뒤 아래의 namespace를 import 합니다.

using System.Net;

그리고 Program.cs에서 사용자에게 website주소의 입력을 요청하고 주소가 입력되면 Uri type을 사용해 해당 주소를 HTTP, FTP 등의 scheme, port 번호, host 등 각각의 요소로 분해하는 문을 아래와 같이 추가합니다.

Console.Write("Enter a valid web address (or press Enter): ");

string? url = Console.ReadLine();
if (string.IsNullOrWhiteSpace(url))
{
    url = "http://cliel.com/";
}

Uri uri = new(url);
Console.WriteLine($"URL: {url}");
Console.WriteLine($"Scheme: {uri.Scheme}");
Console.WriteLine($"Port: {uri.Port}");
Console.WriteLine($"Host: {uri.Host}");
Console.WriteLine($"Path: {uri.AbsolutePath}");
Console.WriteLine($"Query: {uri.Query}");

예제를 실행하고 정확한 website주소를 입력하게 되면 아래와 같은 결과를 확인할 수 있습니다.

이어서 입력된 website주소에 대한 ip를 확인할 수 있는 문을 추가합니다.

IPHostEntry entry = Dns.GetHostEntry(uri.Host);
Console.WriteLine($"{entry.HostName} has the following IP addresses:");
foreach (IPAddress address in entry.AddressList)
{
    Console.WriteLine($" {address} ({address.AddressFamily})");
}

예제를 실행하고 정확한 website주소를 입력하면 다음의 결과를 표시할 것입니다.

(2) Server로 ping 보내기

위 예제에서 입력된 website주소의 web server 상태는 ping응답을 받음으로써 확인할 수 있습니다. Program.cs에서 이를 구현하기 위한 code를 아래와 같이 추가합니다.

Console.WriteLine($"Host: {uri.Host}");

Ping ping = new();
Console.WriteLine("Pinging server. Please wait...");

PingReply reply = ping.Send(uri.Host);
Console.WriteLine($"{uri.Host} was pinged and replied: {reply.Status}.");

if (reply.Status == IPStatus.Success)
{
    Console.WriteLine("Reply from {0} took {1:N0}ms", arg0: reply.Address, arg1: reply.RoundtripTime);
}

예제를 실행하고 정확한 website주소를 입력해 보면 다음의 결과를 표시할 것입니다.

[C# 12와 .NET 8] 7. .NET Packaging과 배포

클리엘 — Tue, 20 Feb 2024 09:11:50 +0900

C# 키워드가 .NET 유형과 어떻게 관련되어 있는지, 네임스페이스와 어셈블리 간에는 어떤 관계가 있는지에 대한 것을 알면 C#언어를 이해하는데 도움이 될 수 있습니다. 또한 .NET library에서 이전 .NET framework library를 어떻게 사용하고 이식할 수 있는지의 여부도 함께 알아볼 것이며 이를 통해 .NET을 좀더 폭넓게 활용할 수 있을 것입니다.

1. .NET 8

.NET에서는 Base Class Library (BCL) API를 통해 수 많은 기능들을 제공하고 있습니다. .NET Standard를 통해서는 다른 전체 .NET platform간 이런 기능들을 재사용할 수 있도록 하고 있는데 때문에 지금의 .NET과 이전의 것을 적절히 이해해둘 필요가 있습니다.

.NET Standard 2.0의 최소규격을 지원하는 .NET Core 2.0부터는 .NET Core의 첫번째 version에는 없던 많은 API를 제공하고 있으므로 여기서 부터가 중요한 전환점이 될 수 있습니다. .NET Framework 개발자가 최신의 개발과 관련하여 15년간 이용할 수 있었던 library와 application은 지금 .NET과 통합되었고 Windows는 물론 macOS와 다양한 Linux에서 동작할 수 있습니다.

.NET Standard 2.1은 3,000여개의 새로운 API가 추가되었는데 이들 중 몇몇은 이전 version과의 호환성을 깨는 runtime의 변경이 필요했습니다. 따라서 .NET Framework 4.8은 .NET Standard 2.0만을 구현하며 .NET Core 3.0, Xamarin, Mono, 그리고 Unity는 .NET Standard 2.1을 구현하게 되었습니다.

.NET 5에 들어서는 project에서 .NET 5만을 사용한다면 .NET Standard의 필요성을 제거할 수 있게 되었고 이는 .NET 6, .NET 7에서도 동일합니다. 하지만 여전히 .NET Framework project와 Xamarin mobile app을 생성해야 하는 경우도 있으므로 지금도 .NET Standard 2.0과 2.1 class library를 생성할 수 있습니다.

현재 .NET 6와 .NET 7은 자체 .NET MAUI를 통해 완벽하게 mobile과 desktop app을 지원하고 있는데 이로서 .NET Standard의 필요성은 점차 감소하고 있습니다.

아래는 지난 5년동안의 .NET의 진행상황을 요약하기 위해 주요 .NET Core와 최신 .NET을 동등한 .NET Framework와 비교한 것입니다.

.NET Core 1.x : 2016년 3월이 현재 version이며 .NET Framework 4.6.1에 비해 훨씬 작은 API를 가지고 있습니다.
.NET Core 2.x : .NET Framework 4.7.1과 동일하게 .NET Standard 2.0을 구현함으로서 동등한 API에 도달하였습니다.
.NET Core 3.x : .NET Framework 4.8에서 구현하지 않은 .NET Standard 2.1을 구현함으로서 월씬 더 많은 API를 지원하게 되었습니다.
.NET 5 : 상당히 향상된 성능과 함께 더 .NET Framework 4.8에 비해 더 많은 API를 지원합니다.
.NET 6 : 지속적인 성능 향상과 API확장을 이루었으며 2022년 5월에 추가된 .NET MAUI를 통해 mobile app을 지원할 수 있게 되었습니다.
.NET 7 : .NET MAUI로 mobile app지원을 위한 최종 통합 version입니다.
.NET 8 : 지속적인 성능 향상이 이루어지고 있으며 모든 신규 project에 적용할 수 있습니다.

(1) .NET Core 1.0

2016년 6월에 release 되었으며 ASP.NET Core를 사용하는 Linux용 web과 cloud application 그리고 service를 포함한 최신의 cross-platform app개발을 위해 안정적인 API를 제공하는데 초점이 맞춰진 version입니다.

(2) .NET Core 1.1

2016년 11월에 release 되었으며 bug를 수정하고 지원되는 Linux의 배포한 수를 증가되었으며 .NET Standard 1.6를 지원하게 되었습니다. 또한 성능의 증가도 이루어졌는데 특히 web app과 service를 위한 ASP.NET Core에서 큰 성능향상이 이루어졌습니다.

(3) .NET Core 2.0

2017년 8월에 release되었으며 .NET Standard 2.0을 구현하였고 .NET Framework library를 참조하고 더 많은 성능향상을 이루었습니다.

(4) .NET Core 2.1

2018년 5월에 release 되었으며 확장가능한 tooling system(사용 목적에 따라 각각의 도구(기능)를 선택/조합하는 체계)에 중점을 두었습니다. Span<T>, 암호화 및 압축 그리고 예전 windows application을 이식하는데 필요한 20,000가지의 추가적인 API와 함께 Windows Compatibility Pack, Entity Framework Core값 변환, LINQ GroupBy 변환, data seeding, query type과 같은 새로운 type이 추가되었으며 아래 표의 기능을 포함해 전반적인 성능 향상이 이루어졌습니다.

기능	내용
Spans	-
Brotli compression	Brotli algorithm을 통한 압축방식
EF Core Lazy loading	lazy(지연) loading 사용
EF Core Data seeding	-

(5) .NET Core 2.2

2018년 12월에 release 되었으며 runtime에서의 진단향상, 선택적 계층 compile등에 중점을 두었으며 ASP.NET Core과 Entity Framework에 NetTopologySuite (NTS) library, query tag, 소유 entity collection 등의 type을 사용하는 공간 data지원등 새로운 기능이 추가되었습니다.

(6) .NET Core 3.0

2019년 9월에 release 되었으며 Windows forms, WPF(Windows Presentation Foundation) 그리고 Entity Framework 6.3, side-by-side와 app-local 개발, fast JSON reader, serial port 접근, IoT(Internet of Things) solution을 위한 pinout 접근등을 사용하는 desktop application구축하는데 필요한 지원에 중점을 두었습니다. 또한 아래 기능을 포함해 기본 계층 compile이 추가되었습니다.

기능	내용
Embedding .NET in-app	-
Index and Range	-
System.Text.Json	고성능 JSON 처리

(7) .NET Core 3.1

2019년 12월에 release 되었으며 bug수정과 개선에 초점이 맞춰져 Long Term Support (LTS)가 되었고 이로서 2022년 12월까지 지원이 이루어졌습니다.

(8) .NET 5.0

2020년 10월에 release 되었으며 mobile을 제외한 다양한 .NET platform을 통합하는데 주력하였습니다. platform을 개선하고 아래 표의 기능을 포함해 전반적으로 성능향상이 이루어졌습니다.

기능	내용
Half type	반정밀도 부동 소수점 숫자
정규 표현식 성능 향상	정규 표현식 성능 향상
System.Text.Json 향상	고성능 JSON 처리
EF Core generated SQL	-
EF Core Filtered Include	Entity filtering
EF Core의 Humanizer 통합	-

(9) .NET 6.0

2021년 10월에 release 되었으며 data관리를 위한 EF Core로 더 많은 기능과 함께 시간과 날짜에 관한 새로운 type이 추가되었습니다. 또한 아래 표의 기능을 포함해 전반적인 성능향상이 이루어졌습니다.

기능	내용
.NET SDK 상태 확인	.NET SDK update 확인
Apple Silicon 지원	배포가능한 console application 생성가능
Link trim mode 기본 사용	app trimming을 통한 app size 감소
List<T>에 대한 EnsureCapacity	collection용량 확보를 통한 성능 향상
RandomAccess를 사용하는 저수준 file API	-
EF Core 구성 규칙	-
새로운 LINQ method	-
TryGetNonEnumeratedCount	-

(10) .NET 7.0

2022년 10월에 release 되었으며 mobile platform을 통합하고 string syntax coloring과 IntelliSense 같은 새로운 기능이 추가되었습니다. tar 형식의 압축을 생성하거나 풀어낼 수 있게 되었고 EF Core를 통한 insert와 upate성능이 향상되었습니다.

기능	내용
[StringSyntax] attribute	regular expression syntax coloring 활성화
[GeneratedRegex] attribute	source generator를 통한 정규 표현식 성능 향상
Tar archive support	tar 압축 file
ExecuteUpdate와 ExecuteDelete	더욱 효과적인 update및 삭제
Order와 OrderDescending	item 자체 정렬

(11) .NET 8.0

C# 12 및 F# 8 언어의 새로운 기능과 개선 사항을 포함하고 있으며 Dynamic Profile-Guided Optimization (PGO)이라는 새로운 코드 생성기를 도입하여 실제 사용에 기반한 코드 최적화를 이룰 수 있습니다. 실제 이를 통해 통해 애플리케이션 성능을 최대 20%까지 향상시킬 수 있습니다. 이 밖에 AI사용을 위한 기능이 강화되었습니다.

(12) .NET 5 이후의 성능 향상

Microsoft는 지난 몇년간 .NET에 대한 상당한 성능향상을 이루어 왔습니다. 이와 관련된 상세한 내용은 아래 글을 통해 확인하실 수 있습니다.

Performance Improvements in .NET 5 - .NET Blog (microsoft.com)

Performance Improvements in .NET 5 - .NET Blog

Explore many performance improvements, big and small, that have gone into the .NET 5 runtime and core libraries to make apps and services leaner and faster.

devblogs.microsoft.com

Performance Improvements in .NET 6 - .NET Blog (microsoft.com)

Performance Improvements in .NET 6 - .NET Blog

Take a rip-roarin' tour through hundreds of PRs worth of performance improvements for .NET 6.

devblogs.microsoft.com

Performance Improvements in .NET 7 - .NET Blog (microsoft.com)

Performance Improvements in .NET 7 - .NET Blog

.NET 7 is fast. Really fast. This post deep-dives into hundreds of performance improvements that contributed to that reality.

devblogs.microsoft.com

Performance Improvements in .NET 8 - .NET Blog (microsoft.com)

Performance Improvements in .NET 8 - .NET Blog

.NET 7 was super fast, .NET 8 is faster. Take an in-depth tour through over 500 pull requests that make that a reality.

devblogs.microsoft.com

(13) Update를 위한 .NET SDK 확인

.NET 6에서 부터 Microsoft는 설치 SDK와 runtime의 version을 확인하기 위한 명령을 추가했고 이를 통해 update가 필요하다고 확인되는 경우 이를 알려줄 수 있습니다.

명령은 아래와 같으며

dotnet sdk check

다음과 같은 경우처럼 update가 필요한 항목을 확인할 수 있습니다.

.NET SDKs:
Version      Status
------------------------
8.0.101      Up to date.

.NET Runtimes:
Name                              Version      Status
-------------------------------------------------------------------------------------
Microsoft.NETCore.App             5.0.17       .NET 5.0 is out of support.
Microsoft.NETCore.App             6.0.7        Patch 6.0.26 is available.
Microsoft.WindowsDesktop.App      6.0.7        Patch 6.0.26 is available.
Microsoft.NETCore.App             6.0.10       Patch 6.0.26 is available.
Microsoft.WindowsDesktop.App      6.0.10       Patch 6.0.26 is available.
Microsoft.NETCore.App             6.0.11       Patch 6.0.26 is available.
Microsoft.WindowsDesktop.App      6.0.11       Patch 6.0.26 is available.
Microsoft.NETCore.App             6.0.12       Patch 6.0.26 is available.
Microsoft.WindowsDesktop.App      6.0.12       Patch 6.0.26 is available.
Microsoft.NETCore.App             6.0.13       Patch 6.0.26 is available.
Microsoft.WindowsDesktop.App      6.0.13       Patch 6.0.26 is available.
Microsoft.AspNetCore.App          6.0.14       Patch 6.0.26 is available.
Microsoft.NETCore.App             6.0.15       Patch 6.0.26 is available.
Microsoft.WindowsDesktop.App      6.0.15       Patch 6.0.26 is available.
Microsoft.AspNetCore.App          6.0.26       Up to date.
Microsoft.NETCore.App             6.0.26       Up to date.
Microsoft.WindowsDesktop.App      6.0.26       Up to date.
Microsoft.NETCore.App             7.0.3        .NET 7.0 is going out of support soon.
Microsoft.WindowsDesktop.App      7.0.3        .NET 7.0 is going out of support soon.
Microsoft.AspNetCore.App          7.0.15       .NET 7.0 is going out of support soon.
Microsoft.NETCore.App             7.0.15       .NET 7.0 is going out of support soon.
Microsoft.WindowsDesktop.App      7.0.15       .NET 7.0 is going out of support soon.
Microsoft.AspNetCore.App          8.0.1        Up to date.
Microsoft.NETCore.App             8.0.1        Up to date.
Microsoft.WindowsDesktop.App      8.0.1        Up to date.

The latest versions of .NET can be installed from https://aka.ms/dotnet-core-download. For more information about .NET lifecycles, see https://aka.ms/dotnet-core-support.

2 .NET Component

.NET은 아래와 같은 요소로 이루어져 있습니다.

Language compiler : C#이나 F#등으로 된 source code를 assembly로 저장된 IL code로 변환시킵니다. C# 6.0 이후부터는 compiler를 Roslyn이라는 이름으로 open-source화 하였습니다.
Common Language Runtime(CoreCLR) : Assembly를 load 하여 해당 assembly에 저장된 IL code를 해당 computer의 CPU에 맞는 native code로 compile한뒤 thread와 memory 같은 관리 resource환경 안에서 code를 실행하게 됩니다.
Base Class Libraries(BCL 또는 CoreFX) : Application을 구축할 때 공통적인 동작을 수행하기 위해 Nuget을 통하여 package 및 배포된 type의 사전 build 된 assembly를 포함할 수 있습니다. 이를 사용하여 LEGO 부품을 조립하듯 필요한 것을 빠르고 안정적으로 구축할 수 있습니다.

(1) Assembly, NuGet package, namespace

Assembly는 type이 filesystem으로 저장된 것입니다. Code를 배포하기 위한 mechanism인데 예를 들어 System.Data.dll assembly는 data를 관리하기 위한 type을 포함하고 있습니다. 다른 assembly의 다른 type을 사용하기 위해서는 해당 assembly가 참조되어 있아야 하며 이때 assembly는 정적(pre-created) 또는 동적(generated at runtime)인 것이 될 수 있습니다. 또한 assembly는 class library인 dll이나 console app과 같은 exe의 단일 file로 compile 될 수도 있습니다.

Assembly는 NuGet package를 통해 내려받기 가능하도록 배포될 수 있으며 이때 다수의 assembly나 다른 resource를 포함할 수 있습니다.

Microsoft NuGet feed는 아래 주소에서 찾을 수 있습니다.

NuGet Gallery | Home

The NuGet Gallery is the central package repository for NuGet, the package manager for .NET.

www.nuget.org

● Namespace

Namespace는 type의 주소입니다. 단순한 이름대신 주소체계를 사용함으로써 type을 식별하기 위한 mechanism으로 활용됩니다.

한 가지 예로 .NET에서 System.Web.Mvc namespace의 interface인 IActionFilter는 System.Web.Http.Filters namespace의 IActionFilter에 비해 namespace가 다르므로 다른 interface로 구별될 수 있습니다.

● Assembly 의존성

Assembly가 class library로 compile 되고 다른 assembly에서의 사용을 위해 이를 제공하게 된다면 이때 file은 .dll 확장자를 가지게 되며 독립적으로 실행될 수 없습니다.

마찬가지로, assembly가 application으로 compile 되면 이때는 exe확장자를 가지게 되며 독립적으로 실행가능한 상태가 됩니다. (.NET Core 3.0이전에 console app은 dll file로 compile 되었으며 이때는 dotnet run 명령을 통해 실행될 수 있었습니다.)

모든 assembly는 하나 또는 그 이상의 class library를 의존성으로 참조할 수 있습니다. 하지만 소위 순환참조는 불가능하기 때문에 예를 들어 B라는 assembly는 A라는 assembly에서 이미 B assembly를 참조하고 있다면 A assembly를 참조할 수 없습니다. 때문에 compiler는 순환참조를 유발할 수 있는 의존성 참조를 추가하려고 한다면 경고를 표시하게 됩니다. 대게는 오래전에 작성된 code에서 순환참조에 대한 오류가 나오기 쉬우며 만약 정말 순환참조가 필요한 상황이 온다면 이는 interface로 관련 문제를 해결하는 것이 좋습니다.

(2) Microsoft .NET Project SDK

기본적으로 console application은 Microsoft .NET project SDK에 대한 의존성 참조를 가지고 있습니다. 이 platform은 NuGet package에서 거의 대부분의 application에서 필요로 하는, 예를 들어 System.Int32나 System.tring type과 같은 수천 개의 type들을 포함하고 있으며 .NET을 사용할 때는 project file에서 필요로 하는 의존성 assembly와 NuGet package 그리고 platform 등을 참조하게 됩니다.

(3) Assembly에서 namespace와 type

대부분의 일반적인 .NET type은 System.Runtime.dll assembly에 있으며 assembly와 namespace는 항상 1:1로 mapping 되지는 않습니다. 단일 assembly라도 다수의 namespace를 포함할 수 있으며 namespace는 다수의 assembly에서 정의될 수 있습니다. 아래 표는 type을 지원하기 위해 사용되는 일부 assembly와 namespace 간 연관성을 나타내고 있습니다.

Assembly	사용 Namespace	제공 Type
System.Runtime.dll	System, System.Collections, System.Collections.Generic	Int32, String, IEnumerable<T>
System.Console.dll	System	Console
System.Threading.dll	System.Threading	Interlocked, Monitor, Mutex
System.Xml.XDocument.dll	System.Xml.Linq	XDocument, XElement, XNode

(4) NuGet package

.NET은 하나가 아닌 몇 개의 package별로 나누어졌고 이를 NuGet이라는 package 관리 기술을 사용해 게시하였습니다. 이렇게 게시된 각각의 package들은 같은 이름의 단일 assembly로 표현됩니다. 예를 들어 System.Collections package는 System.Collections.dll assembly를 포함합니다.

Package는 다음과 같은 장점 및 특징을 가집니다.

공개 feed(패키지를 인터넷의 모든 사용자와 공개적으로 공유하는 데 사용)에 쉽게 게시할 수 있습니다.
재사용이 가능합니다.
자체 일정에 따라 게시될 수 있습니다.
다른 package와 독립적으로 test 될 수 있습니다.
같은 assembly를 다른 OS와 CPU에 따라 build 한 여러 version을 포함시킴으로써 다른 OS와 CPU를 지원할 수 있습니다.
하나의 library에 대해서만 특정한 종속성을 가질 수 있습니다.
참조되지 않은 package는 배포의 일부가 아니므로 app은 더 작아질 수 있습니다. 아래 표는 가장 중요한 package와 해당 package에서 중요한 type의 일부를 나타낸 것입니다.

Package	중요 type
System.Runtime	Object, String, Int32, Array
System.Collections	List<T>, Dictionary<TKey, TValue>
System.Net.Http	HttpClient, HttpResponseMessage
System.IO.FileSystem	File, Directory
System.Reflection	Assembly, TypeInfo, MethodInfo

(5) Framework

Package는 API를 정의하며 framework는 이런 package를 group화 합니다. 어떠한 package도 없는 framework는 어떠한 API도 정의하지 않습니다.

.NET package는 각각 일련의 framework를 지원합니다. 예를 들어 System.IO.FileSystem package version 4.3.0은 아래 framework를 지원합니다.

.NET Standard, version 1.3 이후
.NET Framework, version 4.6 이후
Six Mono와 Xamarin platform (Xamarin.iOS 1.0)

좀 더 상세한 내용은 아래 주소를 참조하시기 바랍니다.

NuGet Gallery | System.IO.FileSystem 4.3.0

System.IO.FileSystem 4.3.0

Provides types that allow reading and writing to files and types that provide basic file and directory support. Commonly Used Types: System.IO.FileStream System.IO.FileInfo System.IO.DirectoryInfo System.IO.FileSystemInfo System.IO.File System.IO.Directory

www.nuget.org

(6) Type 사용을 위한 namespace importing

예제를 통해 namespace가 assembly와 type에 어떻게 관련되는지를 알아보도록 하겠습니다. csStudy07 이름의 빈 solution을 생성하고 그 안에 'AssembliesAndNamespaces'이름의 project를 추가합니다.

AssembliesAndNamespaces의 Program.cs에서 기존 구문을 모두 삭제하고 아래와 같이 XDocument type의 instance를 생성하는 문을 추가합니다.

XDocument doc = new();

이 상태에서 Project를 build 하면 다음과 같은 compiler error message가 발생하게 됩니다.

The type or namespace name 'XDocument' could not be found (are you missing a using directive or an assembly reference?)

XDocument type은 우리가 compiler에게 해당 type의 namespace가 무엇인지를 알려주지 않았기 때문에 인식될 수 없습니다. 설령 project가 type을 포함하고 있는 assembly를 참조하고 있다고 하더라도 type이름에 namespace에 대한 접두사를 붙이거나 해당 namespace를 import 해야 합니다.

XDocument class의 이름에 mouse를 대면 하단에 풍선도움말이 표시되는데 이때 'Show potential pixes'를 click한뒤 menu에 나오는 System.Xml.Linq를 선택하면 자동적으로 해당 Namespace가 file의 상단에 using문을 추가함으로써 import 될 것입니다. 일단 namespace가 import 되고 나면 namespace에 속하는 모든 type은 code에서 namespace전체를 붙여줄 필요 없이 이름만 입력하는 것으로 사용가능하게 됩니다.

Visual Studio를 사용하는 것이라면 위에서 처럼 type을 입력하는 것만으로 인식가능한 namespace를 자동으로 import 해줄 것입니다.(2022 version부터)

(7) C# keyword와 .NET type의 연결

C#에서는 문자열을 다루는 keyword가 2가지가 있는데 하나는 string이고 다른 하나는 String입니다. 이 둘의 차이는 소문자 s와 대문자 S 뿐이며 사실상 용도와 동작에 있어서는 아무런 차이가 없습니다. int와 string과 같은 C# keyword는 class library assembly에 있는 .NET Type의 별칭입니다.

따라서 string keyword를 사용하는 경우에 compiler는 이를 System.String type으로 인식하게 되고 int를 사용하는 경우에는 System.Int32 type으로 인식합니다. 문자열을 다루기 위해 String이라고 하는 것보다는 string으로 사용하는 것이 더 익숙하고 편리한 면이 있으며 Int32보다는 int로 사용하는 것도 같은 이유기 때문에 좀 더 편리한 code의 작성을 위해 별칭으로 따로 만들어둔 것입니다.

Program.cs에서 문자열값을 가진 2개의 변수를 선언하는데 하나는 string으로 다른 하나는 String으로 선언합니다.

string s1 = "Hello";
String s2 = "World";
Console.WriteLine($"{s1} {s2}");

위 예제를 실행하면 두 변수는 정확히 동일하게 취급되어 동일한 처리를 하게 됩니다.

Project의 csproj file에서 전역적으로 import 되는 System namespace를 사용하지 않도록 하는 요소를 아래와 같이 추가합니다.

<ItemGroup>
	<Using Remove="System" />
</ItemGroup>

그러면 아래와 같이 compiler 오류가 발생할 것입니다.

이를 통해 String은 System namespace의 String type을 사용한다는 것을 알 수 있습니다.

실제 String과 같은 type대신 C# keyword를 사용하면 위에서와 같이 해당 type의 namespace import를 신경 쓰지 않아도 됩니다.

● C# 별칭과 .NET type의 Mapping

아래 표는 18가지 C# type keyword와 같이 연결된 .NET Type을 나타내고 있습니다.

Keyword	.NET type	Keyword	.NET type
string	System.String	char	System.Char
sbyte	System.SByte	byte	System.Byte
short	System.Int16	ushort	System.UInt16
int	System.Int32	uint	System.UInt32
long	System.Int64	ulong	System.UInt64
nint	System.IntPtr	nuint	System.UIntPtr
float	System.Single	double	System.Double
decimal	System.Decimal	bool	System.Boolean
object	System.Object	dynamic	System.Dynamic.DynamicObject

다른 .NET Programming 언어 compiler도 같은 방식을 사용할 수 있습니다. 예를 들어 VB.NET의 경우에는 Integer라는 이름의 type을 가지고 있으며 이는 System.Int32의 별칭으로 연결됩니다.

● native-sized integers

C# 9에서는 native-sized integers에 대한 별칭에 해당하는 nint와 nuint를 도입하였습니다. 여기서 저장되는 integer값의 크기는 platform에 따라 다릅니다. 따라서 32bit process에서는 32bit integer로 저장되며 sizeof()에서는 4byte를 반환하고 64bit process에서는 64bit integer로, sizeof()에서는 8byte를 반환합니다. 해당 별칭의 이름이 IntPtr/UIntPtr인데 이를 통해 해당 별칭은 integer값이 저장된 memory의 위치를 나타낸다는 것을 알 수 있으며 실제 저장되는 type은 process에 따라 System.Int32 또는 System.Int64가 됩니다.

Console.WriteLine($"int.MaxValue = {int.MaxValue:N0}");
Console.WriteLine($"nint.MaxValue = {nint.MaxValue:N0}");

● Type의 위치 표시

Visual Studio에서 아래와 같이 string이나 String의 변수를 생성하고

string s;

해당 type을 선택한 뒤 mouse오른쪽 button을 눌러 'Go to Definition'을 선택합니다.

Code editor를 보면 assembly file명은 'System.Runtime.dll'이지만 class는 System namespace에 있음을 알 수 있습니다.

그런데 지난 글에서

[.NET/C#] - [C# 12와 .NET 8] 2. C#

System.Runtime.dll에 포함된 type은 0 임을 언급한 바 있습니다.

System.Runtime.dll assembly가 포함하고 있는 것은 type-forwarder입니다. 이들은 assembly안에 포함되어 있는 것처럼 표시하지만 다른 곳에 구현되어 있는 특별한 type입니다. 이 경우 string은 고도로 최적화된 code를 사용해 .NET runtime내부에 깊이 구현되어 있습니다.

(8) .NET Standard를 사용한 legacy platform과의 code공유

.NET Standard 이전에는 PCL(Portable Class Libraries)가 있었습니다. PCL에서는 code의 library를 만들고 명시적으로 library에서 지원할 Xamarin, Silverlight, Windows 등의 platform을 지정할 수 있었고, 그렇게 하면 library는 지정된 platform에 의해서 지원되는 API와의 상호작용에 사용될 수 있었습니다.

하지만 Microsoft는 이것이 지속가능하리라고 판단하지 않고 미래 모든 .NET platform에서 지원할 단일 API인 .NET Standard를 생성하게 됩니다. .NET Standard에 이어 .NET Standard 2.0에서는 중요한 최신 .NET platform의 통합을 시도했고 2019년 말에 발표된 .NET Standard 2.1에서는 .NET Core 3.0과 그해 Xamarin에서만이 새로운 기능을 지원했습니다. (앞으로 언급되는 .NET Standard는 .NET Standard 2.0을 의미합니다.)

.NET Standard는 HTML5와 같이 둘다 platform이 지원할 수 있는 표준에 해당합니다. Google의 Chrome browser나 Microsoft의 Edge browser가 HTML5의 표준을 구현하듯 .NET Core, .NET Framework 그리고 Xamarin은 모두 .NET Standard를 구현합니다. 만약 다양한 legacy .NET에 걸쳐 작동하는 type의 library를 만들고자 한다면 .NET Standard를 통해 가장 쉽게 구현할 수 있습니다.

.NET Standard 2.1에서 많은 API가 추가되어 runtime의 변화가 필요했으며 .NET Framework는 가능한 한 변화 없이 유지되어야 할 Microsoft의 legacy platform이므로 .NET Framework 4.8에서는 .NET Standard 2.1을 구현하기 보다는 .NET Standard 2.0에서 남아있습니다. 만약 .NET Framework에서 지원되어야 할 필요가 있다면 비록 최신의 version이 아니고 모든 최근의 언어와 BCL의 새로운 기능을 지원하지 않지만 .NET Standard 2.0상의 class library를 만들 수 있습니다.

어떤 .NET Standard version을 목표로 할지에 대한 선택에서는 지원하고자 하는 platform과 가능한 기능사이에 균형을 맞추는 것이 중요합니다. 하위 version은 더 많은 platform을 지원하지만 더 작은 API를 갖게 됩니다. 상위 version은 적은 platform을 지원하지만 더 많은 API를 가질 수 있습니다. 일반적으로는 필요로 하는 모든 API를 지원하는 선에서 하위 version을 선택할 수 있습니다.

(9) 다른 SDK를 사용하는 class library의 기본 framework

Class library를 만들기 위해 dotnet SDK tool을 사용할 때 어떤 framework가 기본적으로 사용될지 알고 있을 필요가 있습니다. 아래 표는 이를 간략히 나타내고 있습니다.

SDK	새로운 class library에 사용될 기본 target framework
.NET Core 3.1	netstandard2.0
.NET 6	net6.0
.NET 7	net7.0
.NET 8	net8.0

물론 class library가 기본적으로 특정 .NET의 version을 대상으로 한다 하더라도 이것이 기본 template을 사용해 class library project를 생성한 이후에는 바꿀 수 없다는 것을 의미하는 것은 아닙니다.

설정에 의해 target framework를 library참조가 필요한 project에서 지원하는 값으로 바꿀 수 있습니다.

Class library target framework	project에서 사용할 수 있는 대상
netstandard2.0	.NET Framework 4.6.1이후, .NET Core 2.0이후, .NET 5.0이후, Mono 5.4이후, Xamarin.Android 8.0이후, Xamarin.iOS 10.14이후
netstandard2.1	.NET Core 3.0이후, .NET 5.0이후, Mono 6.4이후, Xamarin.Android 10이후, Xamarin.iOS 12.16이후
net6.0	.NET 6.0이후
net7.0	.NET 7.0이후
net8.0	.NET 8.0이후

Class library의 대상 framework를 확인하고 필요하다면 더 적절한 것으로 바꿀 수 있습니다. 기본값을 그대로 수용하기보다는 무엇이 적합한지 의식적으로 결정을 내리시면 됩니다.

(10) .NET Standard 2.0 class library를 만들기

.NET Standard 2.0을 사용해 모든 .NET legacy platform과 Windows 및 macOS, Linux OS의 cross-platform에서 사용가능하며 다양한 .NET API에 access 할 수 있는 class library를 만들어볼 것입니다.

csStudy07 solution에 SharedLibrary이름의 Class Library유형의 project를 추가합니다. 이때 .NET Standard 2.0을 target으로 설정해야 합니다.

만약 .NET Standard 2.0 기능만 사용하는 type뿐만 아니라 .NET 7의 새로운 기능을 사용하는 type을 생성해야 한다면 이 두 개의 class library를 분리하여 생성해야 합니다.

2개의 class library를 생성하는 대신 multi-targeting을 지원하는 방법도 존재합니다. 자세한 내용은 아래 link를 참고하시기 바랍니다.

Cross-platform targeting for .NET libraries | Microsoft Learn

Cross-platform targeting for .NET libraries

Best practice recommendations for creating cross-platform .NET libraries.

learn.microsoft.com

(11) .NET SDK 제어

기본적으로 dotnet 명령줄 실행에서는 system에 설치된 가장 최신의 .NET SDK를 사용합니다. 그러나 때로는 이렇게 사용되는 SDK를 변경해야 하는 경우가 있습니다. 그리고 이것은 global.json file을 사용함으로써 가능한데 dotnet명령은 global.json file을 현재 folder와 상위 folder에거 검색합니다.

지금부터 설명하는 절차를 굳이 따라 할 필요는 없지만 그래도 해보고자 한다면 .NET 6.0 SDK를 설치해야 하며 아래 link로부터 가져올 수 있습니다.

Download .NET 6.0 (Linux, macOS, and Windows) (microsoft.com)

Download .NET 6.0 (Linux, macOS, and Windows)

.NET 6.0 downloads for Linux, macOS, and Windows. .NET is a free, cross-platform, open-source developer platform for building many different types of applications.

dotnet.microsoft.com

csStudy07 project folder하위에 ControlSDK이름의 새로운 folder를 만들고 해당 folder안에서 terminal을 열어 아래 명령을 내려줍니다.

dotnet --list-sdks

만약 .NET SDK 6.0을 설치했다면 아마도 아래와 같은 결과를 표시할 수 있습니다.

6.0.418 [C:\Program Files\dotnet\sdk]
8.0.101 [C:\Program Files\dotnet\sdk]

이 상태에서 아래의 명령을 내려 global.json이름의 file을 만들고 아래와 같이 설정하여 설치한 .NET Core 6.0 SDK의 사용을 강제하도록 합니다.

dotnet new globaljson --sdk-version 6.0.410

생성된 file을 열어보면 아마도 다음과 같이 저장되어 있을 것입니다.

{
  "sdk": {
    "version": "6.0.410"
  }
}

이제 아래 명령을 통해 class library project의 생성을 시도합니다.

dotnet new classlib

만약 정상적으로 처리된다면 해당 project가 생성되어 있을 테지만 .NET SDK 6.0이 설치되지 않은 상태라면 다음의 오류가 표시될 것입니다.

The command could not be loaded, possibly because:
  * You intended to execute a .NET application:
      The application 'new' does not exist.
  * You intended to execute a .NET SDK command:
      A compatible .NET SDK was not found.

Requested SDK version: 6.0.410

(12) SDK와 framework의 혼합사용

대개의 경우 신규 project를 생성할때 Microsoft의 장기적(3년)지원을 받기 위해 long-term version의 .NET을 사용할 것입니다. 이후에 새로운 .NET version이 나오고 거기에 맞춰 upgrade할 수도 있겠지만 그렇게 하지 않는다고 해서 사용중인 .NET runtime의 생명주기동안 C#언어의 개선된 기능이나 성능에 대한 이점을 포기할 필요는 없습니다.

향후에도 C# compiler를 설치하고 사용하면서 기존 .NET에 대한 사용을 지속할 수 있습니다. 이걸 시기적으로 보면 다음과 같이 설명할 수 있습니다.

2023년 11월	.NET SDK 8.0을 설치하고 이를 사용해 .NET 8로 target이 설정된 project를 build합니다. 이때 C# 12가 기본적으로 사용됩니다. 이후에는 매달 개발자 computer에서 .NET 8 SDK와 사용자 computer상에서 .NET 8 runtime update patch가 이루어집니다.
2024년 2월	새로운 C# 언어와 .NET library기능을 확인해 보기 위해 선택적으로 .NET SDK 9 Preview를 설치할 수 있습니다. .NET 8로 target이 맞춰진 경우에는 새로운 library기능은 사용할 수 없습니다. Preview는 매년 2월 ~ 10월 사이에 release되며 공식 blog의 공지사항을 통해 Preview에서의 새로운 기능을 확인할 수 있습니다.
2024년 11월	.NET SDK 9.0.x를 설치하고 이를 사용해 .NET 8로 target이 설정된 project를 build합니다. 이때 C# 13이 기본적으로 사용되며 언어의 새로운 기능역시 사용할 수 있습니다. 또한 SDK와 runtime에 대한 완전한 지원을 받을 수 있고 .NET 8 target project에서도 EF Core 9의 새로운 기능을 사용할 수 있습니다.
2025년 2월	새로운 C# 언어와 .NET library기능을 확인해 보기 위해 선택적으로 .NET SDK 10 Preview를 설치할 수 있습니다. 만약 .NET 8 project를 새로운 version으로 전환해야 한다면 .NET9와 .NET10의 새로운 library및 ASP.NET Core 기능을 적용할 수 있는지에 대한 계획을 세워야 합니다.
2025년 11월	.NET SDK 10.0.x를 설치하고 이를 사용해 .NET 8로 target이 설정된 project를 build합니다. 이때 C# 14이 기본적으로 사용되며 언어의 새로운 기능역시 사용할 수 있습니다. 다만 .NET 8은 LTS이므로 .NET 8의 수명주기종료가 되는 2026년 11월까지 .NET 10으로의 전환이 필요합니다.

.NET SDK를 설치할때는 모든 .NET project를 build하기 위해 기본적으로 가장 최신의 version이 사용됨을 기억하시기 바랍니다. 따라서 만약 현 시점에서 .NET 9 SDK preview가 설치되면 인위적으로 사용할 version을 강제하지 않는 이상 project build를 위해 해당 version이 사용될 것입니다.

3. 배포를 위한 code 게시하기

만약 소설과 같은 글을 쓴 경우라면 이것을 다른 사람이 읽도록 하기 위해서는 '출판'해야 할 것입니다. 대부분의 개발자는 자신의 project에서 사용하거나 또는 app을 실행하는 일반사용자를 위한 code를 작성합니다. 그렇게 하기 위해서는 class library를 packaging 하거나 실행 가능한 형태의 application으로 게시를 해야 합니다.

.NET application을 배포하고 게시하기 위해서는 아래 3가지 방법을 사용할 수 있습니다.

Framework-dependent deployment (FDD)
Framework-dependent executable (FDE)
Self-contained

만약 application 및 여기에 해당하는 package종속성을 같이 배포하기로 했지만 .NET자체는 제외한다면 대상 computer에 설치된 .NET에 의존해야 합니다. 이것은 server에 web application을 배포하기에 적합한 방식입니다. 왜냐하면 .NET은 물론 다른 web application 이미 server에 존재할 수 있기 때문입니다.

Framework-dependent deployment (FDD)는 dotnet 명령줄 도구를 통해 실행될 수 있는 DLL을 배포하는 경우를 의미하며 Framework-dependent executables (FDE)는 직접적으로 실행될 수 있는 EXE를 배포하는 경우를 의미합니다. 이 둘은 모두 system에 적절한 version의 .NET runtime이 설치되어 있어야 합니다.

때로는 다른 사람에게 USB memory를 통해 application을 전달하고자 할 수 있습니다. 이런 경우 전달받은 사용자의 computer에서 실행될 수 있도록 self-contained deployment를 수행할 수 있습니다. 물론 이렇게 하는 경우 배포 file의 size가 커질 수 있지만 관련된 모든 library를 포함하게 되므로 실행하는 데는 아무런 문제가 없을 것입니다.

(1) 게시를 위한 console app 만들기

csStudy07 solution에서 DotNetEverywhere이름의 Console App project를 생성합니다. 그리고 Program.cs에서 기존 구문을 모두 삭제하고 console app이 어디서든 작동할 수 있음을 말하는 message와 현재 운영체제에 대한 정보를 출력하는 문을 아래와 같이 추가합니다.

Console.WriteLine("I can run everywhere!");
Console.WriteLine($"OS Version is {Environment.OSVersion}.");

if (OperatingSystem.IsMacOS())
{
    Console.WriteLine("I am macOS.");
}
else if (OperatingSystem.IsWindowsVersionAtLeast(major: 10, build: 22000))
{
    Console.WriteLine("I am Windows 11.");
}
else if (OperatingSystem.IsWindowsVersionAtLeast(major: 10))
{
    Console.WriteLine("I am Windows 10.");
}
else
{
    Console.WriteLine("I am some other mysterious OS.");
}

Console.WriteLine("Press ENTER to stop me.");
Console.ReadLine();

위 예제를 실행하면 다음과 같은 결과를 표시할 것입니다.(실행되는 환경에 따라 약간씩 다를 수 있습니다.)

Project file(csproj)을 열어 <PropertyGroup> 요소 안에 세 가지 운영체제를 대상으로 하기 위한 runtime 식별자를 아래와 같이 추가합니다.

<Nullable>enable</Nullable>
<RuntimeIdentifiers>
	win10-x64;osx-x64;osx.11.0-arm64;linux-x64;linux-arm64
</RuntimeIdentifiers>

추가한 요소는 다음과 같은 의미를 가집니다.

win10-x64 : Windows 10 또는 Windows Server 2016 64-bit를 의미합니다. 만약 Microsoft Surface Pro X, Surface Pro 9(SQ 3) 또는 Windows Dev Kit 2023으로 배포하고자 한다면 win10-arm64로 설정할 수 있습니다.
osx-64 : macOS Sierra 10.12이상을 의미합니다. 또한 osx.10.15-x64 (Catalina), osx.13.0-x64 (Ventura on Intel), osx.13.0-arm64 (Ventura on Apple Silicon)등 특정 version을 명시할 수도 있습니다.
linux-x64 : Ubuntu, CentOS, Debian, Fedora와 같은 Linux의 대부분의 desktop 배포판을 의미합니다. linux-arm을 사용하는 경우에는 Raspbian 또는 Raspberry Pi OS 32-bit를 의미하며 linux-arm64라면 Raspberry Pi running Ubuntu 64-bit를 의미합니다.

특정 runtime을 식별하기 위해 사용가능한 2가지 요소가 있습니다. <RuntimeIdentifier>는 특정한 한 가지만을 지정해야 하는 경우에 사용하며 <RuntimeIdentifiers>는 예제와 같이 여러 가지를 지정해야 하는 경우에 사용합니다. 그런데 만약 잘못된 값을 사용하게 된다면 compiler는 error를 발생시키게 되는데 경우에 따라 단 하나의 잘못된 문자로 error가 발생하는 경우에 무엇이 잘못되었는지 찾기가 어려워질 수 있으므로 주의해야 합니다.

(2) dotnet 명령

.NET SDK를 설치하게 되면 dotnet이라는 이름의 command line interface(CLI)를 같이 설치하게 됩니다.

● 새로운 project 생성

.NET CLI는 template을 사용해 새로운 project를 현재 folder에 생성하는 명령을 포함하고 있습니다.

Terminal을 열고 .NET 7이상 이라면 'dotnet new list'를, .NET 6라면 'dotnet new --list'혹은 'dotnet new -l'명령을 내려줍니다. 그러면 다음과 같이 현재 설치된 template을 표시하게 됩니다.

대부분의 dotnet 명령의 switche는 길고 짧은 version을 각각 사용할 수 있기 때문에 만약 --list라 하면 -l처럼 사용할 수 있습니다. 짧은 것은 typing 하기에 빠를 수 있지만 다른 사람이나 심지어 본인도 잘못 명령을 해설할 수 있으므로 긴 것을 사용하면 의미를 좀 더 명확히 전달할 수 있습니다.

.NET MAUI는 Linux를 지원하지 않습니다. 해당 작업은 open source community에서 계속 진행되겠지만 진정한 cross-platform UI를 사용해야 한다면 Avalonia를 참고하시기 바랍니다.

Avalonia UI - Home

Avalonia UI - Cross-Platform UI Framework for .NET

Pixel-Perfect Cross-Platform .NET Applications with C# for Windows, macOS, Linux, iOS, Android and Browser.

www.avaloniaui.net

(3) .NET및 실행환경에 대한 정보 파악하기

현재 설치된 .NET SDK및 runtime과 함께 운영체제에 대한 정보를 확인해 보려면 'dotnet --info'명령을 사용하면 됩니다.

(4) dotnet CLI로 Project 관리하기

.NET CLI는 아래명령을 통해 project를 관리하기 위해 현재 folder에 project에 대한 몇 가지 작업을 수행할 수 있습니다.

dotnet help : dotnet 명령에 대한 도움말을 표시합니다.
dotnet new : 새로운 .NET project 또는 file을 생성합니다.
dotnet tool : .NET 환경을 확장하기 위한 도구를 설치하거나 관리합니다.
dotnet workload : .NET MAUI와 같은 선택적 workload를 관리합니다.
donet restore : project에 대한 의존성을 download 합니다.
dotnet build : .NET Project를 build(compile)합니다. .NET 8에서는 --tl라는 새로운 option을 추가했으며 이를 통해 build가 수행중인 작업에 대한 실시간 정보를 확인할 수 있습니다. 좀더 자세한 사항은 dotnet build command - .NET CLI | Microsoft Learn 이곳을 참고하시기 바랍니다.
dotnet build-server : build에 의해 시작된 server와의 상호작용을 수행합니다.
dotnet msbuild : MS Build Engine명령을 실행합니다.
dotnet clean : build로 생성되는 임시 folder를 삭제합니다.
dotnet test : project에 대한 단위 test를 build 하고 실행합니다.
dotnet run : project를 build하고 실행합니다.
dotnet pack : project에 대한 NuGet package를 생성합니다.
dotnet publish : 의존성 또는 self-contained application과 함께 project를 build하고 게시합니다. .NET 7및 그 이전 version에서는 배포시 Debug의 설정이 기본이었으나 .NET 8부터는 Release설정이 기본으로 게시합니다.
dotnet add : project에 package 혹은 class library에 대한 참조를 추가합니다.
dotnet remove : project에 대한 package 혹은 class library 참조를 삭제합니다.
dotnet list : project에 참조된 package 또는 class library를 listing 합니다.

(5) Self-contained app 게시하기

위에서 만든 cross-platform console app인 DotNetEverywhere를 게시하려면 terminal에서 DotNetEverywhere project가 있는(csproj가 있는) folder로 이동한 뒤 다음과 같은 명령을 내려 project를 build 하고 self-contained release version으로 Windows 10에서의 console application을 게시하도록 합니다.

dotnet publish -c Release -r win10-x64 --self-contained

이렇게 하면 build engine은 필요한 모든 package를 복구하고 project source code를 assembly DLL로 compile 하여 publish folder를 만들어 저장하게 됩니다.

Determining projects to restore...
All projects are up-to-date for restore.
DotNetEverywhere -> C:\Users\w10tsp\DotNetEverywhere\bin\Release\net7.0\win10-x64\DotNetEverywhere.dll
DotNetEverywhere -> C:\Users\w10tsp\DotNetEverywhere\bin\Release\net7.0\win10-x64\publish\

이어서 아래 명령을 추가로 사용해 macOS와 다양한 Linux에서의 release version으로 게시하도록 합니다.

dotnet publish -c Release -r osx-x64 --self-contained
dotnet publish -c Release -r osx.11.0-arm64 --self-contained
dotnet publish -c Release -r linux-x64 --self-contained
dotnet publish -c Release -r linux-arm64 --self-contained

필요하다면 위와 같은 명령들은 PowerShell과 같은 script 언어를 사용해 자동화하고 cross-platform인 PowerSheel Core를 사용해 모든 OS상에서 script file을 실행할 수 있습니다. 이는 그저 위의 명령들을 저장한 .ps1 확장자 file을 만들고 file을 실행하기만 하면 됩니다. PowerShell에 관해서는 아래 link를 통해 더 자세한 정보를 확인하실 수 있습니다.

cs11dotnet7/docs/powershell at main · markjprice/cs11dotnet7 · GitHub

GitHub - markjprice/cs11dotnet7: Repository for the Packt Publishing book titled "C# 11 and .NET 7 - Modern Cross-Platform Devel

Repository for the Packt Publishing book titled "C# 11 and .NET 7 - Modern Cross-Platform Development Fundamentals" by Mark J. Price - GitHub - markjprice/cs11dotnet7: Repository for the ...

github.com

위 명령을 실행한 뒤 Windows 탐색기를 열어 'DotNetEverywhere\bin\ Release\net7.0' folder로 이동해 보면 다섯 가지 OS에 대한 output folder가 생성되어 있음을 확인하실 수 있습니다.

'win10-x64' folder안에서 publish folder를 선택해 보면 Microsoft.CSharp.dll과 같은 필요한 모든 assembly가 저장되어 있음을 볼 수 있으며 이중 DotNetEverywhere.exe file을 선택하면 대략 file의 크기가 151 KB정도 됨을 보실 수 있습니다.

현재 OS가 Windows라면 해당 file을 double click 하여 program을 실행하고 그 결과를 확인해 볼 수 있습니다.

I can run everywhere!
OS Version is Microsoft Windows NT 10.0.19045.0.
I am Windows 10.
Press ENTER to stop me.

참고로 publish folder의 전체 크기는 대략 70MB 정도 됩니다. 각 OS별로 만들어진 publish folder를 필요한 OS에 복사하고 실행하면 아마도 정상적으로 실행됨을 알 수 있을 것입니다. 이는 console app이 .NET application에 대한 self-contained 배포판이기 때문입니다.

예제에서는 console app을 사용했지만 ASP.NET Core website나 web service 또는 Windows Forms나 WPF app과 같은 것들도 쉽게 만들 수 있습니다. 물론 이때도 Linux나 macOS가 아닌 Windows computer를 위한 Windows desktop app을 배포할 수도 있습니다.

(6) 단일 file app 게시하기

단일 file로서 게시하고자 한다면 게시할 때 flag를 지정할 수 있습니다. .NET 5에서 단일 file app은 Windows와 macOS에서 사실상 기술적으로 단일 file 배포가 불가능했기 때문에 주로 Linux에 집중되었습니다. 그러나 .NET 6 이후에부터는 Windows에서도 적절한 단일 file app을 만들 수 있게 되었습니다.

만약 app을 실행하고자 하는 computer에 적절한 version의 .NET이 설치되어 있다면 app을 게시할 때 아래와 같이 확장 flag를 사용해 self-contained가 필요하지 않고 단일 file로서 배포(가능하다면)하고자 함을 알려줄 수 있습니다.

dotnet publish -r win10-x64 -c Release --no-self-contained /p:PublishSingleFile=true

위와 같이 하면 2개의 file이 생성되는데 하나는 exe, 다른 하나는 pdb입니다. exe는 실행가능한 file을 의미하며 pdb는 program debug database로서 debugging에 필요한 정보를 담고 있습니다.

macOS상에서 게시된 application애 대한 exe는 존재하지 않으므로 osx-x64와 같은 명령을 사용해야 하며 생성된 file에는 확장자가 존재하지 않을 것입니다.

만약 pdb file마저도 exe안으로 포함시키고자 한다면 assembly와 함께 배포되도록 해야 하며 그러기 위해서 csproj file에서 <PropertyGroup> 요소 안에 <DebugType> 요소를 추가하고 여기에 embedded를 아래와 같이 설정합니다.

<RuntimeIdentifiers>
	win10-x64;osx-x64;osx.11.0-arm64;linux-x64;linux-arm64
</RuntimeIdentifiers>
<DebugType>embedded</DebugType>

그러나 대상 computer에 .NET이 설치되어 있지 않은 상태라면 Linux의 경우 단 2개의 file만을 필요로 하지만 Windows라면 coreclr.dll, clrjit.dll, clrcompression.dll 그리고 mscordaccore.dll과 같은 추가적인 file이 필요합니다.

terminal에서 아래 명령을 통해 Windows 10용 console app의 self-contained release version을 build 합니다.

dotnet publish -c Release -r win10-x64 --self-contained /p:PublishSingleFile=true

그리고 DotNetEverywhere\bin\Release\net7.0\win10-x64\publish foler에서 DotNetEverywhere.exe file을 선택합니다. 그러면 해당 file의 크기가 거의 65MB 정도로 커지게 되는 것을 알 수 있습니다. 또한 pdb file은 11KB 정도인데 이는 system에 따라 크기가 달라질 수 있습니다.

(7) App trimming을 사용한 app size 줄이기

.NET app을 self-contained app으로 배포하는 데 있어서 한 가지 문제점은 .NET library에서 너무 많은 용량을 차지한다는 것이며 특히 문제는 모든 .NET Library를 brwoser에서 내려받아야 하는 Blazor WebAssembly component가 문제가 될 수 있고 이러한 여러 가지 이유로 size를 줄여줄 필요가 있습니다.

그리고 이러한 문제는 배포 시 사용하지 않는 assembly를 packaging에서 제외하도록 함으로써 해결할 수 있습니다. .NET Core 3.0에서 도입된 app trimming system은 code에서 필요한 assembly를 식별하고 필요하지 않은 것들을 제거할 수 있습니다. 이를 copyused trim mode라고 합니다.

.NET 5에서 trimming은 개별 type을 제거하고 심지어 assembly안에서 사용되지 않는 method등의 member를 제거할 수도 있습니다. template에 의해 생성된 기본 console app의 경우 trimming된 System.Console.dll assembly는 대략 60KB에서 30KB로 줄어드는데 .NET 5에서 당시 이 기능은 실험적인 기능이라 기본적으로 사용되지 않도록 disable되어 있습니다.

.NET 6에서 Microsoft는 자신들의 library에 주석을 추가하여 어떤 식으로 안전하게 trimming 할 수 있는지를 나타내도록 하였으며 이에 따라 type과 member의 trimming이 기본적으로 사용되도록 적용되었고 이를 link trim mode라고 합니다.

.NET 7에서 Microsoft는 link를 full로 copyused를 partial로 명칭을 변경하였습니다.

문제는 trimming이 사용되지 않는 assembly, type, member 등을 얼마나 잘 식별하느냐 하는 것입니다. 만약 code가 동적인 것, 예를 들어 reflection과 같은 것이라면 정확하게 작동하지 않을 수 있고 이것 때문에 Microsoft는 수동적인 조정이 가능하도록 하였습니다.

● Assembly 수준 trimming 사용

Assembly 수준의 trimming을 사용하는 데는 2가지 방법이 있습니다. 첫 번째는 csproj(project file)에 아래와 같은 요소를 추가하는 것입니다.

<PublishTrimmed>true</PublishTrimmed>

두 번째는 게시할 때 아래와 같이 flag를 사용하는 것입니다.

dotnet publish -c Release -r win10-x64 --self-contained -p:PublishTrimmed=True

● Type 및 member수준의 trimming 사용

여기에도 2가지 방법이 있는데 첫 번째는 위의 예와 마찬가지로 아래의 요소를 추가하는 것이며

<PublishTrimmed>true</PublishTrimmed>
<TrimMode>Link</TrimMode>

두 번째 방법으로 flag를 사용하는 것입니다.

dotnet publish ... -p:PublishTrimmed=True -p:TrimMode=Link

.NET 6에서 link trim mode는 기본적으로 사용할 수 있으므로 assembly수준의 trimming을 의미하는 copyuse와 같은 다른 trim mode를 사용하고자 하는 경우일 때만 swich를 지정하면 됩니다.

(8) build artifact가 생성되는 위치 조정하기

일반적으로 각 project는 자신만의 obj와 bin folder를 가지고 있어서 여기에 build 동안의 임시 file이 생성되며 특히 bin은 배포를 위한 file이 생성됩니다. .NET 8에서는 필요하다면 obj와 bin에 생성되는 file의 위치를 변경할 수도 있는 기능을 도입하였습니다.

project가 존재하는(*.csproj file이 존재하는) folder에서 아래와 같이 명령을 내려줍니다.

dotnet new buildprops --use-artifacts

그러면 특별한 경우가 아닌한 다음과 같이 message가 표시되며

해당 folder에는 'Directory.Build.props'이름의 file이 표시됩니다. file은 다음과 같은 makeup으로 저장되어 있습니다.

<Project>
  <!-- See https://aka.ms/dotnet/msbuild/customize for more details on customizing your build -->
  <PropertyGroup>

    <ArtifactsPath>$(MSBuildThisFileDirectory)artifacts</ArtifactsPath>

  </PropertyGroup>
</Project>

위의 설정은 build process가 시작되면 그에 따른 folder가 artifacts 이름의 folder안에 생성됨을 의미합니다. 따라서 project를 build해 보면

bin과 obj folder가 위와 같이 생성되어 있음을 확인할 수 있습니다.

(9) Native ahead-of-time compilation

Native AOT는 .NET이 설치되어 있지 않은 환경에서의 실행을 위해 Self-contained 형태로 assembly를 생성하고 그것을 native code로 compile하여 더 빠르게 실행하고 더 적은 memory를 사용할 수 있도록 합니다.

즉, runtime에서 JIT(Just In Time) compiler를 사용하는 대신 배포시점에 IL code를 native code로 compile하는 것인데 위에서 설명한 이점을 얻을 수 있는 대신 Windows x64나 Linux Arm과 같이 특정한 runtime환경이 지정되어야 합니다.

native AOT는 게시시점에 발생하므로 현재 project가 AOT를 사용하도록 설정되어 있다고 하더라도 debugging의 목적으로 실행하는등의 동작시에는 여전히 native AOT가 아닌 runtime JIT compiler를 사용하게 됩니다.

다만 native AOT와 호환되지 않는 일부 기능은 disable되거나 예외를 발생시킬 수 있으며 source 분석기가 활성화되어 잠재적인 code 비호환성에 대한 경고를 표시하게 됩니다.

● Native AOT 의 한계

Native AOT는 다음과 같은 일부 한계가 존재합니다.

Assembly의 동적 loading이 없습니다.
System.Reflection.Emit을 사용하는 것과 같은 runtime code 생성이 없습니다.
Trimming이 필요하며 여기에는 자체적인 한계가 존재합니다.
필요한 모든 library를 포함하는 Self-contained으로만 배포되므로 배포크기가 커질 수 있습니다.

물론 자체 assembly에서 위의 기능을 사용하지 않을 수 있지만 .NET 자체의 주요부분은 해당 기능을 사용합니다. 예를 들어 ASP.NET Core MVC(Controller를 사용하는 Web API service를 포함해)와 EF Core는 자신들의 기능을 구현하기 위해 runtime code 생성을 수행합니다.

.NET Team은 native AOT와 .NET과의 더 나은 호환성을 위해 노력중이지만 Minimal API를 사용하는 경우에만 .NET 8에서 ASP.NET Core에 대한 기본적인 지원을 포함하고 있으며 EF Core는 지원하지 않습니다.

Native AOT 게시 process는 지원하지 않는 기능을 사용하는 경우 이를 알려주기 위한 code 분석기를 포함하고 있지만 아직까지 모든 package가 이러한 기능이 잘 작동하도록 anotate되어 있지는 않습니다. Type또는 member가 AOT를 지원하지 않음을 나타내는데 사용된 가장 일반적인 annotation은 [RequiresDynamicCode] attribute입니다.

AOT가 나타내는 위험성에 관한 자세한 사항은 아래 link를 참고하시가 바랍니다.

Introduction to AOT warnings - .NET | Microsoft Learn

Introduction to AOT warnings - .NET

Learn why warnings might be produced when publishing an application as Native AOT, how to address them, and how to make the application "AOT compatible."

learn.microsoft.com

● Reflection 과 native AOT

Reflection는 runtime에서 type의 metadata를 검사하고 member의 동적호출과 code생성을 목적으로 자주사용됩니다.

Native AOT는 일부 reflection기능을 허용하긴 하지만 native AOT compilation process동안 수행되는 trimming은 type이 reflection을 통해서만 접근가능한 member를 가지고 있는지의 여부를 정적으로 판단할 수 없고 따라서 이들 member는 AOT에 의해 제거될 수 있고 때문에 runtime예외를 일으킬 수 있습니다.

개발자는 자신의 type에 [DynamicallyAccessedMembers]으로 annotate함으로서 해당 member가 reflection을 통해서만 접근될 수 있고 때문에 trimming하지 않은 상태로 남아있어야 함을 표시할 수 있습니다.

● Native AOT의 요구사항

Native AOT는 운영체제에 따라 다음과 같은 추가적인 요구사항이 뒤따릅니다.

Windows	전체 기본 component를 가진 Visual Studio 2022 Desktop development with C++ workload 설치
Linux	compiler toolchain과 .NET runtime이 의존하는 library를 위해 developer package를 설치해야 합니다. 예를 들어 Ubuntu 18.04 이상에서 다음과 같은 명령을 내려줍니다. sudo apt-get install clang zlib1g-dev

Cross-platform native AOT 배포는 지원하지 않습니다. 즉, 배포하고자 하는 특정 운영제제상에서 배포되어야 합니다. 때문에 Linux에서의 native AOT project 배포본은 Windows상에서 실행될 수 없습니다. 물론 그 반대도 마찬가지 입니다.

● Project에 native AOT 적용하기

Project에서 native AOT 배포를 적용하려면 project (csproj) file에 다음과 같이 <PublishAot>요소를 추가해야 합니다.

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
    <PublishAot>true</PublishAot>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>
</Project>

● Native AOT project build 하기

Visual Studio를 통해 native AOT 호환 project를 생성하려면 다음과 같이 'Enable native AOT publish'를 check합니다.

dotnet CLI를 통해서는 다음과 같이 --aot option을 통해 project를 생성할 수 있습니다.

dotnet new console --aot

위의 방법으로 생성된 project file에서는 PublishAot와 InvariantGlobalization요소가 추가됩니다.

<PropertyGroup>
  <OutputType>Exe</OutputType>
  <TargetFramework>net8.0</TargetFramework>
  <ImplicitUsings>enable</ImplicitUsings>
  <Nullable>enable</Nullable>
  <PublishAot>true</PublishAot>
  <InvariantGlobalization>true</InvariantGlobalization>
</PropertyGroup>

.NET 8의 Console App project에서는 명시적으로 invariant globalization를 true로 설정하는 것은 새로운 기능으로 이는 app이 특정한 문화권에 구애받지 않고 전세계 어디서든 배포되고 동일한 동작을 수행하도록 합니다. 만약 이 요소의 설정을 false로 하거나 요소자체를 누락한다면 현재 computer의 문화권을 기본으로 설정하게 됩니다. 이에 관한 좀더 자세한 사항은 아래 link를 참고하시기 바랍니다.

runtime/docs/design/features/globalization-invariant-mode.md at main · dotnet/runtime · GitHub

이어 program.cs에서는 기존의 문을 모두 삭제하고 현재 문화권과 OS version을 표시하도록 수정합니다.

using System.Globalization;

Console.WriteLine("현재 문화권 설정: {0}", CultureInfo.CurrentCulture. DisplayName);
Console.WriteLine("운영체제: {0}", Environment.OSVersion);

Console.Write("종료하려면 아무키나 누르십시오...");
Console.ReadKey(intercept: true);

project를 실행하고 결과를 확인합니다.

하지만 native AOT는 배포시점에 적용되므로 build된 실행 file은 여전히 JIT compiler를 사용합니다.

● Native AOT project 배포하기

개발중에 정상적으로 작동하는 console app이라도 trimming하지 않고 JIT compile하게 되면 이를 native AOT를 사용해 배포하는 것은 실패할 수 있습니다. 일단 trimming이 이루어지고 JIT compile되어야 native AOT 배포를 사용할 수 있는 상태가 됩니다.

배포동안에 project가 AOT에 관한 어떠한 경고도 표시하지 않는다면 해당 app은 AOT 배포후에 잘 작동하리라고 기대할 수 있습니다.

project를 배포하려면 다음과 같이 명령을 내려줍니다.

배포실행 후 'bin\Release\net8.0\win-x64\publish' folder를 보면 실행 file이 1.2M가 넘는것을 확인할 수 있습니다. 참고로 pdb file은 debuging에 사용되는 file입니다. 여기에 있는 해당 exe file을 실행하면 이전과 정확히 같은 동작을 수행한다는 것을 확인할 수 있습니다.

다시 program.cs로 돌아와 이번에는 동적 code를 위한 namespaces를 아래와 같이 추가합니다.

using System.Reflection; // To AssemblyName.
using System.Reflection.Emit; // To AssemblyBuilder.

using System.Globalization;

그리고 동적 assembly builder를 생성하도록 아래와 같이 code를 추가하고

AssemblyBuilder ab = AssemblyBuilder.DefineDynamicAssembly(new AssemblyName("assemblyName"), AssemblyBuilderAccess.Run);

Console.WriteLine("현재 문화권 설정: {0}", CultureInfo.CurrentCulture. DisplayName);

다시 배포를 시도하면 아래와 같은 경고 message를 보게 됩니다.

대략적인 내용은 .NET team 이 [RequiresDynamicCode] attribute를 적용한 DefineDynamicAssembly method의 호출에 관한 것입니다.

native AOT에 관한것은 아래 linki에서 좀더 자세하게 알아보실 수 있습니다.

Native AOT deployment overview - .NET | Microsoft Learn

Native AOT deployment overview - .NET

Learn what Native AOT deployments are and why you should consider using it as part of the publishing your app with .NET 7 and later.

learn.microsoft.com

4. .NET assembly decompile

C#을 학습하기 위한 가장 좋은 방법 중에 하나는 수준 높은 다른 누군가가 만들어 놓은 code를 보는 것입니다.

물론 학습목적이 아닌 자신의 library나 application에 사용할 목적으로 code를 복사하기 위한 decompile을 시도해 볼 수도 있을 것입니다. 어쨌건 decompile은 그들의 지적재산권을 침해하는 것으로 귀결될 수 있으므로 주의해야 합니다.

(1) Visual Studio 2022의 ILSpy extension을 사용한 decompile

.NET assembly의 decompile은 ILSpy와 같은 도구를 통해 가능합니다. Visual Studio에서 Extensions -> Manage Extensions menu를 선택합니다.

왼쪽 category에서 online을 선택하고 search에 'ILSpy'를 입력하고 ILSpy 2022 선택한 뒤 download button을 눌러줍니다.

Download가 완료되면 Visual Studio를 닫아 내려받은 ILSpy 2022의 설치를 완료합니다.

Visual Studio를 재시작하고 csStudy07 project를 열어줍니다. 그리고 solution explorer에서 DotNetEverywhere project를 mouse오른쪽 click한뒤 'Open output in ILSpy'를 선택합니다.

잠시가다리면 ILSpy가 열리게 되는데 decompile 할 언어설정이 C#으로 되어 있는지 확인합니다. 왼쪽 화면에는 'Assemblies navigation'화면이 보이는데 여기에서 DotNetEverywhere를 확장합니다. 이어서 '{ }'와 Program을 차례로 확장한 뒤 '<Main>$(string[]) : void'부분을 click 하여 compiler가 생성한 Program class와 보간문자열이 어떻게 작동하는지를 나타내는 <Main>$ method를 표시합니다.

계속해서 ILSpy에서 File -> Open menu를 선택한 뒤 'DotNetEverywhere/bin/Release/net7.0/linux-x64' foler에서 System.Linq.dll file을 열어봅니다. 그리고 Assemblies tree에서 'System.Linq ~'와 System.Linq namespace, Enumerable class를 차례로 확장한 뒤 'Count<TSource>(this IEnumerable<TSource>) : int'를 선택합니다.

Count method를 보면 몇 가지 배워볼 만한 점을 발견할 수 있습니다.

source 매개변수를 확인하고 null이라면 ArgumentNullException 예외를 발생시키도록 합니다.
source는 좀 더 효휼적으로 읽어 들일 수 있는 자체의 Count속성으로 구현할 수 있는 Interface를 확인합니다.
source의 모든 item을 열거하고 counter를 증가시키는 마지막 method는 구현 효율성이 가장 낮습니다.

Count method의 source code를 확인하고

public static int Count<TSource>(this IEnumerable<TSource> source)
{
	if (source == null)
	{
		ThrowHelper.ThrowArgumentNullException(ExceptionArgument.source);
	}
	if (source is ICollection<TSource> collection)
	{
		return collection.Count;
	}
	if (source is IIListProvider<TSource> iIListProvider)
	{
		return iIListProvider.GetCount(onlyIfCheap: false);
	}
	if (source is ICollection collection2)
	{
		return collection2.Count;
	}
	int num = 0;
	using IEnumerator<TSource> enumerator = source.GetEnumerator();
	while (enumerator.MoveNext())
	{
		num = checked(num + 1);
	}
	return num;
}

그다음 Intermediate Language (IL)에서 생성한 것과 동일한 code를 비교해 보기 위해 toolbar에서 C#에 대한 dropdownlist를 ILSpy로 변경합니다.

C# compiler가 source code를 IL code로 변환시킨다는 것만 알고 있으면 될 뿐 사실 IL code가 딱히 유용하지는 않습니다. 위의 source code만 가지고도 Count method가 인수에 대해 어떻게 null을 확인하는지 등을 알 수 있으므로 훨씬 유용하게 활용될 수 있습니다.

아래 link에서는 Visual Studio에서 ILSpy를 어떻게 사용할 수 있는지를 확인할 수 있습니다.

cs11dotnet7/docs/code-editors/vscode.md at main · markjprice/cs11dotnet7 · GitHub

GitHub - markjprice/cs11dotnet7: Repository for the Packt Publishing book titled "C# 11 and .NET 7 - Modern Cross-Platform Devel

Repository for the Packt Publishing book titled "C# 11 and .NET 7 - Modern Cross-Platform Development Fundamentals" by Mark J. Price - GitHub - markjprice/cs11dotnet7: Repository for the ...

github.com

(2) Visual Studio 2022를 통한 source link 보기

Decompile대신 Visual Studio에는 source link를 사용해 본래 source code를 볼 수 있는 기능을 가지고 있습니다.

csStudy07 solution에서 'SourceLinks'라는 Console app유형의 새로운 project를 생성하고 Program.cs에서 string변수를 선언하고 해당 변수가 가진 문자열의 수를 다른 변수에 할당하고 확인하는 문을 아래와 같이 추가합니다.

string name = "cliel";
int length = name.Count();

Console.WriteLine($"{name} has {length} characters.");

이때 Count method에서 mouse오른쪽 button을 click 하여 'Go To Implementation'을 선택합니다. 그러면 Count.cs이름의 source code file이 표시될 텐데 여기서 우리는 count와 관련된 다섯 개의 method가 Enumerable이라는 partial class에 구현되어 있음을 알 수 있습니다.

이러한 source links를 통해서도 위 예제와 같이 관리의 용이성을 위해 어떻게 partial class를 통해서 class를 나누는지와 같은 상황별 예시를 확인할 수 있기 때문에 decompile 하는 것만큼 많은 것을 배울 수 있습니다. ILSpy를 사용하는 경우에도 물론 Enumerable class에 대한 수천 개의 method를 모두 볼 수 있습니다.

아래 link를 통해서는 source links에 관한 더 많은 것과 얼마나 많은 NuGet package가 이를 지원할 수 있는지를 확인해 볼 수 있습니다.

Source Link and .NET libraries | Microsoft Learn

Source Link and .NET libraries

Best practice recommendations for using Source Link to improve debugging for .NET libraries.

learn.microsoft.com

만약 source link가 작동하지 않으면 아래 설정에서 source link의 설정여부를 확인해 보시기 바랍니다.

(3) 기술적으로 decompile을 막을 수 있는 방법은 없습니다.

누군가는 compile 된 code에서 decompile을 막을 수는 없을까 하는 의문을 제기할 수도 있을 것입니다. 이 질문에 정확하게 답하자면 '그렇게 할 수 없다.'라고 할 수 있습니다. 대신 Dotfuscator와 같은 도구를 사용해 code를 읽기 어렵게 만들 수는 있지만 decompile자체는 막을 수 없습니다.

모든 compile 된 application은 동작의 대상이 되는 platform, OS 그리고 hardware에 대한 명령을 포함하고 있습니다. 이들 명령은 기능적으로 본래 source code와 일치하지만 사람에게만 읽기 어렵게 만들수 있을 뿐입니다.

Source code를 보호하고자 한다면 여기에 debugger을 연결하고 단계적으로 code를 통과하는 것도 막을 수 있습니다. compile된 application이 pdb file을 가지고 있다면 debugger를 연결하고 구문을 한 줄씩 실행시킬 수도 있습니다. pdb file이 없어도 여전히 debugger를 연결하고 code가 어떻게 작동하는지를 알 수 있습니다.

사실 decompile에 관한 이러한 내용은 C#, Visual Basic, F#과 같은 .NET언어 뿐만 아니라 C, C++, Delphi 및 assembly 언어(debugging에 연결하거나 disassembled 또는 decompile 될 수 있는)에도 해당하는 사실입니다. 아래 표는 해당 목적을 위해 사용하는 일부 도구를 나타내고 있습니다.

목적	도구	설명
Debugger	SoftICE	운영체제(일반적으로 VM) 아래에서 실행됩니다.
Debugger	WinDbg	다른 debugger보다 Windows data 구조에 관한 더 많은 것을 이해하는데 유용한 도구입니다.
Disassembler	IDA Pro	malware 분석등에 사용됩니다.
Decompiler	HexRays	IDA Pro의 plugin이며 C app을 decompile합니다.
Decompiler	DeDe	Delphi app을 decompile합니다.
Decompiler	dotPeek	JetBrains사에서 만든 것으로 .NET decompiler입니다.

다른 누군가의 software를 Debugging, disassembling, decompiling 하는 행위는 license동의에 반하며 불법일 수 있습니다. 기술적인 방법으로 지적재산권을 보호하는 대신 법이 유일단 수단이 될 수 있습니다.

5. .NET Framework 에서 .NET으로의 이식

기존 .NET Framework 개발자라면 아마도 기존의 application을 .NET으로 전환하고자 할 수 있을 것입니다. 하지만 정말 .NET으로의 전환이 가장 좋은 방법인지는 심도 있게 고려해봐야 합니다. 단지 .NET으로의 이식만이 최상의 방법이 되지는 않습니다.

예를 들어 .NET Framework 4.8에서 동작하는 사용자가 그리 많지 않은 website project가 있습니다. 그러면 해당 website는 최소한의 hardware상에서 방문자 traffic은 충분히 제어되고 작 잘 동할 수 있을 텐데 이것을 .NET platform으로 전환하는데 잠재적으로 수개월을 소요하는 것은 시간낭비가 될 수 있습니다. 하지만 website가 현재 다수의 고비용 Windows Server가 필요하다면 더 비용이 적은 Linux server로 migration 할 수 있습니다.

(1) 전환 가능한 것

.NET은 Windows, macOS, Linux에 대한 아래 type의 application을 지원하고 있으며 때문에 전환이 가능합니다.

Razor Pages와 MVC를 포함한 ASP.NET Core web site
Web API, Minimal API, OData를 포함하는 ASP.NET Core web service(REST/HTTP)
gRPC, GraphQL, SignalR을 포함하는 ASP.NET Core-hoste
명령행 interface인 Console App포함

.NET은 Windows에 대한 아래 Type의 application을 지원하고 있으며 운영에 적합이 가능합니다.

Windows Forms applications
Windows Presentation Foundation (WPF) applications

.NET은 cross-platform desktop과 mobile device에 대한 아래 type의 application을 지원하고 있으며 전환이 가능합니다.

Mobile iOS와 Android를 위한 Xamarin app
Desktop Windows와 macOS 또는 mobile iOS와 Android를 위한 .NET MAUI

.NET은 아래 legacy Microsoft project에 대한 지원을 하지 않으며 전환이 불가능합니다.

ASP.NET Web Forms website. (ASP.NET Core Razor Page 또는 Blazor로의 재구현이 필요합니다.)
Windows Communication Foundation (WCF ) service (단, 요구사항에 따라 사용가능한 open-source project인 CoreWCF가 존재합니다.). (ASP.NET Core gRPC service로의 재구현이 필요합니다.)
Silverligth application. (Blazor 또는 .NET MAUI로의 재구현이 필요합니다.)

Silverlight와 ASP.NET Web Forms application은 .NET으로의 전환이 불가능하며 기존의 Windows Forms와 WPF application을 WIndows전용의 .NET으로 전환하면 이에 따른 새로운 API와 고성능에 대한 이점을 가져갈 수 있습니다.

Legacy ASP.NET MVC web application과 ASP.NET Web API web service역시 .NET으로의 전환이 가능하며 Windows, Linux 또는 macOS에서 host가 가능합니다.

(2) 전환해야 하는 것

전환이 가능하다면 그렇게 하는 것이 맞을까? 그렇게 한다면 어떤 이익을 얻을 수 있을까? 전환함으로써 얻을 수 있는 장점으로는 대략 다음과 같이 정리할 수 있습니다.

Website와 webservice에 대한 Linux, Docker 또는 Kubernetes로의 배포 : 해당 OS들은 website와 web service platform으로서 매우 가볍고 특히 Windows Server와 비교해서는 훨씬 비용 효과적이라고 할 수 있습니다.
IIS와 System.Web.dll에 대한 의존성 제거 : Windows Server로의 배포를 계속한다고 하더라도 ASP.NET Core는 Kestrel web server(또는 다른 것도 마찬가지)에서 가벼우면서도 고성능의 hosting이 가능합니다.
명령줄 도구 : 개발자와 관리자가 자신들의 작업을 자동화하기 위해 사용하는 도구는 종종 console application으로 build 되는데 cross-platform에서 동작가능한 단일 도구는 그 자체로 매우 유용하게 사용될 수 있습니다.

(3) .NET Framework와 .NET의 차이

이들 사이에는 대략 3가지 핵심적인 차이가 존재합니다.

.NET	.NET Framework
NuGet package로 배포되어 있으며 각 application은 필요한 .NET version의 자체 app local 복사를 통해 배포될 수 있습니다.	System전반에 배포되어 있으며 assembly들은 공유됩니다.(GAC-Global Assembly Cache)
Component 계층으로 작게 나누어져 있으므로 최소한의 배포가 가능합니다.	단일적이며 획일적인 배포만이 가능합니다.
ASP.NET Web Forms와 같은 고전 기술과 AppDomains, .NET Remoting, binary serialization과 같은 비 cross-platform 기능들이 제거되었습니다.	.NET에서의 ASP.NET Core MVC와 같은 비슷한 기능뿐만 아니라 ASP.NET Web Forms와 같은 고전적인 기술까지도 남아 있습니다.

(4) .NET Portability Analyzer

Microsoft는 기존의 application에 대한 이식성의 보고서를 생성하는 유용한 도구를 지원하고 있습니다. 아래 link에서 해당 도구의 시연장면을 볼 수 있습니다.

A Brief Look at the .NET Portability Analyzer | Microsoft Learn

A Brief Look at the .NET Portability Analyzer

.NET is going through some monumental changes! It is often difficult to even begin to think about how to port our particular code to the various flavors of .NET. In this video Taylor Southwick and Connie Yau spend some time discussing a great tool that wil

learn.microsoft.com

(5) .NET Upgrade Assistant

Legacy project를 .NET으로 upgrade 하기 위한 가장 최신의 도구로는 .NET Upgrade Assistant가 있습니다. 현재 다음과 같은 .NET Framework project type을 지원하고 있으며 향후에는 더 추가될 것으로 예상됩니다.

ASP.NET MVC
Windows Forms
WPF
Console Application
Class Library

전역 dotnet 도구를 통해 .NET Upgrade Assistant를 설치하려면 아래의 명령을 내려줍니다.

dotnet tool install -g upgrade-assistant

아래 link를 통해 .NET Upgrade Assistant에 대한 더 자세한 내용과 사용법을 확인할 수 있습니다.

Overview of the .NET Upgrade Assistant - .NET Core | Microsoft Learn

Overview of the .NET Upgrade Assistant - .NET Core

Introducing the .NET Upgrade Assistant tool that helps upgrade .NET, .NET Core, or .NET Framework apps to the latest version of .NET.

learn.microsoft.com

(6) 비 .NET Standard library 사용

NuGet package는 .NET Standard 또는 .NET 7과 같은 version을 통해 compile 되지 않은 것이라 하더라도 대부분 .NET에서 사용될 수 있습니다. 만약 공식적으로 .NET Standard를 지원하지 않는 package라고 nuget.org web page에 표시된 package가 있어도 단정적으로 사용 못할 것이라 포기할 필요는 없습니다. 일단 시도해 보면서 되는지 안되는지의 여부를 판단해도 됩니다.

예를 들어 아래와 같이 문서화된 것으로, Dialect Software LLC에서 제작된 행렬처리를 위한 사용자 지정 collection package는 .NET Core나 .NET 7이 존재하기 훨씬 이전인 2013년도가 마지막 update로 확인됩니다.

NuGet Gallery | DialectSoftware.Collections.Matrix 1.0.0

DialectSoftware.Collections.Matrix 1.0.0

Provides matrix data structure suitable for storing elements in an n-dimensional cartesian coordinate system of positive integers. example: Axis x = new Axis("x", 0, 100, 1); Axis y = new Axis("y", 0, 10, 1); Matrix<long> matrix = new Matrix<long>(new []{x

www.nuget.org

따라서 해당 package는 .NET Framework로 build 된 것이며 이와 같은 package가 .NET Standard에서만 가능한 API만 사용하는 경우 .NET project에서도 사용할 수 있습니다.

AssembliesAndNamespaces project에서 아래와 같이 Dialect Software의 package를 참조 추가합니다.

  <ItemGroup>
    <PackageReference Include="DialectSoftware.Collections.Matrix" Version="1.0.0" />
  </ItemGroup>

그리고 Program.cs에서 DialectSoftware.Collections과 DialectSoftware.Collections.Generics를 import 하고 아래와 같이 Axis와 Matrix<T>의 instance를 생성하고 값을 채워 넣은 다음 해당 값을 표시하는 문을 추가합니다.

Axis x = new Axis("x", 0, 100, 1);
Axis y = new Axis("y", 0, 10, 1);

Matrix<long> matrix = new Matrix<long>(new[] { x, y });

int i = 0;
for (; i < matrix.Axes[0].Points.Length; i++)
{
    matrix.Axes[0].Points[i].Label = "x" + i.ToString();
}

i = 0;
for (; i < matrix.Axes[1].Points.Length; i++)
{
    matrix.Axes[1].Points[i].Label = "y" + i.ToString();
}

foreach (long[] c in matrix)
{
    matrix[c] = c[0] + c[1];
}

foreach (long[] c in matrix)
{
    Console.WriteLine("{0},{1} ({2},{3}) = {4}", matrix.Axes[0].Points[c[0]].Label, matrix.Axes[1].Points[c[1]].Label, c[0], c[1], matrix[c]);
}

Project를 실행하면 다음과 같은 결과를 표시할 것입니다.

6. Preview 기능 사용하기

Microsoft는 주기적으로 runtime, 언어 compiler, API library등 .NET의 많은 부분에 전역적으로 영향을 미치는 새로운 기능을 제공합니다. 그런데 실질적으로 Microsoft가 기능에 필요한 대부분의 작업을 완료했다고 하더라도 .NET release에 대한 주기 때까지는 배포가 이루어지지 않을 것입니다. 문제는 이렇게 되면 실전에서 적절한 test를 하기에는 너무 늦다는 것입니다.

따라서 .NET 6부터 Microsoft는 GA(general availability) release에서는 preview 기능을 포함하게 되었습니다. 개발자는 이들 미리 보기 기능을 선택하고 Microsoft에게 feedback을 제공할 수 있습니다. 최신 GA release는 모두가 사용할 수 있습니다.

Preview 기능에 관한 내용임에 주의해야 합니다. .NET 혹은 Visual Studio에 대한 preview version과는 다릅니다. Microsoft는 Visual Studio와 .NET에 대한 preview version을 개발자들로부터 feedback을 얻고자 개발 중에 release 하며 그런 뒤 최종 GA를 release 합니다. 이때 GA가 모두가 사용가능한 기능이 되는 것입니다. GA이전에는 새로운 기능을 경험해 볼 수 있는 방법은 preview version을 설치하는 것입니다. Preview 기능은 GA release와 함께 설치되며 선택적으로 사용가능해야 하므로 다르다고 할 수 있습니다.

예를 들어 Microsoft는 .NET SDK 6.0.200를 2022년 02월에 release 했는데 이것은 C# 11 compiler를 preview 기능으로서 포함시켰습니다. 이는 .NET 6 개발자가 선택적으로 언어의 version을 preview로 설정할 수 있었음을 의미하며 이것으로 raw string literal과 required keyword 같은 C# 11 기능을 사용해 볼 수 있었습니다.

Preivew 기능은 production code에서는 지원하지 않으며 최종 release전에 대폭적인 변화가 있을 가능성이 있습니다. 따라서 오로지 test목적으로만 사용해야 합니다.

(1) Preview 기능이 필요한 경우

[RequiresPreviewFeatures] attribute는 사용하는 assembly, type 또는 member를 나타내는 데 사용되며 Code analyzer는 해당 assembly를 scan 하고 필요하다면 경고를 생성하게 됩니다. 만약 code에서 어떠한 preview 기능도 사용하지 않는다면 어떠한 경고 message도 보지 않게 될 테지만 그렇지 않다면 preview 기능을 사용한다는 경고를 해당 code를 사용하는 이에게 표시하게 됩니다.

(2) Preview 기능 사용

csproj(project file)에서 아래와 같이 preview 기능과 preview 언어 기능을 사용하기 위한 요소를 추가합니다.

<Nullable>enable</Nullable>
<EnablePreviewFeatures>true</EnablePreviewFeatures>
<LangVersion>preview</LangVersion>

[C# 12와 .NET 8] 6. Interface와 Class상속

클리엘 — Tue, 20 Feb 2024 09:11:32 +0900

이번 글을 통해서는 OOP(Object-Oriented Programming)을 사용한 하나의 개체에서 다른 새로운 type을 상속하는 기본 개념에 대해 알아볼 것입니다. 또한 generic을 사용하여 어떻게 code를 안전하게 만들고 성능을 높일 수 있는지, delegate와 event를 통해 type 간 message를 어떻게 교환할 수 있는지를 알아보고 참조와 값 type에 대한 차이점도 확인해 볼 것입니다. 공통기능에 대한 interface를 구현하고 기능을 재사용하기 위해 기반 class로부터 상속받는 파생 class를 만들 것이며 상속된 type member를 재정의하고 다형성(polymorphism)도 사용해 볼 것입니다. 또한 확장 method의 생성과 계층적으로 상속된 class간 변환에 대한 것들, 그리고 static code analyzer를 통해 어떻게 code를 개선할 수 있을지도 함께 살펴볼 것입니다.

1. Class library와 console application의 설정

이번 예제를 위해서는 2개의 project를 정의하는 것으로 시작해야 합니다. csStudy06 이라는 solution을 만들고 여기에 MyLibrary이름의 Class Library유형의 project와 MyApp이름의 Console App project를 추가합니다. 그리고 MyLibrary file에서 Person.cs file을 아래와 같이 추가합니다.

namespace MyLibrary
{
	public class Person
	{
		// 속성
		public string? Name { get; set; }
		public DateTime DateOfBirth { get; set; }
        
		// Method
		public void WriteToConsole()
		{
			Console.WriteLine($"{Name} was born on a {DateOfBirth:dddd}.");
		}
	}
}

MyApp project에서 MyLibrary project를 참조 추가하고 Program.cs에서 기존의 구문을 모두 삭제한 뒤 Person에 대한 instance개체를 생성하고 해당 개체의 정보를 console에 출력하는 문을 아래와 같이 추가합니다.

using MyLibrary;

Person kdh = new()
{
	Name = "김동희",
	DateOfBirth = new(year: 1980, month: 12, day: 01)
};

kdh.WriteToConsole();

예제를 실행하면 다음과 같은 결과를 표시할 것입니다.

2. 정적 method와 연산자 다중정의(overloading)

연산자의 동작은 일반적으로 사용되는 method가 아닌 동일한 type에 대한 2개의 instance에 적용되는 특별한 method에 대한 것입니다.

예를 들어 2개의 Person에 대한 intance에서 +나 × 와 같은 이항연산자를 적용해 둘의 Person instance를 결합하여 '결혼식'을 표현거나 '출산'과 같이 곱하여 특별한 결과를 가져오기 위한 뭔가를 수행할 수 있을 것입니다. 이러한 동작은 대부분 동작에 대한 의미가 가장 높은것에 따라 달라질 수 있습니다.

많은 경우에 비슷한 동작을 수행하는 정적 method와 instance method 둘다 구현하기도 합니다. 예를 들어 string type은 비교를 위한 Compare 정적 method와 CompareTo라는 instance method를 가지고 있습니다. 이는 type에서 더 높은 유연성을 제공함으로서 개발자가 type의 특정 기능을 사용하기에 적합한 방식을 선택할 수 있게 됩니다.

(1) Method를 통한 기능 구현

Person.cs에서 아래 2개의 field를 추가하여 Person이 결혼한 상태인지 누구랑했는지를 나타낼 수 있도록 합니다.

public List<Person> Spouses = new();
public List<Person> Children = new();
public bool Married => Spouses.Count > 0;

그 다음 아래와 같은 method를 추가하는데 하나는 instance, 다른 하나는 정적 method이며 Person끼리 혼인이 가능하도록 합니다.

public static void Marry(Person p1, Person p2)
{
  ArgumentNullException.ThrowIfNull(p1);
  ArgumentNullException.ThrowIfNull(p2);
  
  if (p1.Spouses.Contains(p2) || p2.Spouses.Contains(p1))
  {
    throw new ArgumentException(string.Format("{0}은(는) 이미 {1}와 혼인함", arg0: p1.Name, arg1: p2.Name));
  }
  
  p1.Spouses.Add(p2);
  p2.Spouses.Add(p1);
}

public void Marry(Person partner)
{
  Marry(this, partner);
}

정적 method에서는 p1과 p2이름의 parameter를 통해 Person 개체를 전달받고 있으며 이때 guard절을 통해 null여부를 확인하고 있습니다. 이 후 p1혹은 p2가 이미 혼인한 상태라면 예외를 발생시키고 그렇지 않으면 각각의 배우자로 서로를 저장하도록합니다. 물론 하나의 Person이 여러번의 혼인을 가능하게끔 할 수 있으며 그에 따라 예외가 발생하지 않도록 하는 것도 가능할 것입니다.

Instance method에서는 정적 method를 호출하는 것으로 되어 있으며 현재 Person(this)과 혼인 상대에 해당하는 Person을 매개변수로 전달합니다.

그리고 다음의 별도의 instance method도 추가하여 Person이 혼인한 상태면 그에 따른 배우자와 자식을 표시할 수 있도록 합니다.

public void OutputSpouses()
{
  if (Married)
  {
    Console.WriteLine($"{Name}은(는) {Spouses.Count}명과 혼인함:");

    foreach (Person spouse in Spouses)
    {
      Console.WriteLine($" {spouse.Name}");
    }
  }
  else
  {
    Console.WriteLine($"{Name}은(는) 아직 싱글");
  }
}

public void WriteChildrenToConsole()
{
  Console.WriteLine($"{Name}은(는) {Children.Count}명의 아이가 있음");
}

계속해서 아이를 갖게되는 경우를 위해 다음과 같은 instance method와 정적 method도 추가해 줍니다.

public static Person Procreate(Person p1, Person p2)
{
  ArgumentNullException.ThrowIfNull(p1);
  ArgumentNullException.ThrowIfNull(p2);
  
  if (!p1.Spouses.Contains(p2) && !p2.Spouses.Contains(p1))
  {
    throw new ArgumentException(string.Format("{0}은(는) 아직 {1}와 혼인상태가 아닙니다.", arg0: p1.Name, arg1: p2.Name));
  }
  
  Person baby = new()
  {
    Name = $"{p1.Name}와 {p2.Name}의 Baby",
    DateOfBirth = DateTime.Now
  };
  
  p1.Children.Add(baby);
  p2.Children.Add(baby);
  
  return baby;
}

public Person ProcreateWith(Person partner)
{
    return Procreate(this, partner);
}

Procreate 정적 method에서 생성할 Person 개체는 p1과 p2 매개변수로 전달되며 여기서 baby라는 새로운 Person개체는 p1과 p2의 이름으로 생성됩니다. 이는 이후에 반환된 baby의 Name속성을 통해 변경할 수 있는데 물론 세번째 매개변수를 추가하여 생성할 baby의 이름을 지정해주는 것도 가능하지만 후에 이진 연산자를 정의할 것이므로 세번째 매개변수를 가질 수 없으며 따라서 baby 참조만을 반환하고 호출 code에서 이름을 바꾸도록 할 것입니다.

baby개체는 부모에 해당하는 Person의 Children collection에 추가되고 반환될 것입니다. 이때 Class는 참조 type이므로 baby개체의 복사본이 아닌 memory에 저장된 baby개체의 참조가 저장됩니다. 참조 type과 값 type에 대한 자세한 사항은 추후에 살펴볼 것입니다.

ProcreateWith이름의 instance method에서 Person개체는 this와 함께 partner이름의 매개변수로 정적 method인 Procreate 로 전달되어 해당 method구현을 재사용하게 됩니다. 여기서 this keyword는 현재 class의 intance 참조를 의미하며 관련된 정적 method와 instance method는 서로 다른 이름을 사용하는 것이 관례입니다.

Program.cs에서는 세명의 Person개체를 생성하고 결혼식을 올린다음 서로에 대한 Children을 생성합니다. 이때 예제에서 문자열을 처리하는 것중에 backslash (\) 접미사가 사용된것에 주의합니다.

Person hong = new() { Name = "홍길동" };
Person kim = new() { Name = "김길순" };
Person lee = new() { Name = "이길영" };

hong.Marry(kim);

Person.Marry(hong, lee);
hong.OutputSpouses();
kim.OutputSpouses();
lee.OutputSpouses();

Person baby1 = hong.ProcreateWith(kim);
baby1.Name = "Hong-1baby";
Console.WriteLine($"{baby1.Name}아기가 {baby1.DateOfBirth}에 태어남");

Person baby2 = Person.Procreate(lee, hong);
baby2.Name = "Hong-2baby";
kim.WriteChildrenToConsole();
lee.WriteChildrenToConsole();
hong.WriteChildrenToConsole();

for (int i = 0; i < hong.Children.Count; i++)
{
  Console.WriteLine(format: " {0}'의 {1}번째 자녀 : \"{2}\".", arg0: hong.Name, arg1: i, arg2: hong.Children[i].Name);
}

예제를 실행하면 다음과 같은 결과를 표시할 것입니다.

보는바와 같이 동일한 개체 type에 대한 2개의 intance에 적용되는 기능의 경우 이에 필요한 정적 method와 intance method를 모두 제공하여 동일한 기능을 구현하고 있습니다. 정적 method든 intance method든 모든 경우에 적합한 method는 없으며 특정 type이 어떻게 사용될지 예측할 수도 없습니다. 따라서 두 method를 모두 제공하여 개발자가 원하는 방식으로 type을 적절히 사용하도록 하는 것이 가장 좋습니다.

밑에서 부터는 이제 type에 대한 두 intance에 대해 어떠한 방식으로 위와 동일한 기능을 부여할 수 있는지 알아볼 것입니다.

(2) 연산자를 사용한 기능 구현

System.String은 2개의 문자열을 연결하고 그 결과를 반환하는 Concat이라는 정적 method를 갖고 있습니다.

string s1 = "Hello "; 
string s2 = "World!";
string s3 = string.Concat(s1, s2); 
Console.WriteLine(s3);

위와 같이 Concat method를 통해서도 가능하지만 사실 개발자에게는 + 연산자를 통해 두 문자열을 결합하는 것이 더 자연스러울 수 있습니다.

string s3 = s1 + s2;

위와 같이 우리는 +연산자를 통해 둘의 People에 대한 결혼식을 올리고 *연산자로 자식을 낳는 동작을 수행할 수 있습니다. 연산자는 method이름대신 기호를 사용한다는 것만 다를뿐 하나의 method이므로 문법역시 method와 동일하게 구현됩니다.

Person.cs에서 아래와 같이 정적 method를 추가하여 결혼을 구현하고

public static bool operator +(Person p1, Person p2)
{
	Marry(p1, p2);
 	return p1.Married && p2.Married;
}

연산자에 대한 반환 type은 매개변수로 전달된 type과 일치할 필요는 없지만 void가 될 수는 없습니다.

다시 ×에 대한 정적 method로 출산을 구현합니다.

public static Person operator *(Person p1, Person p2)
{
  return Procreate(p1, p2);
}

Method와 달리 연산자는 intellisense에 나타나지 않습니다. 개발자의 입장에서 연산자를 사용할 수 있는지가 불분명하기 때문에 그에 대응하는 method를 같이 만들어두는것이 좋습니다. 이때 연산자를 구현하는것 안에서 method를 호출하도록 하면 code를 재사용하는 것이 가능할 것입니다. Method를 구현해야 하는 두번째 이유로는 모든 언어에서 연산자를 지원하지는 않기 때문입니다. 즉, 다른 언어에서 C#에서 지원하는 모든 연산자를 지원한다는 보장이 없는 것입니다.

위와 같이 정의한 method는 다음과 같은 방법으로 호출됩니다.

Person hong = new() { Name = "홍길동" };
Person kim = new() { Name = "김길순" };
//Person lee = new() { Name = "이길영" };

if (hong + kim)
{
  Console.WriteLine($"{hong.Name}과 {kim.Name}양의 혼인이 성사됨.");
}

Person baby = hong * kim;
baby.Name = "홍아기";

kim.WriteChildrenToConsole();

예제를 실행하면 다음과 같은 결과를 확인할 수 있습니다.

아래 link를 통해서는 더 많은 연산자의 재정의 대해 알아볼 수 있습니다.

Operator overloading - Define unary, arithmetic, equality, and comparison operators. - C# | Microsoft Learn

Operator overloading - Define unary, arithmetic, equality, and comparison operators. - C#

Learn how to overload a C# operator and which C# operators are overloadable. In general, the unary, arithmetic, equality and comparison operators are overloadable.

learn.microsoft.com

3. Generic을 통해 안전하게 재사용할 수 있는 type만들기

2005년 C# 2.0과 .NET Framework 2.0에서 Microsoft는 type을 좀 더 안전하게 재사용할 수 있으며 더 효율적으로 활용할 수 있는 generic이라는 기능을 도입했습니다. 이를 통해 개발자는 개체를 매개변수로 전달하는 방식과 비슷하게 type을 매개변수로 전달하여 generic이 제공하는 유연성을 사용할 수 있습니다.

(1) 비 generic type 사용

우선 generic type을 사용하지 않는 경우에 먼저 살펴볼 것입니다. 이를 통해 취약하게 입력된 매개변수 및 값에서와 같은 문제와 System.Object의 사용으로 인한 성능문제를 해결하기 위해 generic이 어떤 개념으로 설계되었는지를 이해할 수 있을 것입니다.

System.Collections.Hashtable는 나중에 값을 빠르게 찾는 데 사용되는 각각의 고유한 key와 값을 다수로 저장하는 데 사용되며 key와 value모두 System.Object로 선언되었기에 object type이 될 수 있습니다. 비록 int와 같은 type값을 저장할 때 object사용에 대한 유연성을 제공해 주기는 하지만 generic보다 상대적으로 느릴 수밖에 없으며(boxing과 unboxing) item을 추가할 때 type을 확인하지 않으므로 bug가 발생되기 쉽습니다.

Program.cs에서 비 generic collection인 System.Collections.Hashtable에 대한 intance를 생성하고 아래와 같이 4개의 item을 추가합니다.

System.Collections.Hashtable lookupObject = new();

lookupObject.Add(key: 1, value: "one");
lookupObject.Add(key: 2, value: "two");
lookupObject.Add(key: 3, value: "three");
lookupObject.Add(key: kdh, value: "Person");

이어서 2의 값을 가진 key를 정의하고 이를 hashtable에서 값을 찾기 위한 구문을 추가합니다.

int key = 2;
Console.WriteLine(format: "Key {0} has value: {1}", arg0: key, arg1: lookupObject[key]);

또한 kdh개체를 사용해 값을 찾은 구문도 추가합니다.

Console.WriteLine(format: "Key {0} has value: {1}", arg0: kdh, arg1: lookupObject[kdh]);

예제를 실행시키면 아래와 같은 결과를 표시할 것입니다.

비록 code는 잘 작동하긴 했지만 실질적으로 모든 type이 key와 값으로 사용될 수 있기 때문에 잠재적인 문제점을 가지고 있습니다. 다른 개발자가 예제의 lookupObject를 사용하고 모든 item이 int와 같은 특정 type이라고 예상한다면 아마도 해당 type으로 변환을 시도할 것입니다. 하지만 모든 type이 일관된 type은 아니므로 어느 지점에서는 예외를 일으킬 수 있습니다. 또한 lookupObject가 많은 item을 가지면 가질수록 성능은 저하됩니다.

System.Collections namespace의 import를 되도록이면 피해야 합니다. 대신 System.Collections.Generics와 다른 namespace를 대신 import 하여 사용하는 것이 좋습니다.

(2) generic type 사용

System.Collections.Generic.Dictionary<TKey, TValue>도 역시 System.Collections.Hashtable과 마찬가지로 값을 빠르게 검색하는 데 사용되는 각각의 고유한 key를 가진 다수의 값을 저장할 수 있고 이때 key와 값은 어떠한 개체도 될 수 있습니다. 다만 compiler에게 key와 값의 type으로 어떤 것을 사용할지를 collection을 instance화 할 때 명시해야 합니다. 이때 TKey와 TValue의 generic 매개변수를 통해 type을 특정할 수 있습니다.

통상 generic type이 정의가능한 type을 하나 가질 때 이름은 T가 됩니다. 예를 들어 List<T>에서 T는 list에 저장되는 type을 말합니다. generic type이 정의가능한 type을 여러 개 가지는 경우에는 접두사로서의 이름이 T가 되어야 하고 그 뒤에 Dictionary<TKey, TValue>처럼 용도에 맞는 이름이 부여됩니다.

이러한 방식은 충분한 유연성을 제공하며 빠르고, item이 추가될 때 type을 확인하게 되므로 bug 또한 최소화할 수 있습니다. Dictionary< TKey, TValue>를 포함하고 있는 System.Collections.Generic namespace는 기본적으로 전역 import 되므로 별도의 import를 지정할 필요가 없습니다.

예제를 통해 generic을 사용하여 어떻게 문제를 해결할 수 있는지를 확인해 보도록 하겠습니다.

Program.cs에서 generic lookup collection Dictionary<TKey, TValue>에 대한 instance를 생성하고 아래와 같이 4개의 item을 추가합니다.

Dictionary<int, string> lookupIntString = new();

lookupIntString.Add(key: 1, value: "one");
lookupIntString.Add(key: 2, value: "two");
lookupIntString.Add(key: 3, value: "three");
lookupIntString.Add(key: kdh, value: "person");

이렇게 하면 compiler는 kdh에 대한 오류를 다음과 같이 표시할 것입니다.

이 상태에서 kdh를 숫자 4로 바꾸고 key변수도 4로 설정한 뒤 아래와 같이 dictionary에서 값을 검색하는 문을 추가합니다.

lookupIntString.Add(key: 4, value: "person");

Console.WriteLine(format: "Key {0} has value: {1}", arg0: key, arg1: lookupIntString[key]);

예제를 실행하면 다음과 같은 결과를 표시할 것입니다.

4. Event 발생과 제어

Method는 종종 개체가 그 자체로 또는 관련 개체에서 수행할 수 있는 동작으로 설명됩니다. 예를 들어 List<T>는 자체적으로 item을 추가할 수 있고 스스로 item을 비울 수 있으며 File은 filesytem안에서 file을 생성하고 삭제하는 동작을 수행할 수 있습니다.

반면 Event는 개체로 발생되는 동작을 말합니다. 예를 들어 사용자 interface에서 button은 click event를 가지며 click는 button에서 발생하는 것입니다. FileSystemWatcher는 directory나 file에 대한 변화가 발생할 때 작동되는 Created 및 Deleted와 같은 event를 발생시키고 변경사항을 알리기 위해 filesystem을 감시합니다.

Event를 좀 다른 측면으로 보면 두 개체사이에 message를 교환하는 방법을 제공한다고도 할 수 있습니다.

Event는 delegate를 내장하고 있는데 event에 대해 들어가 보려면 우선 이 delegate가 무엇인지 그리고 어떻게 작동하는지를 먼저 알아볼 필요가 있습니다.

(1) Delegate를 사용한 method 호출

지금까지 예제를 통해서 우리는 이미 method를 호출하고 실행하는 가장 일반적인 방식을 사용해 봤습니다. .(점) 연산자를 통해 method의 이름을 사용하여 접근하는 것으로 예를 들어 Console.WriteLine는 Console type에 있는 WriteLine method를 호출한다는 의미가 됩니다.

method를 호출하고 실행하는 다른 방법으로는 delegate를 사용하는 것입니다. 함수 pointer를 지원하는 언어를 사용해 본 적이 있다면 delegate를 type-safe method pointer로 생각할 수 있습니다.

즉, delegate는 해당 delegate와 동일한 특성에 일치하는 method의 memory주소를 포함하고 있으므로 정확한 매개변수의 type을 통해 안전하게 호출할 수 있습니다.

예를 들어, Person class에서 아래와 같이 매개변수에 string type을 전달되어야 하며 반환값의 type이 int인 method가 있다면

public int MyMethod(string input)
{
	return input.Length;
}

Person의 p1과 같은 instance를 통해 method를 아래와 같이 호출할 수 있습니다.

Person p1 = new();
int result = p1.MyMethod("Frog");

또는 간접적으로 호출될 method의 특성과 일치하는 delegate를 정의할 수 있는데 이때 delegate는 매개변수의 이름과는 일치할 필요가 없이 단지 매개변의 type과 반환되는 값의 type만 일치하면 됩니다.

delegate int DelegateWithMatchingSignature(string s);

이렇게 하면 호출하고자 하는 method의 point를 부여하고 아래와 같이 delegate의 instance를 생성한 뒤 method를 호출하는 것처럼 delegate를 호출하면 됩니다.

DelegateWithMatchingSignature d = new(p1.MyMethod);
int result = d("Flog");

Method를 호출하기에 다소 복잡한 과정을 거치는 것처럼 보이기 때문에 어쩌면 '이렇게 method를 호출할 필요가 있을까?'라는 질문을 던질 수도 있습니다. 결론부터 얘기하면 이것은 유연성을 제공하기 위한 것입니다.

예를 들어 순서대로 호출되어야 하는 method의 queue를 생성하기 위해 delegates를 사용할 수도 있습니다. 향상된 확장성을 제공하기 위해 수행되어야 하는 queue의 action은 service에서 일반적입니다.

다른 예로는 다수의 action이 병렬적으로 동작되어야 하는 경우를 들 수 있습니다. Delegate는 다른 thread에서 동작하는 비동기 운영을 지원하기 위한 내장된 기능을 갖고 있으며 이로 인해 향상된 응답성을 제공할 수 있습니다.

가장 중요한 것은 delegate는 우리가 서로에 대해서 알지 못하는 다른 개체들 사이에 message를 전달하기 위한 event를 구현할 수 있도록 한다는 것입니다. Event는 서로에 대해 알 필요가 없는 component사이에서 느슨한 결합의 예가 될 수 있는데 이때는 그저 event의 특성만 알고 있으면 될 뿐입니다.

(2) Delegate 정의하고 실행하기

Microsoft는 event로 사용하기 위해 2개의 delegate를 사전 정의하였고 해당 delegate는 모두 아래 2개의 매개변수를 가지고 있습니다.

object? sender : 해당 매개변수는 event를 발생시킨 혹은 message를 보낸 개체를 참조하며 null이 될 수 있습니다.
EventArgs e 또는 TEventArgs e : 해당 매개변수는 발생한 event에 대한 추가적인 관련 정보를 포함합니다. 예를 들어 GUI환경에서 MouseMoveEventArgs를 정의할 수 있는데 여기에는 mouse pointer가 위치한 x, y좌표를 나타내는 속성을 가지고 있습니다. 은행 계좌의 경우라면 출금하는 금액의 속성을 가진 WithdrawEventArgs를 가질 수도 있을 것입니다.

이들 delegate의 특성은 간단하지만 유연합니다.

public delegate void EventHandler(object? sender, EventArgs e);
public delegate void EventHandler<TEventArgs>(object? sender, TEventArgs e);

위에서 첫 번째는 추가적인 인수값을 전달할 필요가 없는 method용이며 두 번째는 generic type TEventArgs에 의해 정의된 대로 인수값을 전달해야 하는 method용입니다.

자체 type으로의 event를 정의해야 하는 경우에는 이들 2개의 사전정의된 delegate 중 하나를 사용할 수 있습니다.

이제 delegate와 event를 직접 사용해 보도록 하겠습니다.

Person class에 아래와 같은 구문을 추가하고

public EventHandler? Shout;

public int AngerLevel;

public void Poke()
{
	AngerLevel++;

	if (AngerLevel >= 3)
	{
		if (Shout != null)
		{
			Shout(this, EventArgs.Empty);
		}
	}
}

다음 사항에 주목합니다.

예제에서는 Shout이름의 EventHandler delegate field를 정의하였습니다.
AngerLevel을 저장하기 위한 int field를 정의하였습니다.
Poke이름의 method를 정의하였습니다.
person에서는 Poke method가 실행될 때마다 AngerLevel field를 증가시키고 3의 값에 도달하면 Shout event를 발생시키도록 되어 있지만 단 적어도 단 하나의 event delegate가 code가 아닌 외부에서 정의된 method를 가라키고 있어야 합니다. 즉 null이 되어서는 안 됩니다.

Method를 호출하기 전 개체가 null인지 아닌지를 확인하는 것은 아주 일반적인 것입니다. C# 6 이후부터는 .연산자전에 ?문자를 통해 inline에서 간소화된 null확인이 가능해졌습니다.
Shout?.Invoke(this, EventArgs.Empty);

MyApp project에서는 Program.cs에서 sender 매개변수로 부터 Person개체를 참조하고 이들에 대한 일부 정보를 출력하는 특성과 일치하는 method를 아래와 같이 추가합니다.

static void Man_Shout(object? sender, EventArgs e)
{
	if (sender is null) return;

	Person? p = sender as Person;

	if (p is null) return;

	Console.WriteLine($"{p.Name} is this angry: {p.AngerLevel}.");
}

참고로 Event를 처리하기 위한 method의 이름은 Microsoft에서 관례적으로 '개체이름_Event이름'으로 지정하고 있습니다.

그리고 delegate field로 method를 할당하고 네 번에 걸쳐 Poke method를 호출하는 구문을 아래와 같이 추가합니다.

kdh.Shout = Man_Shout;
kdh.Poke();
kdh.Poke();
kdh.Poke();
kdh.Poke();

위 예제를 실행하면 다음과 같은 결과를 표시할 것입니다. Poke method를 호출하는 처음 두 번은 아무런 반응도 없다가 최소 3번의 Poke가 실행되면 Man_Shout event를 발생시킬 것입니다.

(3) Event 정의하고 실행하기

위 과정을 통해 event의 기능적인 면에서 가장 중요한 delegate를 어떻게 구현할 수 있는지를 알아보았습니다. 이를 통해 code의 완전히 다른 조각으로 구현되어야 하는 method의 특성을 정의하고 해당 method와 그 외 delegate field와 연결된 다른 모든 것들을 호출합니다.

Event는 위에서 알아본 것과는 비교적 알아야 할 내용이 많지는 않습니다.

Delegate field로 method를 할당할 때는 이전 예제에서처럼 단순한 할당 연산자를 통해서 할당하는 것은 피해야 합니다. =연산자 대신 +=연산자를 사용함으로써 더 많은 method를 delegate field에 할당할 수 있습니다. Delegate가 호출되면 비록 순서자체를 제어할 수는 없지만 여기에 할당된 모든 method가 호출될 것입니다.

Shout delegate field가 이미 하나 또는 그 이상의 method를 참조하고 있을 때 =연산자를 통해 새로운 method를 할당하게 되면 다른 모든 것들을 대체하게 됩니다. 따라서 Event를 위해 사용되는 delegate에서는 일반적으로 method의 추가와 삭제를 위해 개발자가 +=이나 -=연산자를 사용하도록 강제되곤 합니다.

Person.cs에서 event keyword를 선언된 delegate field에 아래와 같이 추가합니다.

public event EventHandler? Shout;

이렇게 하면 기존에 Program.cs에서 event를 할당하던 구문에는 다음과 같은 compiler error message가 표시됩니다.

event keyword가 하는 역할의 대부분이 바로 이것입니다. 만약 delegate field에 하나이상의 method가 할당되기를 원하지 않는다면 기술적으로는 event keyword가 필요하지 않지만 delegate field에 event가 사용된다는 것을 대부분 예상할 수 있기 때문에 기본적으로 event keyword를 사용하는 것이 좋습니다.

Program.cs에서는 기본 method할당 문을 +=연산자로 변경합니다.

kdh.Shout += Man_Shout;

예제를 실행하면 이전과 동일한 결과를 표시할 것입니다.

Program.cs에서 기존 Man_Shout method를 복사해 method의 이름과 WriteLine method를 아래와 같이 변경해 줍니다.

static void Man_Shout2(object? sender, EventArgs e)
{
	if (sender is null) return;

	Person? p = sender as Person;

	if (p is null) return;

	Console.WriteLine($"Stop it!");
}

그리고 기존 Man_Shout method를 할당한 구문 다음에 위 새로운 method를 할당하는 구문을 추가합니다.

kdh.Shout += Man_Shout;
kdh.Shout += Man_Shout2;

예제를 다시 실행하면 다음과 같은 결과를 표시할 것입니다.

5. Interface의 구현

Interface는 표준적인 기능을 구현하고 새로운 것을 생성하기 위해 다른 type을 연결하는 방법을 제공하는데 LEGO brick에서 서로 같이 붙일 수 있는 Studs on top이나 plug, socket의 전기적 표준과 같은 것으로 생각할 수 있습니다.

Interface에 대한 type을 구현하면 특정한 기능을 구현한다는 약속을 만들게 되는는데 이러한 특징 때문에 종종 interface를 계약으로 설명하기도 합니다.

(1) 공통 interface

아래 표는 type에서 구현할 수 있는 공통 interface를 나타낸 것입니다.

Interface	Method	Description
IComparable	CompareTo(other)	type이 instance를 정렬하기 위한 비교 method를 정의합니다.
IComparer	Compare(first, second)	second type이 first type의 instance를 정렬하기 위한 비교 method를 정의합니다.
IDisposable	Dispose()	finalizer를 기다리는 것보다 더 효휼적으로 비관리 resource를 해제하기 위한 소거 method를 정의합니다.
IFormattable	ToString(format, culture)	개체의 값을 문자열로 표현할때 이를 형식화 하기 위한 문화권 인식 method를 정의합니다.
IFormatter	Serialize(stream, object) Deserialize(stream)	저장 또는 전송을 위해 개체를 byte stream또는 byte strem에서 개체로 변환하는 method를 정의합니다.
IFormatProvider	GetFormat(type)	언어와 지역에 기반해 입력을 형식화 하는 method를 정의합니다.

(2) 정렬 시 개체의 비교

흔히 구현되는 가장 일반적인 interface 중 하나는 IComparable입니다. 해당 interface는 CompareTo이라는 method하나를 정의하고 있는데 2가지 형태로 사용될 수 있습니다. 하나는 null가능한 개체 type을 필요로 하며 다른 하나는 null가능한 generic type T를 필요로 합니다.

namespace System
{
	public interface IComparable
	{
		int CompareTo(object? obj);
	}
	public interface IComparable<in T>
	{
		int CompareTo(T? other);
	}
}

예를 들어 string type에서는 string이 비교되기 전에 정렬되어야 한다면 -1을, 그 후에 정렬되어야 한다면 1을, 동등하다면 0을 반환하는 IComparable를 구현하고 있습니다. int type에서는 비교되는 int type보다 더 작으면 -1을, 더 크면 1을, 동등하다면 0을 반환하는 IComparable을 구현합니다.

type이 IComparable interface중 하나를 구현한다면 type의 instance를 포함하는 array와 collection은 정렬될 수 있습니다.

IComparable interface와 Person class의 CompareTo method를 구현하기 전에 Name속성에 null값을 가진 일부를 포함하고 있는 Person instance의 array를 정렬할 때 어떠한 동작이 실행되는지를 확인해 보도록 하겠습니다.

MyApp project의 Program.cs에서 title과 함께 매개변수로 전달된 people collection에서 이름을 출력할 method를 추가합니다.

static void OutputPeopleNames(IEnumerable<Person?> people, string title)
{
	Console.WriteLine(title);

	foreach (Person? p in people)
	{
		Console.WriteLine(" {0}", p is null ? "<null> Person" : p.Name ?? "<null> Name");
	}
}

그리고 Person instance의 array를 생성하고 console에 item을 출력하기 위해 OutputPeopleNames method를 호출하는 문을 추가합니다. 그리고 array를 정렬한 다음 console로 item을 다시 출력합니다.

Person?[] people =
{
	null,
	new() { Name = "kim" },
	new() { Name = "hong" },
	new() { Name = "ahn" },
	new() { Name = null },
	new() { Name = "lee" }
};

OutputPeopleNames(people, "정렬 전 people");

Array.Sort(people);

OutputPeopleNames(people, "Person의 IComparable implementation을 사용해 정렬한 후");

위 예제를 실행하면 다음과 같은 예외를 발생시키게 됩니다. 예외 message에서는 주어진 문제를 해결하기 위해 type이 IComparable를 구현해야 함을 말하고 있습니다.

Person.cs에서 아래와 같이 IComparable<Person?>을 상속하도록 합니다.

public class Person : IComparable<Person?>

그러면 Visual Studio에서는 추가한 code아래에 붉은색 밑줄을 긋고 필요한 method가 아직 구현되지 않았음을 표시하게 됩니다.

이때 왼쪽 전구모양을 click 하고 'Implement interface'를 click 하면 method의 기본 틀을 자동으로 생성할 것입니다.

public int CompareTo(Person? other)
{
	throw new NotImplementedException();
}

method안에서는 NotImplementedException throw부분을 제거하고 null포함해 입력값의 다양성을 처리하는 문을 추가한 뒤 Name field에 대한 CompareTo method를 호출합니다. 이를 통해 string type의 CompareTo구현을 사용하여 결과를 반환하게 될 것입니다.

public int CompareTo(Person? other)
{
	int position;
	if ((this is not null) && (other is not null))
	{
		if ((Name is not null) && (other.Name is not null))
		{
			position = Name.CompareTo(other.Name);
		}
		else if ((Name is not null) && (other.Name is null))
		{
			position = -1;
		}
		else if ((Name is null) && (other.Name is not null))
		{
			position = 1;
		}
		else
		{
			position = 0;
		}
	}
	else if ((this is not null) && (other is null))
	{
		position = -1;
	}
	else if ((this is null) && (other is not null))
	{
		position = 1;
	}
	else
	{
		position = 0;
	}
    
	return position;
}

예제에서는 Name field를 비교하여 두 Person instance를 비교하도록 선택했습니다. 그러므로 Person instance는 자신의 Name에 의해 alphabet순으로 정렬될 것입니다. 이때 null은 collection의 아래로 정렬됩니다. 따라서 계산된 위치를 반환하기 전에 저장하는 것이 debugging시에 유용할 수 있습니다.

예제를 실행하면 이번에는 Name이 alphabet순으로 정렬됨으로써 제대로 작동한다는 것을 알 수 있습니다.

외부에서 자체적으로 생성한 type에 대해 정렬을 허용하고자 한다면 IComparable interface를 구현함으로써 이를 실현할 수 있습니다.

(3) Separate class를 사용한 개체의 비교

어떤 경우에는 type에 대한 source code에 접근할 수 없고 따라서 IComparable interface를 구현할 수 없는 경우가 있을지도 모릅니다. 하지만 type에 대한 정렬을 수행하는 다른 방법이 존재하는데 약간 다른 interface인 IComparer를 구현하는 separate type을 생성하는 것입니다.

MyApp project에서 Comparer.cs이름의 새로운 class file을 추가하고 두 개의 Person instance를 비교할 IComparer interface를 구현하는 class를 아래와 같이 작성합니다.

public class PersonComparer : IComparer<Person?>
{
	public int Compare(Person? x, Person? y)
	{
		int position;

		if ((x is not null) && (y is not null))
		{
			if ((x.Name is not null) && (y.Name is not null))
			{
				int result = x.Name.Length.CompareTo(y.Name.Length);

				if (result == 0)
				{
					return x.Name.CompareTo(y.Name);
				}
				else
				{
					position = result;
				}
			}
			else if ((x.Name is not null) && (y.Name is null))
			{
				position = -1;
			}
			else if ((x.Name is null) && (y.Name is not null))
			{
				position = 1;
			}
			else
			{
				position = 0;
			}
		}
		else if ((x is not null) && (y is null))
		{
			position = -1;
		}
		else if ((x is null) && (y is not null))
		{
			position = 1;
		}
		else
		{
			position = 0;
		}

		return position;
	}
}

Program.cs에서는 위 예제의 class를 이용해 array를 정렬하는 문을 이전 예제에서 아래와 같이 변경합니다.

Array.Sort(people, new PersonComparer());

OutputPeopleNames(people, "Person의 IComparer implementation을 사용해 정렬한 후");

예제를 실행하고 Name길이와 alphabet순으로 정렬되는 다음의 결과를 확인합니다.

people에 대한 array의 정렬을 수행할 때 예제에서는 PersonComparer type을 정렬 algorithm으로 대신사용할 것을 명시적으로 요청하였으므로 people은 kim과 같이 짧은 이름이 우선순위로 올라오게 되며 가장 긴 이름의 hong이 후순위로 정렬되는 것을 알 수 있습니다. 만약 2개 또는 그 이상으로 이름의 길이가 동등한 경우 이때는 ahn, kim과 같이 alphabet순의 정렬이 이루어지게 됩니다.

(4) 암시적 그리고 명시적인 interface구현

Interface는 암시적으로 그리고 명시적인 방법으로 구현될 수 있습니다. 암시적인 구현은 간단하며 더 일반적이기도 합니다. 명시적인 구현은 type의 method가 같은 이름과 특성을 가진 여러 version을 가지고 있을 때 사용됩니다.

예를 들어 IGamePlayer와 IKeyHolder는 game에서 패할 수 있고 key에서는 key를 잃을 수 있으므로 둘 다 같은 매개변수를 가진 Lose라는 method를 가질 수 있습니다. type안에서 이 둘의 interface를 구현해야 할 때 단지 하나의 Lose구현만 암시적인 method가 될 수 있습니다. 둘의 interface가 같은 구현을 공유할 수 있다면 그렇게 되겠지만 그렇지 않다면 다른 Lose method는 다르게 구현되어야 하며 명시적으로 호출되어야 합니다.

public interface IGamePlayer
{
	void Lose();
}
public interface IKeyHolder
{
	void Lose();
}

public class Person : IComparable<Person?>, IGamePlayer, IKeyHolder
{
	//암시적인 구현
	public void Lose()
	{
	}

	//명시적인 구현
	void IGamePlayer.Lose()
	{
	}

Person p = new();
p.Lose(); // 임시적 호출

((IGamePlayer)p).Lose(); // 명시적 호출

//명시적인 호출의 또 다른 방법
IGamePlayer player = p as IGamePlayer;
player.Lose();

(5) 기본 구현을 통한 interface 정의

C# 8에서 부터 interface를 위해 도입된 기능으로 기본 구현(default implementations)이라는 것이 있습니다.

MyLibrary project에서 IPlayable.cs이름의 file을 추가하고 Play와 Pause라는 2개의 method를 가진 public IPlayable interface를 정의합니다.

public interface IPlayable
{
	void Play();
	void Pause();
}

MyApp project에서는 DvdPlayer.cs이름의 class file을 추가하고 IPlayable interface를 아래와 같이 구현합니다.

public class DvdPlayer : IPlayable
{
	public void Pause()
	{
		Console.WriteLine("DVD player is pausing.");
	}
	public void Play()
	{
		Console.WriteLine("DVD player is playing.");
	}
}

위와 같은 상황에서 C# 8 이전에 Stop이라는 새로운 method를 추가해야 한다면 적어도 하나의 type이 본래 interface에서 구현될 수 있으므로 이렇게 하는 것은 불가능합니다. interface의 주요 기능중 하나는 성립된 계약을 지키게끔 하는 것입니다.

C# 8에서 부터는 release이후에도 기본구현이 추가되면 이를 통해 새로운 member의 추가를 허용하게 되었습니다. C#을 사용하는 일부 개발자들은 사실 이러한 생각을 별로 좋아하지는 않습니다만 변경사항으로 인한 부작용이나 전체 interface를 새로 정의해야 하는 현실적인 이유로서 유용할 수 있으며 Java나 Swift 같은 다른 언어의 경우에는 비슷한 기술을 이미 허용하기도 합니다.

기본 interface 구현은 기본 platform을 일부 근본적으로 바꾸어야 하기 때문에 .NET 5.0 또는 그 상위의 C#에서만 지원하고 있습니다. 그외 .NET Core, ..NET Standard, .NET Framework등에서는 지원하지 않습니다.

IPlayable interface에서 아래와 같이 기본 구현을 통해 Stop method를 추가합니다.

public interface IPlayable
{
	void Play();
	void Pause();
	void Stop() // default interface implementation
	{
		Console.WriteLine("Default implementation of Stop.");
	}
}

그리고 MyApp project를 build 하면 DvdPlayer가 Stop method를 구현하지 않았음에도 불구하고 정상적으로 이루어짐을 확인할 수 있습니다. 일단 이렇게 해놓으면 추후에 DvdPlayer에서 Stop에 대한 기본구현을 재정의함으로써 method를 구현할 수 있는 여지가 생깁니다.

6. 참조와 값 type에서의 memory관리

지금까지는 간단하게만 참조 type에 대해서 언급해 왔는데 이제 이에 대해 좀 더 구체적으로 들어가 보려고 합니다.

Memory의 범주에는 크게 2가지로 나누어 볼 수 있는데 하나는 stack 다른 하나는 heap입니다. 요즘 운영체제에서 stack과 heap은 물리적 혹은 가상 memory 어느 곳이든 될 수 있습니다.

Stack memory는 CPU에 의해 직접적으로 관리되며 후입-선출 체계를 사용하고 L1과 L2 cache에서 data가 다뤄질 가능성이 많기 때문에 성능면에서 더 빠르게 작동합니다. heap memory가 느리긴 하지만 더 풍부한 용량을 가질 수 있는 반면 stack은 크기가 제한적입니다.

ARM64, x86, x64에서 동작하는 Windows에서는 stack의 기본 size가 1MB이며 일반적인 Linux기반 운영체제에서는 8MB입니다. MAC OS의 terminal에서 ulimit -a 명령을 사용하면 stack의 크기가 8,192KB로 제한되어 있고 다른 memory의 경우에는 'unlimited'임을 알 수 있습니다. Stack memory가 쉽게 채워지고 이어서 'stack overflow'를 일으키기가 쉬운 이유가 바로 이러한 stack memory의 size제한 때문입니다.

(1) 참조와 값 type의 정의

C#에서는 개체의 type을 정의하기 위한 3가지 keyword가 존재합니다. class, record 그리고 struct가 그것입니다. 이 모든 것은 field나 method와 같은 member를 가질 수 있지만 다른 차이점은 이들이 어떻게 memory에 할당되느냐 하는 것입니다.

record나 class를 통해 type을 정의하면 이것은 참조(reference) type이 됩니다. 즉, 개체 자체는 heap memory에 할당되며 해당 개체에 대한 heap의 주소만 stack에 저장됩니다. 이는 미약하지만 아주 약간의 overhead를 일으킬 수 있습니다.
record struct 혹은 struct를 사용해 type을 정의하면 이것은 값 type이 됩니다. 특, 개체 자체에 대한 memory가 stack에 그대로 할당됩니다.

Struct에서도 struct type이 아닌 field type을 사용하게 되면 해당 field는 heap에 저장될 것입니다. 따라서 이러한 개체의 data는 stack과 heap에 동시에 존재하게 됩니다.

가장 일반적인 struct type은 아래와 같이 분류할 수 있습니다.

Number type : byte, sbyte, short, ushort, int, uint, long, ulong, float, double, decimal
System.Drawing type : Color, Point, PointF, Size, SizeF, Rectangle, RectangleF
기타 : char, DateTime, DateOnly, TimeOnly, bool

System.String(string)과 System.Object(object)를 포함에 다른 모든 type은 class입니다.

Type의 data가 저장되는 memory의 장소에 대한 용어적인 차이점과는 별개로 가장 주된 차이점은 struct로부터는 상속이 불가능하다는 것입니다.

(2) 참조와 값 type이 memory에 저장되는 방식

예를 들어 아래와 같이 몇 개의 변수를 선언하는 console app이 있다고 가정했을 때

int number1 = 49;
long number2 = 12;

System.Drawing.Point location = new(x: 4, y: 5);

Person kim = new()
{
	Name = "kim hee seoung",
	DateOfBirth = new(year: 1982, month: 12, day: 13)
};

Person hong;

여기에서 실제 예제의 문이 실행될 때 어떤 것이 stack과 heap에 할당되는지 검토해 보면 아래와 같은 사항을 확인할 수 있습니다.

number1 변수는 값 type(또는 struct)이므로 stack에 할당되며 32bit integer이므로 4byte의 memory를 사용하게 됩니다. 값은 49인데 이는 변수에 직접적으로 저장됩니다.
number2 변수 역시 값 type이므로 stack에 할당되며 64bit integer이므로 8byte의 memory를 사용하게 됩니다.
location 역시 값 type이며 stack에 할당됩니다. 또한 x와 y라는 2개의 32bit-integer로 이루어져 있으므로 8byte의 memory를 사용합니다.
kim은 참조 type(class)이며 64bit 운영체제의 경우 64bit memory 주소를 위해 stack에 8byte가 할당됩니다. 그리고 Person의 instance를 저장하기 위해 충분한 공간의 heap이 할당됩니다.
hong은 참조 type이며 stack에 64bit memory 주소를 저장하기 위해 8byte 공간을 사용하게 됩니다. 다만 현재 시점에서는 null이므로 아직 heap에 memory가 할당되지 않았습니다. 만약 예제에서 kim을 hong에 할당하게 된다면 heap에 대한 Person의 memory 주소가 hong으로 복사될 것입니다.

참조 type에 할당된 모든 memory는 heap에 저장됩니다. 만약 Person과 같은 참조 type에서 field가 DateTime과 같은 값 type이라면 DateTime의 값 역시 heap에 저장됩니다.

값 type이 참조 type인 field를 가진 경우라면 값 type의 값은 heap에 저장됩니다. Point는 2개의 field로 이루어진 값 type이며 2개의 field모두 값 type이기 때문에 전체 개체는 stack에 할당될 수 있습니다. 만약 point 값 type이 string과 같이 참조 type인 field를 가지게 된다면 string byte는 heap에 저장될 수 있습니다.

(3) Boxing

C#에서 boxing은 값 type이 heap memory로 옮겨지고 System.Object instance안으로 감싸는 것을 말합니다. 반대로 Unboxing은 값이 stack으로 되돌아 오는 경우를 의미하며 이때 Unboxing은 명시적으로 이루어집니다. boxing은 암시적으로 발생할 수 있으므로 개발자의 의식없이 이루어질 수 있고 이때 약간의 과부하가 생기게 됩니다.

예를 들어 아래 예제에서는 int값을 boxing하고 바로 다시 unboxing하고 있습니다.

int n = 3;
object o = n; // 암시적인 Boxing
n = (int)o; // 명시적인 Unboxing

또 다른 예로는 아래와 같이 값 type을 형식화된 문자열에 전달하는 경우입니다.

string s = "hello";
int i = 10;

Console.WriteLine("stirng output {0} - {1}", s, i);

이때 i는 값 type으로서 boxing이 이루어집니다. 문자열 s는 참조 type이고 이미 heap이 존재하므로 boxing/unboxing과는 관련이 없습니다.

상술했듯이 Boxing과 unboxing은 성능이 부정적인 영향을 줄 수 있으므로 개발자 입장에서는 되도록 이러한 동작이 발생하지 않게 하는 것이 좋지만 그렇다고 해서 너무 걱정할 필요는 없습니다. 실제 많은 code에서 boxing/unboxing은 자주 사용되며 너무 남발하지 않는 이상은 이것때문에 성능상 문제를 일으키는 경우가 거의 없는 경우가 많습니다. 물론 Unity와 같은 game개발의 경우에는 garbage collector가 기대한것 만큼 신속하게 동작하지 않을 수 있기 때문에 가능한한 이러한 동작이 발생되는 경우를 피하는 것이 좋습니다.

(4) Type의 동일성

일반적으로 2개의 변수를 비교할 때는 ==이나 !=연산자를 사용하는데 이들 2개의 연산자는 참조와 값 type에서 다르게 동작합니다.

2개의 값 type 변수에 대한 동일성을 확인할때 .NET은 실질적으로 stack에 있는 이들 2개 변수에 대한 값을 비교하고 동일한 값이라면 true를 반환합니다.

Program.cs에서 동일한 값을 가진 2개의 integer변수를 선언하고 이들을 비교하는 문을 아래와 같이 추가합니다.

int a = 3;
int b = 3;

Console.WriteLine($"a: {a}, b: {b}");
Console.WriteLine($"a == b: {(a == b)}");

예제를 실행하면 다음과 같은 결과를 확인할 수 있습니다.

2개의 참조 type 변수에 대한 동일성을 확인할때 .NET은 이들 두 변수에 대한 memory 주소를 비교하고 동일하다면 true를 반환합니다.

Program.cs에서 둘의 Person instance를 선언하고 Name을 동일하게 설정한 뒤 이들 변수를 비교하는 문을 아래와 같이 추가합니다.

Person p1 = new() { Name = "Kim" };
Person p2 = new() { Name = "Kim" };

Console.WriteLine($"p1: {p1}, p2: {p2}");
Console.WriteLine($"p1 == p2: {(p1 == p2)}");

예제를 실행하면 다음과 같은 결과를 확인할 수 있습니다.

위와 같은 결과가 나오게 되는 이유는 개체가 다르기 때문입니다. 만약 이 둘의 변수가 실질적으로 heap상에 같은 개체를 가리키고 있다면 이들은 동일하게 판단될 수 있습니다.

Program.cs에서 3번째 Person 개체를 선언하고 p1을 할당합니다.

Person p3 = p1;
Console.WriteLine($"p3: {p3}");
Console.WriteLine($"p1 == p3: {(p1 == p3)}");

예제를 실행하면 이번에는 다음과 같은 결과를 확인할 수 있습니다.

참조 type의 이러한 동작에 대한 한 가지 예외는 string type입니다. string은 참조 type이지만 동일성을 비교하는 연산자에서는 이들이 값 type인 것처럼 동작하도록 재정의되어 있습니다.

Program.cs에서 두 Person instance의 Name속성을 비교하는 문을 아래와 같이 추가하고

Console.WriteLine($"p1.Name: {p1.Name}, p2.Name: {p2.Name}");
Console.WriteLine($"p1.Name == p2.Name: {(p1.Name == p2.Name)}");

예제를 실행하면 다음과 같은 결과를 확인할 수 있습니다.

물론 우리가 임의로 만든 class에 대해서도 서로가 같은 개체(heap상 같은 memory 주소)가 아니라도 해당 개체의 field가 같은 값을 가진 경우라면 비교 연산자가 true를 반환하도록 만들 수도 있습니다. 하지만 이렇게 하기보다는 record class를 사용하여 동일한 동작을 구현하는 것이 좋습니다.

(5) Struct type 정의

Sturct를 통해서는 자체 값 type을 정의할 수 있습니다.

MyLibrary project에서 DisplacementVector.cs이름의 file을 아래와 같이 추가합니다.

public struct DisplacementVector
{
	public int X { get; set; }
	public int Y { get; set; }

	public DisplacementVector(int initialX, int initialY)
	{
		X = initialX;
		Y = initialY;
	}

	public static DisplacementVector operator +(DisplacementVector vector1, DisplacementVector vector2)
	{
		return new(vector1.X + vector2.X, vector1.Y + vector2.Y);
	}
}

Program.cs에서는 DisplacementVector에 대한 2개의 새로운 instance를 생성하고 이들에 대해 +연산을 수행한 뒤 그 결과를 출력하도록 합니다.

DisplacementVector dv1 = new(3, 5);
DisplacementVector dv2 = new(-2, 7);
DisplacementVector dv3 = dv1 + dv2;
Console.WriteLine($"({dv1.X}, {dv1.Y}) + ({dv2.X}, {dv2.Y}) = ({dv3.X}, { dv3.Y})");

예제를 실행하면 다음과 같은 결과를 확인할 수 있습니다.

값 type에서는 기본 생성자를 명시적으로 정의하지 않는다 하더라도 stack상에 값이 초기화되어야 하므로 기본값을 통한 기본 생성자는 반드시 가지게 됩니다. 만약 이런 경우라면 DisplacementVector에 대한 2개의 integer field는 0으로 초기화될 것입니다.

이어서 DisplacementVector에 대한 또 다른 instance를 하나 더 생성하고 해당 개체의 속성을 출력하도록 합니다.

DisplacementVector dv4 = new();
Console.WriteLine($"({dv4.X}, {dv4.Y})");

예제를 실행한 결과는 다음과 같습니다.

type에 존재하는 모든 field에서 사용하는 최종 memory가 16byte이거나 혹은 그 보다 더 적고 이들 field가 값 type만을 사용하며 해당 type으로부터 파생되는 것이 필요하지 않다면 Microsoft에서는 struct를 사용할 것을 권장하고 있습니다. type에서 stack memory로 16byte 이상을 사용하고 field가 참조 type이거나 상속이 필요하다면 class를 사용해야 합니다.

(6) Record struct type 정의

C# 10에서는 class type에서 뿐만 아니라 struct type에서도 record keyword를 사용할 수 있게 되었습니다.

따라서 DisplacementVector type은 아래와 같이 정의될 수 있습니다.

public record struct DisplacementVector(int X, int Y);

Record struct는 class의 이점을 가진 struct인 record class와 모든 동일한 이점을 가집니다. record struct와 record class사이에 한 가지 차이점이라면 record struct는 readonly keyword를 적용하지 않는 이상은 불변이 아니라는 것입니다. struct는 ==와 !=연산자를 구현하지 않지만 자동적으로 record struct로 구현됩니다.

이러한 변화로 Microsoft는 record class를 정의하고자 할 때 class keyword가 선택 적라 하더라도 명시적으로 class를 지정해 줄 것을 권장하고 있습니다.

public record class ImmutableAnimal(string Name);

(7) 비관리 resource 해제

이전 예제를 통해 우리는 생성자를 통해 field를 초기화할 수 있고 type은 여러 생성자를 가질 수 있음을 알게 되었습니다. 이때 만약 생성자가 OS의 제어하에 있는 file이나 mutex와 같은 .NET에서 관리되지 않는 비관리 resource를 할당할때 .NET은 자동적인 garbage collection기능을 사용해 비관리 resource를 해제할 수 없으므로 수동적인 해제처리가 필요합니다.

각 type은 resource의 해제가 필요할때 .NET runtime에서 호출될 수 있는 단일 finalizer를 가질 수 있습니다. Finalizer는 type의 이름인 생성자와 동일한 이름을 가지지만 앞에 접두사 ~문자를 가집니다.

public class ObjectWithUnmanagedResources
{
	public ObjectWithUnmanagedResources() // 생성자
	{
		// 비관리 resource 할당
	}
	~ObjectWithUnmanagedResources() // 종료자 (또는 파괴자)
	{
		// 비관리 resource 해제
	}
}

finalizer(또는 destructor)를 Deconstruct method와 혼동해서는 안됩니다. destructor는 resource를 해제하는 것으로 개체를 memory에서 소거하는 것입니다. 하지만 Deconstruct method는 예를 들어 tuple을 사용할 때처럼 각각의 요소로 분해된 개체를 반환하며 C# deconstruction 문법을 사용합니다. 이에 대한 내용은 아래 글을 참고하시기 바랍니다.

[C# 12와 .NET 8] 5. OOP (Object-Oriented Programming)

C#에서는 OOP를 통해 자신만의 type을 만들 수 있습니다. 이를 위해 data를 저장하기 위한 field와 동작을 수행하는 method를 포함해 type이 가질 수 있는 member들에 대해 encapsul화와 같은 OOP개념을 사용해

lab.cliel.com

위 예제는 비관리 resource에 대한 처리를 할 수 있는 최소한의 구현이지만 finalizer를 제공함으로써 생길 수 있는 문제는. NET garbage collector가 type에 할당된 resource의 해제를 완료하기 위해 2번의 garbage collection 동작이 필요하게 된다는 것입니다.

선택적이기는 하지만 type을 사용하는 개발자가 명시적으로 resource를 해제할 수 있도록 하는 또 다른 method를 제공하는 것을 권장합니다. 이를 통해 garbage collector가 file과 같은 비관리 resource 중 관리되는 부분을 즉시 해제하도록 할 수 있습니다. 즉, garbage collection이 이중적인 실행대신 단일 garbage collection만으로 개체의 관리 memory 부분을 해제하는 것입니다.

이는 아래와 같이 IDisposable interface를 통해 기본적인 mechanism을 구현할 수 있습니다.

public class ObjectWithUnmanagedResources : IDisposable
{
	public ObjectWithUnmanagedResources()
	{
	}
	~ObjectWithUnmanagedResources()
	{
		Dispose(false);
	}

	bool disposed = false;
	public void Dispose()
	{
		Dispose(true);
		GC.SuppressFinalize(this);
	}

	protected virtual void Dispose(bool disposing)
	{
		if (disposed) return;

		if (disposing)
		{
		}

		disposed = true;

	}
}

예제에서는 public과 protected로 2개의 Dispose method가 존재하는데 public void Dispose method는 type을 사용하는 개발자에 의해 호출되는 것이며 비관리와 관리 resource를 할당 해제합니다. bool형식의 매개변수를 가진 protected virtual void Dispose method는 내부적으로 resource의 해제를 구현하기 위해 사용됩니다. 다만 여기서는 finalizer thread가 이미 동작중이고 ~ObjectWithUnmanagedResources method를 호출했다면 비관리 resource만이 할당해제가 필요한 상황이 되므로 disposing 매개변수와 disposed를 확인해야 합니다.

GC.SuppressFinalize(this)를 호출하는 것은 garbage collector에게 finalizer의 동작이 더 이상 필요하지 않음을 알려주기 위한 것이며 두 번째 garbage collection의 필요성을 제거합니다.

(8) Dispose의 호출을 보장하기

다른 개발자가 IDisposable이 구현된 type을 사용할 때는 public Dispose method가 아래와 같은 문을 통해 호출되도록 해야 합니다.

using (ObjectWithUnmanagedResources thing = new())
{
	// ...
}

위 문은 compiler가 아래와 같이 예외가 발생하는 경우에도 여전히 Dispose method가 호출되도록 code를 변환합니다.

ObjectWithUnmanagedResources thing = new();

try
{
	// ...
}
finally
{
	if (thing != null) thing.Dispose();
}

IAsyncDisposable을 구현한 type의 경우에는 아래와 같은 문을 통해 public Dispose method가 호출되도록 할 수 있습니다.

await using (ObjectWithUnmanagedResources thing = new())
{
	// ...
}

7. null 사용

지금까지 memory에 저장되는 방식에 따라 참조 type과 값 type이 어떻게 다른지와 struct변수에서 숫자와 같은 원시값이 저장되는 방식에 대해 알아보았습니다. 하지만 아직 변수가 값을 가지지 않았다면? 그런 경우라면 또 그것을 어떻게 표시할 수 있을까? C#은 이런 경우에 대해 null라는 개념을 제공하여 변수가 아직 값을 가지지 않았음을 표현하는 데 사용할 수 있도록 하였습니다.

(1) 값 type을 null가능하게 만들기

기본적으로 int나 DateTime과 같은 값 type은 항상 값을 가져야 합니다. 그런데 null이나 빈 상태를 허용하는 database와 같은 곳에서 값을 읽을 때는 값 type에도 null을 허용하는 것이 편리할 수 있습니다. 우리는 이것을 'null가능한 값 type'이라고 합니다.

그리고 이렇게 null을 허용하는 것은 변수를 선언할 때 type에 접미사로 ?문자를 사용함으로써 가능합니다.

csStudy06 solution에 NullHandling이름의 Console App project를 추가하고 Program.cs에서 기존 구문을 모두 삭제한 뒤 int변수를 선언하고 null을 포함해 값을 할당하는 문을 추가합니다. 이때 하나는 ? 접미사를 사용하고 다른 하나는 사용하지 않습니다.

int thisCannotBeNull = 4;
thisCannotBeNull = null;
Console.WriteLine(thisCannotBeNull);

int? thisCouldBeNull = null;
Console.WriteLine(thisCouldBeNull);
Console.WriteLine(thisCouldBeNull.GetValueOrDefault());

thisCouldBeNull = 7;
Console.WriteLine(thisCouldBeNull);
Console.WriteLine(thisCouldBeNull.GetValueOrDefault());

위와 같이 code를 작성하면 Visual Studio에서는 다음과 같은 compile error를 발생시키게 됩니다.

error가 발생한 부분의 code를 주석처리하고 예제를 실행하면 다음과 같은 결과가 표시될 것입니다.

두 번째 부분이 비어있는 이유는 null값이 표시된 것이기 때문입니다.

이어서 아래와 같이 null을 지정하는 문을 추가합니다.

Nullable<int> thisCouldAlsoBeNull = null;
thisCouldAlsoBeNull = 9;
Console.WriteLine(thisCouldAlsoBeNull);

여기서 Nullable<int>부분을 click 하고 F12 key를 누르거나 mouse 오른쪽 button을 눌러 'Go To Definition'을 선택하면 Nullable<T>유형인 generic 값 type은 값 type이라는 struct인 T type이 있어야 하며 HasValue, Value, GetValueOrDefaut와 같은 유용한 member가 존재함을 알 수 있습니다.

struct뒤에 ?를 붙이게 되면 다른 struct로 변경하는 것입니다.

(2) Null 관련 initial

아래 표는 null과 관련하여 일반적으로 사용되는 initial을 표시한 것입니다.

Initial	의미	설명
NRT	Nullable reference types	C# 8과 함께 도입된 compiler기능이며 C# 10의 project에서 기본으로 활성화되어 design time에 code를 정적으로 분석하고 참조 type에 대한 null 값의 오용가능성을 경고표시합니다.
NRE	NullReferenceException	null 값을 역참조하려할때 runtime에서 발생하는 예외로, null값을 가진 변수나 member에 접근하는 경우를 의미합니다.
ANE	ArgumentNullException	매개변수가 null이면서 null을 올바른 값으로 취급할 수 없을때 method가 호출됨으로서 runtime에서 발생하는 예외입니다.

(3) Null 가능 참조 type

Null 값을 다루는 것은 여러 언어에서 아주 일반적인 것이라 많은 개발자들은 null존재에 대해서 별다른 의문을 가지고 있지는 않습니다. 그러나 변수가 null이 되는 것을 허용하지 않는다면 코드를 단순화할 수 있는 많은 상황이 있을 수 있습니다.

C# 8 compiler의 가장 중요한 변화중 하나는 null가능한 것과 null가능하지 않은 참조 type을 확인하고 경고를 표시한다는 것입니다. 그런데 참조 type은 이미 null이 가능한 type인데 왜 null여부를 확인하는 걸까?

C# 8부터 참조 type은 file 혹은 project 수준에서 option설정을 통해 더 이상 참조 type이 null이 가능하지 않도록 할 수 있습니다. 이것은 C#에서는 큰 변화에 해당하므로 Microsoft는 이 기능을 option으로 결정할 수 있게끔 만들어 두게 됩니다.

해당 C# compiler기능은 해당 기능이 적용되기 이전에 만들어진 것으로 예상되는 수천 가지의 library와 app에 적용되기까지는 몇 년의 시간이 걸릴 수도 있습니다. 심지어 Microsoft조차 .NET 6까지 주요 .NET package에 이 새로운 기능을 구현할 시간이 없었을 정도입니다.

이렇게 변화하는 동안 우리는 우리가 만든 project에 위 기능과 관련된 몇 가지 접근 방식을 선택할 수 있습니다.

Default : .NET 5나 그 이전에 생성된 project에서는 어떠한 변경도 필요하지 않으며 null가능하지 않은 참조 type은 확인되지 않습니다. .NET 6나 이후에 생성된 project에서 null가능성 확인은 기본으로 사용되지만 csproj project file에서 <Nullable>요소를 삭제하거나 disable로 설정함으로써 해당 기능을 비활성으로 돌릴 수 있습니다.
Opt-in project, opt-out files : project수준에서 해당 기능을 사용하고자 하는 것이며 예전 방식의 호환성으로 남아 있어야 하는 file들은 제외됩니다. 이것은 Microsoft가 새로운 기능을 사용하기 위해 자체 package가 update 될 때까지 내부적으로 사용하는 접근법입니다.
Opt-in file: 설정한 각각의 file에서만 기능을 사용하도록 합니다.

(4) null가능성 경고 확인 기능 제어

Project 수준에서 null가능한 경고 확인 기능을 사용하려면 csproj(project file)을 아래와 같이 설정해야 합니다. (반대로 기능을 사용하지 않으려면 disable로 맞춰줍니다.)

<PropertyGroup>
...
 	<Nullable>enable</Nullable>
</PropertyGroup>

File수준에서 기능을 사용하려면 아래와 같이 설정합니다.(반대로 기능을 사용하지 않으려면 disable로 맞춰줍니다.)

#nullable enable

(5) null 및 관련 / 기타 compiler 경고의 비활성처리

Project나 file수준에서 nullability기능을 사용하고자 하는 경우에도 이와 관련된 일부 경고 message는 나타나지 않도록 할 수 있습니다. 아래 표는 일반적으로 나타날 수 있는 nullability 경고를 나타내고 있습니다.

CS8600	null literal 또는 null가능값을 비 nullable type으로 변경합니다.
CS8601	가능한 null 참조 할당
CS8602	가능한 null 참조의 역참조
CS8603	가능한 null 참조의 반환
CS8604	매개변수에 대한 가능한 null 참조 할당
CS8618	생성자를 나올때 non-nullable field 'field 명'은 non-null value값을 포함해야 합니다. 필요하다면 field를 null가능한 type으로 선언합니다.
CS8625	null literal을 non-nullable 참조 type으로 변경할 수 없습니다.
CS8655	switch 표현식은 일부 null입력을 처리할 수 없습니다.

전체 project단위에서 compiler 경고를 나타나지 않게 하려면 위와 같은 compiler 경고 code를 semi colon으로 구분한 NoWarn 요소를 추가합니다.

<NoWarn>CS8600;CS8602</NoWarn>

특정한 경고 code를 임시적으로 제거했다가 다시 복구함으로서 구문단위로 특정한 경고의 발생을 제어할 수 있습니다.

#pragma warning disable CS8602
...
...
#pragma warning restore CS8602

(6) null일 수 없는 변수와 매개변수 선언

null가능한 참조 type을 사용하고 참조 type에 null값을 할당하고자 한다면 null가능한 값 type을 표시하던 것과 같은 문법인 ?문자를 type선언뒤에 붙여주는 문을 사용할 수 있습니다.

그렇다면 null가능한 참조 type은 어떻게 작동하는지 예제를 통해 알아보도록 하겠습니다. 주소에 대한 정보를 저장할 때 Street, City, Region에 대한 입력을 강제하고자 하지만 Building은 공백이 가능하다는 가정하에 NullHandling project에 서 Address.cs file을 추가하고 field를 아래와 같이 추가합니다.

public class Address
{
    public string? Building;
    public string Street;
    public string City;
    public string Region;
}

Visual Studio에서 위와 같이 code를 작성하면 Street field에서 처럼 null가능한 부분에 대해서 다음과 같이 경고를 표시할 것입니다.

이 상태에서 non-nullable인 각 field에 대해 empty string을 아래와 같이 할당합니다.

public class Address
{
    public string? Building;
    public string Street = string.Empty;
    public string City = string.Empty;
    public string Region = string.Empty;
}

Program.cs에서는 Address의 instance를 생성하고 각 속성에 아래와 같이 값을 할당합니다.

Address address = new()
{
    Building = null,
    Street = null,
    City = "Daegu",
    Region = "KR"
};

이렇게 되면 Building이 아닌 Street의 null설정 부분에서 CS8625에 대한 경고를 보게 됩니다.

이제 예제에서 Street의 설정 부분에 있는 null다음에 아래와 같이 null 무효 연산자인 !를 추가해 줍니다.

Street = null!,

이렇게 하면 경고 message는 사라지게 될 것입니다. 다음으로 Building과 Street에 대한 속성을 역참조하는 문을 아래와 같이 추가합니다.

Console.WriteLine(address.Building.Length);
Console.WriteLine(address.Street.Length);

하지만 이번에는 CS8602용 경고가 Street가 아닌 Building에 표시될 것입니다.

runtime에서는 여전히 Street에 대한 예외가 발생할 수 있지만 compiler는 Building에 대한 잠재적인 예외를 계속 경고할 것입니다. 이때 이를 피하기 위해서는 Length에 곧장 접근하는 대신 반환될 수 있는 null에 대해 null 조건 연산자를 아래와 같이 사용할 수 있습니다.

Console.WriteLine(address.Building?.Length);

예제를 실행하면 Building의 Length에 접근하는 문에서 null값(공백으로 표시)이 출력되지만 Street의 Length의 접근 시에는 runtime 예외가 발생할 것입니다.

이를 통해 우리는 NRT가 단지 compiler에게 문제를 일으킬 수 있는 잠재적인 null값에 대하여 경고를 제공하도록 요청하는 것일 뿐, code에 대한 실질적인 동작을 바꾸는 것은 아니며 compile time에서 code의 정적인 분석을 수행할 뿐이라는 것을 알 수 있습니다.

이제까지의 설명은 null가능한 참조 type에 대한 것이며, 일반적인 참조 type은 non-nullable이 될 수 있고 값 type에서 사용했던 것과 같은 문법을 통해 nullable참조 type을 만들 수 있음을 말씀드리고자 합니다.

참조 type에서의 ? 접미사는 type을 바꾸지 않습니다. type을 Nullable<T>로 바꾸는 값 type에서의 ? 접미사와는 다른 것입니다. 참조 type은 처음부터 null값을 가지며 nullable 참조 type에서 수행하는 모든 것은 compiler에게 null이 될 수 있음을 말하는 것으로 이것만으로 compiler는 개발자에게 경고를 해줄 필요가 없습니다. 하지만 code에서 null확인을 수행해야 하는 필요성을 없애는 것이 아닙니다.

계속해서 NRT를 구현하는 것과 더불어 code의 동작을 바꾸는 null값으로 작업하기 위한 언어기능에 대해 계속 알아보도록 하겠습니다.

(7) null 확인

Null가능한 참조 type인지 null가능한 값 type변수가 현재 null값을 가지고 있는지를 확인하는 것은 그렇게 하지 않으면 NullReferenceException 예외가 error로 발생할 수 있기 때문에 중요합니다. null 변수는 아래와 같이 사용하기 전 null값인지를 확인할 수 있습니다.

if (nullableVariable != null) //null 확인
{
	int length = nullableVariable.Length; // 위 조건이 없고 null이라면 이 지점에서 예외발생
	...
}

C# 7부터는 '!='를 대체할 수 있도록 ! 연산자를 아래와 같이 결합할 수 있습니다.

if (!(nullableVariable is null))
{
}

C# 9부터는 위에서 보다 더 명확하게 null이 아님을 명시할 수 있는 not이 도입되었습니다.

if (nullableVariable is not null)

만약 값이 null일 수 있는 변수를 사용하려는 경우에 있다면 null 조건부 연산자인 ? 를 아래와 같이 사용할 수 있습니다.

string authorName = null;
int x = authorName.Length;

int? y = authorName?.Length;

때로는 변수를 결과에 할당하거나 변수가 null이면 3처럼 대체값을 사용하려 한다면 ?? null 병합 연산자를 아래와 같이 사용할 수 있습니다.

null가능한 참조 type을 사용한다고 하더라도 여전히 null에 대한 non-nullable 매개변수를 확인하고 ArgumentNullException을 표시할 수 있어야 합니다.

(8) Method의 매개변수에서 null인지를 확인

매개변수와 함께 method를 정의할 때 null값을 확인하는 건 좋은 습관입니다.

C#의 이전 version에서는 if문을 통해 매개변수의 null값을 확인하고 null이면 ArgumentNullException예외를 발생시킬 수 있었습니다.

public void personMethod(Person manager, Person employee)
{
	if (manager == null)
	{
		throw new ArgumentNullException(nameof(manager));
	}
	if (employee == null)
	{
		throw new ArgumentNullException(nameof(employee));
	}
	...
}

C# 10에서는 매개변수가 null인 경우 예외를 발생시킬 수 있는 편리한 method가 도입되어 아래와 같이 사용할 수 있습니다.

public void personMethod(Person manager, Person employee)
{
	ArgumentNullException.ThrowIfNull(manager);
	ArgumentNullException.ThrowIfNull(employee);
	...
}

C# 11 preview에서는 새로운 !!연산자를 도입하여 위와 동일한 동작을 수행시킬 수 있었습니다.

public void personMethod(Person manager!!, Person employee!!)

위 if와 예외를 발생시키는 문은 하위의 다른 문을 실행시키기 이전에 먼저 주입되고 실행되므로 특히 !!연산자는 C# 개발자 community에서 논란이 되기도 했는데 일부는 이러한 연산자를 사용하는 대신 매개변수에 attribute를 사용해 적용하는 걸 선호하기도 했고 .NET team은 이 기능을 통해 .NET library의 전체 code에서 10,000줄 이상을 줄일 수 있었다고 언급하기도 했습니다. 이것만으로 이 기능을 사용하기 충분히 좋다고 생각될 수 있지만 유감스럽게도 team은 이 기능을 최종적으로 삭제하기로 하였습니다. 따라서 !!연산자를 제외하고 if문이나 method를 null확인을 위해 사용해야 합니다.

nullable은 위험성에 대한 경고만 줄 뿐 무엇인가를 강제하는 것이 아님을 기억해야 합니다. null과 관련된 compiler의 경고에 관해서는 아래글을 참고하시기 바랍니다.
https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/ compiler-messages/nullable-warnings.

8. Class로부터의 상속

이전에 생성했던 Person type은 System.Object의 별칭인 object로부터 상속된 것입니다. 이제 Person type으로 상속하는 하위(sub) class를 생성해 봄으로서 상속에 관한 자세한 사항을 알아보도록 하겠습니다.

MyLibrary에서 Employee.cs이름의 새로운 file을 추가하고 아래와 같이 Person으로부터 파생되는 Employee class를 생성합니다.

namespace MyLibrary
{
	public class Employee : Person
	{
	}
}

MyApp project의 Program.cs에서는 아래와 같이 Employee class의 instance를 생성하는 문을 추가합니다.

Employee jun = new()
{
	Name = "seong jun",
	DateOfBirth = new(year: 1985, month: 12, day: 24)
};
jun.WriteToConsole();

해당 예제를 실행하면 다음과 같은 결과를 표시할 것입니다.

여기서 Employee class는 Person의 모든 member가 상속되었음을 알 수 있습니다.

(1) 기능 추가로 class 확장하기

위에서 만들어진 Employee class는 확장을 위해 Employee고유의 member를 추가할 수 있습니다. Employee.cs에서 아래와 같이 직원번호과 고용된 날짜를 위한 2개의 속성을 정의합니다.

public string? EmployeeCode { get; set; }
public DateTime HireDate { get; set; }

그리고 Program.cs에서 jun의 직원번호(EmployeeCode)와 고용날짜(HireDate)를 설정하고 설정된 내용을 출력하는 문을 추가합니다.

jun.EmployeeCode = "JJ001";
jun.HireDate = new(year: 2014, month: 11, day: 23);

Console.WriteLine($"{jun.Name} was hired on {jun.HireDate:yyyy-MM-dd}");

예제를 실행하면 다음과 같은 결과를 표시할 것입니다.

(2) Member 숨김

위 예제에서 WriteToConsole method는 Person으로부터 상속된 것이며 Employee의 Name과 DateOfBirth를 표시하였습니다. 그런데 이 method를 Employee에 맞게 바꾸려 한다면 아마도 아래와 같이 할 수 있을 것입니다.

public DateTime HireDate { get; set; }

public void WriteToConsole()
{
    Console.WriteLine(format:"{0} was born on {1:yyyy-MM-dd} and hired on {2:yyyy-MM-dd}", arg0: Name, arg1: DateOfBirth, arg2: HireDate);
}

해당 예제를 실행하면 다음과 같은 응답을 생성하게 됩니다.

실제 Visual Studio에서는 방금 전 추가한 method에서 Person으로부터의 method가 숨겨진다는 경고를 다음과 같이 표시할 것입니다. app을 build 하고 실행하게 되면 'Error List'창에도 해당 오류를 자세히 표시하게 됩니다.

경고 message에서 설명된 것처럼 method에서 인의적으로 Person의 method를 현재의 method로 바꿀 것임을 나타내는 new keyword를 사용하면 이러한 경고 message를 지울 수 있습니다.

public new void WriteToConsole()

(3) this와 base

C# keyword 중에서는 현재 개체의 instance 혹은 상속의 대상이 되는 base class를 참조하기 위한 this와 base라는 2개의 keyword가 존재합니다.

this는 현재 개체의 instance를 나타내는 것으로서 예를 들어 Person class instance안에 member (비 정적 member)를 위해 this.DateOfBirth과 같은 방법을 사용하여 현재 개체의 instance에 속한 DateOfBirth filed에 접근할 수 있습니다. 물론 일반적인 경우 DateOfBirth만을 사용하는 것만으로 아무런 문제없이 filed에 접근할 수 있지만 만약 DateOfBirth라는 새로운 지역변수가 존재하는 경우라면 지역변수가 아닌 개체의 member로서 DateOfBirth를 참조한다고 명시해줄 필요가 있기 때문에 이때는 this를 붙여줘야 합니다.

base는 현재 개체가 상속하는 기반 class를 나타내는 것입니다. 예를 들어 Person class안에서 base.ToString()문을 사용한다면 이때는 해당 method를 구현하고 있는 base class의 member를 호출하는 것입니다.

(4) Member 재정의

가능하다면 method를 숨기기보다는 override를 사용하는 편이 더 일반적입니다. 단 override는 기반 class에서 overriding을 허용하는 method에 virtual keyword를 적용했을 때만 사용할 수 있습니다.

Program.cs에서 jun의 변숫값을 console에 문자열로 표시하도록 하는 문을 아래와 같이 작성하고

Console.WriteLine(jun.ToString());

예제를 실행하면 다음과 같은 응답을 표시하게 됩니다.

여기서 ToString method는 System.Object로 부터 상속된 것이므로 type의 namespace와 이름을 표시할 것입니다. 이 상태에서 Person.cs에 person의 name과 type의 name을 표시하도록 아래와 같이 ToString method를 추가합니다. 이렇게 되면 ToString method의 동작을 바꿀 수 있게 됩니다.

public override string ToString()
{
    return $"{Name} is a {base.ToString()}";
}

이때 base keyword는 파생 class에서 상속하거나 파생되는 해당 기반 class의 member에 접근할 수 있도록 하는 keyword입니다.

예제를 실행하고 결과를 확인해 보시기 바랍니다. ToString method를 호출할 때 기반 class에서 구현된 ToString의 반환내용과 더불어 person의 name을 함께 표시할 것입니다.

실제 Microsoft의 Entity Framework Core나 Castle의 DynamicProxy, CMS의 content model 최적화 같은 많은 실제 API들은 class에서 정의한 속성이 재정의 될 수 있도록 virtual로 표시되어야 합니다. 이때 어떤 method와 속성 member를 virtual로 할지는 신중하게 결정해야 합니다.

(5) 추상(abstract) class로 부터의 상속

아래 글에서는

[.NET/C#] - [C# 12와 .NET 8] 6. Interface와 Class상속

type이 가져야 할 기본 수준의 기능에 대한 일련의 member를 정의할 수 있는 interface에 대해 다뤄봤습니다. 이것만으로도 꽤 유용하긴 하지만 한 가지 큰 제한사항은 C# 8까지는 자체적으로 구현하는 어떤 것도 제공할 수 없다는 것입니다.

이것은 .NET Framework및 .NET Standard 2.1을 지원하지 않는 다른 platform에서 작동하는 class library를 생성할 때 특히 문제가 됩니다.

이러한 상황에서는 순수 interface와 완전 구현 class의 중간 격인 추상 class를 사용할 수 있습니다.

class가 abstract로 수식되면 해당 class는 완전하지 않음을 나타내기 때문에 instance를 생성할 수 없게 됩니다. 즉, instance가 생성되기 전 더 많은 구현이 필요한 것입니다. 예를 들어 System.IO.Stream class는 추상 class로서 모든 stream에서 필요할 수 있는 공통적인 기능을 구현하고 있지만 완전하지는 않아서 new Stream()으로 instance를 생성할 수 없습니다.

예를 들어 아래와 같은 insterface와

public interface INoImplementation // C# 1.0
{
    void Alpha(); // 파생된 type에서 구현되어야 함
}
public interface ISomeImplementation // C# 8부터
{
    void Alpha(); // 파생된 type에서 구현되어야 함
    void Beta()
    {
        // 기본 구현으로서 재정의될 수 있음
    }
}

추상 class가 존재할 때

public abstract class PartiallyImplemented // C# 1.0
{
    public abstract void Gamma(); // 파생된 type에서 구현되어야 함
    public virtual void Delta() // 재정의될 수 있음
    {
        // 구현
    }
}

위 interface과 추상 class에 대한 파생 class를 생성하면 아래와 같이 만들어질 수 있습니다.

public class FullyImplemented : PartiallyImplemented, ISomeImplementation
{
    public void Alpha()
    {
        // 구현
    }
    public override void Gamma()
    {
        // 구현
    }
}

위와 같이 하면 정말 구현된 class에서만 instance를 생성할 수 있고 다른 type에 대해서는 compile오류가 발생할 수 있습니다.

FullyImplemented a = new();

//에러
PartiallyImplemented b = new();

(6) 상속 및 재정의 차단하기

class에 sealed keyword를 사용하면 해당 class로부터 다른 개발자가 상속받는 것을 막을 수 있습니다.

public sealed class MyType
{
}

. NET에서 sealed가 사용된 사례로는 string class를 들 수 있습니다. Microsft는 string class에 몇몇 극한의 최적화를 구현하였고 때문에 이를 상속해 사용할 경우 부정적인 영향을 끼칠 수 있어서 string class로부터는 아예 상속을 구현할 수 없도록 하였습니다.

class에 있는 method도 마찬가지로 sealed keyword를 통해 누군가가 해당 method를 재정의하는 걸 막을 수 있습니다.

public class MyType
{
	public virtual void MyMethod()
	{

	}
}

public class MyType2 : MyType
{
	public sealed override void MyMethod()
	{

	}
}

따라서 위 예제의 경우 아무도 MyType2에 있는 MyMethod를 재정의할 수 없습니다. sealed는 override method에서만 사용할 수 있습니다.

(7) 다형성

상속된 method의 동작을 바꾸는 데는 2가지 방법이 있습니다. 하나는 new keyword(non-polymorphic inheritance)를 사용해 기반 class의 method를 숨기는 것과 override(polymorphic inheritance)를 사용해 기반 class의 method를 재정의하는 것입니다.

이 두 가지 방법 모두에서는 base keyword를 사용해 기반(super) class의 member에 접근할 수 있는데 그렇다면 이 둘 간의 차이점은 무엇일까?

이 것은 모두 개체의 참조를 가진 변수의 유형에 따라 달라집니다. 예를 들어 Person type의 변수는 Person class 혹은 Person으로부터 파생된 모든 type을 가질 수 있습니다.

Employee.cs에서 ToString method를 재정의하여 employee에 대한 name과 code를 console로 출력하는 문을 아래와 같이 추가합니다.

public override string ToString()
{
    return $"{Name}'s code is {EmployeeCode}";
}

Program.cs에서는 syAhn이라는 이름의 새로운 employee를 생성하고 Person type변수에 저장합니다. 그리고 이 둘의 변수에서 WriteToConsole과 ToString method를 호출합니다.

Employee ahnInEmployee = new()
{
    Name = "syAhn",
    EmployeeCode = "12345"
};

Person ahnInPerson = ahnInEmployee;
ahnInEmployee.WriteToConsole();
ahnInPerson.WriteToConsole();

Console.WriteLine(ahnInEmployee.ToString());
Console.WriteLine(ahnInPerson.ToString());

예제를 실행하면 다음의 결과를 표시할 것입니다.

Method가 new로 숨겨진 경우에 compiler는 해당 개체가 Employee의 method를 말하는 것인지를 알지 못하므로 Person에 대한 WriteToConsole method를 호출하게 됩니다.

Method가 virtual과 override를 통해 재정의된 경우에는 compiler는 비록 변수가 Person class로 정의되었어도 개체가 Employee class이므로 Employeee에서 구현된 ToString method를 호출합니다.

Member의 한정자와 이에 대한 영향은 아래 표와 같이 요약할 수 있습니다.

Variable type	Member modifier	Method executed	In class
Person		WriteToConsole	Person
Employee	new	WriteToConsole	Employee
Person	virtual	ToString	Employee
Employee	override	ToString	Employee

개인적인 의견으로 new보다는 virtual과 override가 new보다는 많이 사용되는 듯합니다. 솔직히 다형성을 완전히 이해하지 않아도 virtual과 override정도의 개념만 알고 있으면 그것도 충분합니다.

9. 계층적 상속에서 Casting 하기

Type 간 casting은 type 간 converting과는 미묘하게 다릅니다. Casting은 16-bit integer와 32-bit integer 사이 혹은 sub class와 super class사이와 같이 비슷한 type 간에 이루어지는 것을 말하며 Converting은 문자열-숫자사이와 같이 비슷하지 않은 type간에 이루어지는 것을 말합니다.

(1) 암시적인 casting

이전 예제에서는 파생된 type의 instance를 해당 base type의 변수(또는 base의 base type, 기타 등등)에 저장해 보았습니다. 실제 이러한 동작이 이루어질 때 이것을 암시적 casting이라고 합니다.

(2) 명시적 casting

type명에 괄호를 사용하여 원하는 type으로 cast 하는 방법을 명시적 cast라고 합니다.

Program.cs에서 aliceInPerson변수를 새로운 Employee로 할당하는 문을 아래와 같이 추가합니다.

Employee explicitAhn = ahnInPerson;

이렇게 하면 Visual Studio에서는 다음과 같이 compile error를 표시할 것입니다.

이 상태에서 할당된 변수 앞에 문을 변경하여 Employee type으로 cast 하도록 지정해 줍니다.

Employee explicitAhn = (Employee)ahnInPerson;

(3) Casting 예외 피하기

위의 처리로 compiler는 더 이상 error를 표시하지 않지만 ahnInPerson은 Employee가 아닌 Student처럼 파생된 type이 다를 수 있으므로 주의해야 합니다. 더 복잡한 code를 가진 실제 application에서 해당 변수의 현재 값은 Student의 instance로 설정될 수도 있으며 그러면 위의 예제는 InvalidCastException error를 유발할 것입니다.

● Type을 확인하기 위한 is 사용하기

try 문을 사용해 위의 문제를 해결할 수 있지만 이 보다 더 나은 방법은 is keyword를 사용하여 다음과 같이 if문과 함께 개체의 type을 확인하는 것입니다.

if (ahnInEmployee is Employee)
{
    Console.WriteLine($"{nameof(ahnInEmployee)} IS an Employee");
    Employee explicitAlice = (Employee)ahnInEmployee;
}

예제를 실행하면 다음과 같은 결과를 표시합니다.

위 상태에서 선언적 pattern을 사용하면 code를 더욱 간소화시키고 명시적인 cast의 수행을 생략할 수 있습니다.

if (ahnInEmployee is Employee explicitAhn)
{
    Console.WriteLine($"{nameof(ahnInEmployee)} IS an Employee");
    explicitAhn.WriteToConsole();
}

만약 ahnInEmployee가 Employee가 아닌 경우에 block의 문을 실행하고자 한다면 이전에는 ! (not) 연산자를 사용하여 아래와 같이 표현했지만

if (!(ahnInEmployee is Employee))

C# 9 부터는 not keyword를 사용하여 아래와 같이 표현할 수 있습니다.

if (ahnInEmployee is not Employee)

● Type을 cast 하기 위한 as 사용하기

is의 대안으로 cast를 위해 as keyword를 사용할 수도 있습니다. as keyword는 type의 cast가 불가능한 경우 예외를 일으키는 대신 null을 반환한다는 차이가 있습니다.

Program.cs에서 as keyword를 통해 ahn을 cast 하고 반환값이 null인지 아닌지를 확인하는 문을 아래와 같이 추가합니다.

Employee? aliceAsEmployee = ahnInEmployee as Employee;
if (aliceAsEmployee is not null)
{
    Console.WriteLine($"{nameof(aliceAsEmployee)} AS an Employee");
}

Null 변수 member로의 접근은 NullReferenceException error를 일으킬 수 있으므로 이것을 사용하기 전 항상 null여부를 확인해야 합니다.

위 예제를 실행하면 다음과 같은 결과를 확인할 수 있습니다.

되도록 이면 is와 as keyword를 사용하여 파생된 type사이에 casting을 시도할 때 발생할 수 있는 예외를 피하는 것이 좋습니다. is와 as를 사용하지 않으면 try~catch문을 통해서라도 InvalidCastException예외를 처리해야 합니다.

10. .NET Type의 상속과 확장

.NET에는 사전에 내장된 수천 가지의 type을 포함하고 있습니다. 따라서 필요한 type을 직접 만들기보다는 필요한 동작에 대한 일부 혹은 전체를 상속받고 해당 기능을 재정의하거나 확장하기 위해 Microsoft의 type 중 하나로부터 파생하는 type을 생성함으로써 좀 더 유리한 출발을 할 수 있습니다.

(1) 예외 상속

상속에 대한 하나의 예로 exception으로부터 새로운 type을 파생해 볼 것입니다.

MyLibrary project에서 PersonException.cs이름의 class file을 추가하고 세 개의 생성자를 가진 PersonException이름의 class를 아래와 같이 정의합니다.

public class PersonException : Exception
{
    public PersonException() : base() { }
    public PersonException(string message) : base(message) { }
    public PersonException(string message, Exception innerException) : base(message, innerException) { }
}

일반적인 method와는 달리, 생성자는 상속되지 않습니다. 그러므로 예제에서는 명시적으로 생성자를 선언하고 명시적으로 System.Exception(또는 이것으로부터 파생시킨 exception class)에 구현된 base 생성자를 호출하여 예제의 PersonException에서 이들 생성자를 사용하고자 하는 개발자가 사용할 수 있도록 하고 있습니다.

Person.cs에서는 DateTime매개변수가 person의 DateOfBirth보다 더 이전의 시간인 경우 예외를 발생시키도록 하는 method를 아래와 같이 정의합니다.

public void TimeTravel(DateTime when)
{
	if (when <= DateOfBirth)
	{
		throw new PersonException("DateTime Exception Error");
	}
	else
	{
		Console.WriteLine($"Welcome to {when:yyyy}!");
	}
}

Program.cs에서는 jun의 TimTravel method를 호출할 때 아래와 같이 날짜를 지정하여 호출하도록 합니다.

try
{
    jun.TimeTravel(when: new(1999, 12, 31));
    jun.TimeTravel(when: new(1970, 06, 01));
}
catch (PersonException ex)
{
    Console.WriteLine(ex.Message);
}

예제를 실행하면 다음과 같은 결과를 확인할 수 있습니다.

자체적으로 예외 type을 정의할 때는 System.Exception에 내장된 것을 명시적으로 호출하는 동일한 세 개의 생성자를 제공해야 합니다. 아마도 상속받고자 하는 다른 exception은 더 많을 수 있습니다.

(2) 상속이 불가능할 때 type 확장하기

이전에 sealed 한정자를 사용하면 상속을 막을 수 있다는 것을 언급한 바 있습니다.

Microsoft는 sealed keyword를 System.String class에 적용하여 누구도 이를 상속받아 string에 대한 동작을 잠재적으로 바꿀 수 없도록 하였습니다.

그럼에도 불구하고 여전히 string으로 새로운 method를 추가하고자 한다면 C# 3.0에서 도입된 extension method를 사용할 수 있습니다. 하지만 잠깐. 확장 method를 제대로 이해하기 위해서는 우선 static method부터 다시 살펴볼 필요가 있습니다.

● 기능 재사용을 위한 static method 사용

C#의 첫 번째 버전부터 문자열이 email주소를 포함하는지에 대한 유효성검증과 같은 기능의 재사용을 위해 정적(static) method를 사용할 수 있었습니다. 이때 이러한 기능의 구현은 추후에 알아볼 정규표현식을 사용할 수 있을 것입니다.

MyLibrary project에서 StringExtensions.cs 이름의 새로운 class file을 아래와 같이 추가합니다.

public class StringExtensions
{
    public static bool IsValidEmail(string input)
    {
        return Regex.IsMatch(input, @"[a-zA-Z0-9\.-_]+@[a-zA-Z0-9\.-_]+");
    }
}

예제의 IsValidEmail method는 static이며 @문자 전후로 사용된 문자들이 유효한지를 확인하는 간단한 email pattern과 일치하는지를 확인하기 위해 Regex type을 사용하고 있습니다.

Program.cs에서는 2가지 email 주소에 대한 유효성을 검증하는 문을 아래와 같이 추가합니다.

string email1 = "aaaa@test.com";
string email2 = "bbbb&test.com";

Console.WriteLine("{0} is a valid e-mail address: {1}", arg0: email1, arg1: StringExtensions.IsValidEmail(email1));
Console.WriteLine("{0} is a valid e-mail address: {1}", arg0: email2, arg1: StringExtensions.IsValidEmail(email2));

예제를 실행하면 다음과 같은 결과를 표시할 것입니다.

예제가 잘 작동하기는 하지만 확장 method를 사용하면 위의 예보다 작성해야 할 code를 훨씬 더 많이 줄일 수 있으며 해당 기능의 용법을 단순화할 수 있습니다.

● 기능 재사용을 위한 extension method 사용

extension method안에서 static method를 생성하는 것만으로 extension method를 쉽게 구현할 수 있습니다.

StringExtensions.cs에서 class앞에 static 한정자를 붙이고 type에도 this한정자를 아래와 같이 붙여줍니다.

public static class StringExtensions
{
    public static bool IsValidEmail(this string input)

위와 같이 하면 compiler는 string type의 확장기능으로서 method가 처리됨을 알게 됩니다.

Program.cs에서는 email 주소가 유효한지 확인이 필요한 string 값에 extention method를 아래와 같이 추가합니다.

Console.WriteLine("{0} is a valid e-mail address: {1}", arg0: email1, arg1: email1.IsValidEmail());
Console.WriteLine("{0} is a valid e-mail address: {1}", arg0: email2, arg1: email2.IsValidEmail());

예제를 통해 IsValidEmail method를 호출하기 위한 문법이 약간 단순해졌음을 알 수 있습니다. 그러나 이전에 문법을 그대로 사용하고자 한다면 그것도 여전히 유요 합니다.

IsValidEmail 확장 method는 IsNormalized처럼 string type의 실제 모든 instance method처럼 표시될 것입니다. 다만 Visual Studio에서는 해당 method가 확장 method인지를 나타내기 위한 아래화살표가 method의 icon으로 사용된다는 것만 차이가 있을 뿐입니다.

예제를 실행하면 이전과 동일한 결과를 표시할 것입니다.

확장 method는 기존에 존재하던 instance method를 교체하거나 재정의될 수 없습니다. 예컨대 기존 Insert method를 그대로 확장 method로서 정의할 수 없습니다. 확장 method는 기존 동일한 이름과 특징을 가진 method가 존재하는 경우 IntelliSense에 표시되지는 않지만 해당 instance method를 호출하게 되면 확장 method를 대신 호출하게 됩니다.

여기까지만 보면 확장 method가 그다지 유용해 보이지 않을 수 있지만 LINQ를 통해 data를 다루는 과정에서는 꽤 유용하게 사용될 수 있습니다.

11. Code 개선하기

이제 C#에 대한 기본적인 것을 익히고 나면 이제 더 나은 code를 작성하기 위해 어떻게 해야 하는지를 고민할 필요가 있는데, 이를 위한 몇 가지 방법이 존재합니다.

(1) 경고를 오류로 취급하기

더 나은 code를 작성하기 위한 간단하면서도 효과적인 방법은 스스로가 compiler의 경고를 무시하지 않고 최대한 이를 수정하는 것입니다. 기본적으로 경고는 무시해도 application을 build 하는 데는 문제가 없지만 필요하면 compiler에게 이들에 대한 위험성 있는 경고를 무지하지 못하도록 요청할 수 있습니다.

csStudy06 solution에서 WarningsAsErrors이름의 Console App project를 생성합니다.

그리고 Program.cs에서 사용자에게 이름을 입력하도록 요청하고 입력된 이름으로 인사말을 표시하도록 아래와 같이 기존의 문을 수정합니다.

Console.Write("Enter a name: ");

string name = Console.ReadLine();

Console.WriteLine($"Hello, {name} has {name.Length} characters!");

위의 예제를 build 하면 성공적으로 build가 이루어지긴 하지만 2개의 compiler경고 또한 같이 생성되는 걸 알 수 있습니다.

...\Program.cs(3,15,3,33): warning CS8600: Converting null literal or possible null value to non-nullable type.
...\Program.cs(5,40,5,44): warning CS8602: Dereference of a possibly null reference.

그런데 build를 다시 수행하면 이번에도 정상적으로 build가 이루어지지만 경고는 사라지는 것을 확인할 수 있습니다.

Visual Studio에서는 Error List를 통해 기존의 경고 message를 계속 확인할 수 있습니다. 또한 경고 message가 사라지는 것은 build를 하는 경우로 rebuild를 하면 계속해서 경고 message를 표시합니다.

Visual Studio의 Build menu나 dotnet 명령줄 도구에서 clean을 사용하여 project를 'clean'할 수 있습니다. 그러면 경고 message는 다음 build시도 때 다시 나타나게 될 것입니다.

이제 csproj(project file)에서 compiler에게 경고를 error로서 취급하도록 아래와 같이 요소를 추가하여 요청하도록 합니다.

<Nullable>enable</Nullable>
<TreatWarningsAsErrors>true</TreatWarningsAsErrors>

예제 project를 다시 build 하면 이번에는 build에 실패하고 2개의 error가 표시됨을 알 수 있습니다.

이전에는 build를 다시 시도하면 경고 message도 사라졌지만 이번에 다시 build를 실행하면 여전히 build는 실패하게 됩니다. 따라서 해당 error를 수정하지 않으면 예제 project는 build 할 수 없을 것입니다.

해당 error를 수정하기 위해 ? nullable 연산자를 string 변수를 선언하는 부분에 추가하고 null값을 확인하고 변수가 null이면 app을 빠져나갈 수 있도록 아래와 같이 code를 변경합니다.

string? name = Console.ReadLine();
if (name == null)
{
    Console.WriteLine("You did not enter a name.");
    return;
}

이 상태에서 예제를 build 하면 error 없이 build가 이루어질 것입니다.

위의 예제와 같은 상황에서 ReadLine method는 실제 null을 반환하지 않습니다. 사용자가 어떠한 값도 입력하지 않으면 null이 아닌 공백을 반환합니다. 이 처럼 절대 null일 수 없는 상황이라면 null-forgiving 연산자를 접미사로 붙여 ReadLine을 호출하면 error를 간단하게 수정할 수 있습니다.
string name = Console.ReadLine()!;

되도록이면 경고를 무시하지 말고 경고를 error로 취급하여 이를 수정하는 것이 좋습니다. ReadLine method가 실제 null을 반환하지 않는다는 것을 compiler가 모르는 issue에 대해서는 개별적으로 해당 경고를 끌 수 있습니다.

(2) Warning wave

새롭게 표시될 수 있는 경고와 error는 C# compiler가 release 될 때마다 추가될 수 있습니다.

기존의 code에서 이렇게 추가된 경고 message가 표시된다면 이들 경고는 warning wave라고 하는 opt-in system에서 도입된 것입니다. Opt-in system은 명시적으로 이들 경고 message를 보겠다는 action을 취하지 않으면 기존의 code에서 새로운 경고 message는 볼 수 없다는 것을 의미합니다.

Warning wave는 csproj(project file)에서 AnalysisLevel요소를 사용함으로써 활성화할 수 있습니다. 예를 들어 .NET 7에서 도입된 warning wave warning을 disable하고자 한다면 AnalysisLevel을 6.0으로 아래와 같이 설정하면 됩니다.

<Nullable>enable</Nullable>
<AnalysisLevel>6.0</AnalysisLevel>

이외에 AnalysisLevel에서 설정가능한 값으로는 다음과 같은 것들이 있습니다.

Level	설명
5.0	Warning wave를 5 warning까지로만 설정합니다.
6.0	Warning wave를 6 warning까지로만 설정합니다.
7.0	Warning wave를 7 warning까지로만 설정합니다.
latest (default)	모든 version의 warning wave를 사용하도록 합니다.
preview	Preview wave를 포함한 모든 version의 warning wave를 사용하도록 합니다.
none	warning을 아예 사용하지 않습니다.

Compiler에게 warning을 error로서 취급하도록 지정했다면 사용되는 warning wave warning은 error를 생성하게 됩니다.

Warning wave 5 진단도구는 C# 9에서 추가된 것으로 다음과 같은 몇몇 예를 포함하고 있습니다.

CS8073	표현식의 결과는 항상 false또는 true여야 한다는 것을 의미합니다. ==와 != 연산자는 struct type s의 instance를 null과 비교할때 항상 false나 true만을 반환합니다. if (s == null) { } // CS8073: The result of the expression is always 'false' if (s != null) { } // CS8073: The result of the expression is always 'true'.
CS8892	동기식 주 진입점인 method가 존재하므로 해당 method가 주요 진입점으로 사용되지 않을것임을 의미합니다. 일반적인 Main method와 async인것이 동시에 존재한다면 일반적인것이 우선적으로 처리되므로 compiler는 async인것은 절대 사용되지 않는다라는 것을 경고하게 되는 것입니다.

Warning wave 6 진단도구는 C# 10에서 추가되었습니다.

CS8826

Partial method 선언에 다른 특징이 있음을 의미합니다.

Warning wave 7 진단도구는 C# 11에서 추가되었습니다.

CS8981

Type의 이름은 ascii 소문자만을 포함해야 함을 말합니다. C# keyword는 모두 ascii 소문자입니다. 이 경고는 모든 type이 향후 C# keyword와 충돌하지 않도록 합니다. 도구, 예를 들어 gRPC service를 위해 .NET proxy를 생성하는 Google의 design 도구와 같은 곳에서 생성된 일부 source code는 해당 경고를 발동하게 됩니다.

아래 link를 통해서는 warning wave에 어떤 warning이 추가되었는지를 확인할 수 있습니다.

C# Compiler warning waves | Microsoft Learn

C# Compiler warning waves

C# warning waves are optional warnings that can be reported on code where previously a warning wouldn't have been reported. They represent practices that could be harmful, or potentially elements that may be breaking changes in the future.

learn.microsoft.com

(3) Code를 개선하기 위한 분석도구 사용하기

.NET analyzer는 잠재적인 문제점을 찾아 이들에 대한 수정방안을 제시하는데 그중에서 StyleCop은 더 나은 C# code를 작성하기 위해 가장 일반적으로 사용되는 분석도구 중 하나입니다.

csStudy06 solution에서 CodeAnalyzing Conole App project를 추가하는데 이때 'Do not use top-level statements'부분을 check 하고 생성합니다.

Project가 생성되면 csproj(project file)에서 아래의 요소를 추가하여 StyleCop.Analyzers에 대한 참조를 추가하도록 합니다.

<ItemGroup>
	<PackageReference Include="StyleCop.Analyzers" Version="1.2.0-*">
		<PrivateAssets>all</PrivateAssets>
		<IncludeAssets>
			runtime; build; native; contentfiles; analyzers;
			buildtransitive
		</IncludeAssets>
	</PackageReference>
</ItemGroup>

Version에서 '1.2.0-*'을 사용하면 현재 시점으로 가장 최신 version인 1.2.0-beta.435가 적용됩니다. 만약 GA로 release 된다면 그때는 version에서 1.2.0만 지정하여 *를 제거할 수 있습니다.

그런 뒤 project에 stylecop.json이름의 file을 추가하고 아래와 같이 StyleCop을 위한 설정을 추가합니다.

{
    "$schema": "https://raw.githubusercontent.com/DotNetAnalyzers/StyleCopAnalyzers/master/StyleCop.Analyzers/StyleCop.Analyzers/Settings/stylecop.schema.json",
    "settings": {
    }
}

예제에서 $schema부분은 code editor에서 stylecop.json을 수정할 때 IntelliSense를 가능하게 합니다. settings영역 안에 내부 설정 부분으로 이동 후 Ctrl + Space key를 누르면 IntelliSense는 설정가능한 정확한 하위요소를 표시하게 됩니다.

다시 CodeAnalyzing project file로 돌아와 application의 배포 시에는 stylecop.json이 포함되지 않도록 하고 AdditionalFiles로 개발 중에서만 처리될 수 있도록 하는 설정요소를 추가합니다.

<ItemGroup>
	<None Remove="stylecop.json" />
</ItemGroup>
<ItemGroup>
	<AdditionalFiles Include="stylecop.json" />
</ItemGroup>

Program.cs에서는 console대신 debug output window로 message를 출력하도록 하는 문을 아래와 같이 추가합니다.

static void Main(string[] args)
{
    Debug.WriteLine("Hello, World!");
}

이 상태에서 project를 build 하면 잘못된 것으로 판단되는 것에 대한 경고 message가 표시될 것입니다.

위에서 message는 using 지시문은 namespace선언 내부에 들어가 있어야 함을 말해주고 있습니다.

warning SA1200: Using directive should appear within a namespace declaration

● 경고 message 억제하기

Code를 추가하거나 구성설정을 포함하여 경고 message자체를 표시하지 않게 하기 위한 몇 가지 방법이 존재합니다.

우선 assembly수준의 attribute를 아래와 같이 추가하면 관련된 경고 message를 표시하지 않게 됩니다.

[assembly:SuppressMessage("StyleCop.CSharp.OrderingRules", "SA1200:UsingDirectivesMustBePlacedWithinNamespace", Justification = "Reviewed.")]

#pragma 지시자문을 경고 message를 발생시키는 구문주위에 아래와 같이 적용해도 위와 동일한 효과를 가질 수 있습니다.

#pragma warning disable SA1200 // Using directives should be placed correctly
using System.Diagnostics;
#pragma warning restore SA1200 // Using directives should be placed correctly

또는 stylecop.json file에서 namespace외부에서 using문을 사용할 수 있도록 하는 설정을 추가할 수도 있습니다.

"settings": {
    "orderingRules": {
        "usingDirectivesPlacement": "outsideNamespace"
    }
}

project를 build 하면 warning SA1200 관련된 경고 message는 더 이상 표시되지 않을 것입니다.

참고로 stylecop.json에서 usingDirectivesPlacement의 설정값을 preserve로 바꾸면 using문은 namespace내/외부에서 모두 사용할 수 있도록 설정됩니다.

"orderingRules": {
    "usingDirectivesPlacement": "preserve"
}

● Code의 수정

이제 다른 경고에 대한 수정을 위해 csproj project file에서 문서화를 위해 자동적으로 XML file을 생성하는 요소를 아래와 같이 추가합니다.

<Nullable>enable</Nullable>
<GenerateDocumentationFile>true</GenerateDocumentationFile>

그리고 stylecop.json에서는 company name이나 copyright 문자열등과 같이 문서화에 필요한 값을 제공하기 위한 구성 옵션을 추가합니다.

"orderingRules": {
    "usingDirectivesPlacement": "preserve"
},
"documentationRules": {
    "companyName": "CLIEL",
    "copyrightText": "Copyright (c) CLIEL. All rights reserved."
}

Program.cs에서는 company와 copyright등과 함께 file header에 사용될 comment를 추가하고 using System.Diagnostics;을 namespace안으로 옮겨 둡니다. 또한 class와 method에 명시적인 접근 한정자와 XML comment를 설정합니다.

namespace CodeAnalyzing;

using System.Diagnostics;

/// <summary>
/// Main Class.
/// </summary>
public class Program
{
    /// <summary>
    /// Main Method.
    /// </summary>
    /// <param name="args">
    /// A string array of arguments.
    /// </param>
    public static void Main(string[] args)
    {
        Debug.WriteLine("Hello, World!");
    }
}

위 예제를 build한뒤 bin/Debug/net7.0 folder를 보면 자동적으로 생성된 CodeAnalyzing.xml이름의 file을 확인할 수 있습니다.

<?xml version="1.0"?>
<doc>
    <assembly>
        <name>CodeAnalyzing</name>
    </assembly>
    <members>
        <member name="T:CodeAnalyzing.Program">
            <summary>
            Main Class.
            </summary>
        </member>
        <member name="M:CodeAnalyzing.Program.Main(System.String[])">
            <summary>
            Main Method.
            </summary>
            <param name="args">
            A string array of arguments.
            </param>
        </member>
    </members>
</doc>

CodeAnalyzing.xml file은 문서화 file로 변환하기 위한 DocFX와 같은 도구를 사용해 처리될 수 있습니다. 자세한 사항은 아래 link를 참고하시기 바랍니다.

Building .NET project docs with DocFX on GitHub Pages - James Croft

● StyleCop의 일반적인 권장사항들

Code file에서는 아래와 같은 여러 항목을 순서대로 정렬해야 합니다.

External alias directive
Using directive
Namespace
Delegate
Enum
Interface
Struct
Classe

Class, record, struct 또는 interface안에서는 다음 항목들을 순서대로 정렬해야 합니다.

Field
Constructor
Destructor (finalizer)
Delegate
Event
Enum
Interface
Property
Indexer
Method
Struct
Nested class와 record

StyleCop에 관한 모든 규칙에 관해서는 아래 link를 참고하시기 바랍니다.

StyleCopAnalyzers/DOCUMENTATION.md at master · DotNetAnalyzers/StyleCopAnalyzers · GitHub

[C# 12와 .NET 8] 5. OOP (Object-Oriented Programming)

클리엘 — Tue, 30 Jan 2024 10:27:45 +0900

C#에서는 OOP를 통해 자신만의 type을 만들 수 있습니다. 이를 위해 data를 저장하기 위한 field와 동작을 수행하는 method를 포함해 type이 가질 수 있는 member들에 대해 encapsul화와 같은 OOP개념을 사용해 볼 것입니다. 여기에 더해 tuple syntax support, out variables, inferred tuple names 그리고 default literals과 같은 언어기능과 간단한 동작을 수행하기 위한 연산자와 지역함수를 정의하는 방법도 함께 살펴보고자 합니다.

1. OOP (Object-Oriented Programming)

현실 세계의 개체는 자동차나 사람과 같은 것이지만 programming에서의 개체는 제품이나 은행 계좌와 같이 현실 세계의 무언가를 나타내는 경우가 많으며 더 추상적인 것일 수도 있습니다.

C#에서 우리는 개체의 type을 정의하기 위해 class와 record 또는 struct와 같은 C# keyword를 사용합니다. class와 struct의 차이에 관한 것은 추후에 알아볼 테지만 type을 개체의 청사진 또는 template으로 생각할 수 있습니다.

OOP의 개념을 요약하면 대략 아래와 같이 설명할 수 있습니다.

Capsule화(Encapsulation) : 개체와 관련된 data와 동작의 결합을 말합니다. 예를 들어 '은행계좌'라는 개체는 '잔액'과 '예금주'라는 data를 가질 수 있고 '입금'과 '출금'이라는 동작을 가질 수 있습니다. 캡슐화할 때는 개체의 내부 상태에 대한 접근이나 변경을 외부로부터 제한하는 방식을 통해 동작이나 data로의 접근을 통제할 수 있습니다.
합성(composition) : 개체를 무엇으로 구성할지에 관한 것입니다. 예를 들어 자동차라는 개체는 4개의 wheel개체와 몇몇 좌석개체 그리고 engine과 같은 다른 부분으로 구성될 수 있습니다.
집합(Aggregation) : 개체와 결합될 수 있는 것을 말합니다. 예를 들어 사람은 자동차의 구성요소가 아니지만 운전석에 자리 잡게 되면 자동차의 driver가 됩니다. 즉, 2개의 분리된 개체가 서로 결합하여 새로운 component로 만들어지게 되는 것입니다.
상속(Inheritance) : 기반 혹은 super class로 부터 파생되어 하위 class를 생성함으로써 code를 재사용하는 것을 말합니다. 기반 class의 모든 기능이 상속되어 파생 class에서 사용할 수 있게 되는데 예를 들어 기반 혹은 super Exception class는 모든 예외에 대한 동일한 구현을 가진 몇 가지 member를 가지고 있으며 sub 혹은 파생 SqlException class에서는 이들 member를 상속하여 database연결 속성과 같이 SQL Database 예외가 발생할 때와 관련된 확장된 member를 가지게 됩니다.
다형성(Polymorphism) : 파생된 class에서 상속된 동작을 override 하도록 허용하는 것으로서 이를 통해 파생된 class에서는 본래 class와 다른 동작을 제공할 수 있습니다.

2 Class Library 만들기

Class library assembly는 type을 쉽게 배포가능한 단위(DLL file)로 group화 합니다. 단위 test를 배울 때를 제외하곤 지금까지 code를 작성하기 위해 console application만을 생성해 왔습니다. 여러 project에 걸쳐 재사용가능한 code를 만들려면 Microsoft가 하는 것처럼 class library assembly로 만들어야 합니다.

(1) Class library 생성

재사용 가능한 .NET class library를 만들기 위해 우선 csStudy05라는 solution을 생성하고 그 안에 'NetLibraryStandard2'이름의 Class Library project를 추가합니다. NetLibraryStandard2.csproj file을 열어보면 아래와 같이 .NET 8을 target으로 하는 .NET SDK 8에 의해 project가 만들어졌으며 따라서 해당 project는 다른 .NET 8 호환 assembly에만 참조될 수 있음을 알 수 있습니다.

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

</Project>

위 상태에서 아래와 같이 TargetFramework를 'netstandard2.0'로 변경하고 C# 12 compiler를 사용한다는 것을 명시적으로 지정하기 위한 요소와 모든 C# file로 정적 System.Console class를 정적 import하기 위한 요소를 추가합니다.

<Project Sdk="Microsoft.NET.Sdk">
    <PropertyGroup>
        <TargetFramework>netstandard2.0</TargetFramework>
        <LangVersion>12</LangVersion>
        <ImplicitUsings>enable</ImplicitUsings>
        <Nullable>enable</Nullable>
    </PropertyGroup>

    <ItemGroup>
	    <Using Include="System.Console" Static="true" />
    </ItemGroup>
</Project>

C# 12 compiler를 사용한다고 지정하더라도 .NET platform을 동일하게 맞춰주지 않으면 일부 언어기능을 사용할 수 없는 경우가 있습니다. 예를 들어 C# 8에서 도입된 interface의 기본구현은 .NET Standard 2.1을 필요로 하며 C# 11에서 도입된 required keyword는 .NET 7의 attribute를 필요로 합니다.

이제 csproj file을 저장한뒤 기본적으로 생성한 Class1.cs file로 삭제합니다. 그리고 project를 build 하여 이후에 다른 project에서도 참조가능하도록 설정합니다.

최신의 C#언어와 .NET platform 기능을 사용하기 위해서는 .NET 8 Class Library를 생성해야 합니다. 하지만 .NET Core, .NET Framework, Xamarin과 같은 이전 .NET platform을 지원하려면 .NET Standard 2.0 class library를 생성해야 합니다. 기본적으로 .NET Standard 2.0은 C# 7.0 compiler를 사용하지만 이 설정은 변경할 수 있기 때문에 .NET Standard 2.0 API로 제한한다고 하더라도 최신 SDK와 compiler에 대한 혜택을 여전히 사용할 수 있습니다.

(2) Namespace에 class를 정의하기

이제 필요한 class를 정의할 차례입니다. 'NetLibraryStandard2' project에 Person.cs file을 추가하고 기존 구문을 모두 삭제한 뒤 아래와 같이 CLIEL.Shared라는 Namespace를 설정합니다. 이는 해당 file에서 정의된 type을 명시하는 것입니다.

namespace CLIEL.Shared;

가능한한 논리적으로 명명된 namespace로 class를 생성하는 것이 좋습니다. namespace이름은 예를 들어 숫자와 관련된 경우 System.Numerics와 같이 domain고유의 이름이 될 수 있습니다. 이 경우 예제에서는 Person, BackAccount 그리고 WonderOfTheWorld와 같은 type을 생성할 텐데 이들에 대한 전형적인 이름을 정하지는 않았으므로 CLIEL.Shared로 사용할 것입니다.

그다음 public keyword를 사용한 Person class를 아래와 같이 작성합니다.

namespace CLIEL.Shared;

public class Person
{

}

위 예제의 public C# keyword는 class이전에 와야 합니다. 이 keyword는 접근 한정자로서 해당 class library외부의 다른 모든 code로부터 접근을 허용하기 위한 것입니다.

만약 명시적으로 public keyword를 적용하지 않는다면 해당 class를 정의한 assembly안에서만 접근이 가능하게 됩니다. 아무것도 지정하지 않은 class는 암시적인 접근한정자로 internal을 사용하기 때문입니다. 예제에서 해당 class는 외부 assembly에서도 접근가능하도록 할 것이기 때문에 public으로 class를 정확히 지정해야 합니다.

target이 .NET 6.0 이후로 맞춰져 있고 따라서 C# 10 이후를 사용한다면 code를 간소화하기 위해 semicolon으로 namespace를 선언하고 중괄호를 제거하는 것으로 끝낼 수 있습니다. 따라서 type정의는 들여 쓰기를 하지 않아도 됩니다. 이는 file-scoped namespace선언이라는 것으로 file당 하나의 file-scoped namespace를 가질 수 있습니다.

예제에서는 언어기능을 명시적으로 C#11을 사용할 것이라 csproj file에서 명시하였으므로 가능한 형태이며 만약 그렇게 하지 않은 경우라면 예제는 이전 version의 style로 다음과 같이 만들어야 합니다.

namespace CLIEL.Shared
{
    public class Person
    {
    }
}

(3) 접근 한정자의 이해

상가 예제의 class에는 public keyword를 사용하였으며 해당 keyword가 접근한정자에 해당합니다. public은 외부 class library를 포함해 외부에서 해당 class로 접근이 가능하도록 합니다. 만약 class에 별도의 한정자를 적용하지 않는다면 암시적으로 internal이 적용되며 이는 해당 class가 정의된 같은 assembly안에서만 접근이 가능하도록 합니다. 예제는 외부에서 접근이 가능하도록 만들 것이므로 명시적으로 public을 적용해야 합니다.

class내부의 다른 class처럼 class가 중첩된 경우 내부 class는 private 한정자를 적용하여 상위 class에서 접근하지 못하게 할 수 있습니다. 또한 .NET 7에서는 file한정자가 도입되었는데 이는 code file안에서만 접근이 가능하도록 하는 것으로서 하나의 file에 여러 class를 정의하는 경우 유용하게 사용될 수 있습니다.

file 접근 한정자에 관해서는 아래 글을 참고하시기 바랍니다.

C# reference - C# | Microsoft Learn

C# reference - C#

C# reference

learn.microsoft.com

가장 흔하게 사용되는 한정자로는 public과 internal이 있습니다. internal은 한정자를 지정하지 않은 경우 기본적으로 적용되기는 하지만 되도록이면 internal이라도 code의 가독성을 위해 명시적으로 internal을 지정해 주는 것이 좋습니다.

(4) Member의 이해

예제의 type은 아직까지는 capsule화된 어떠한 member도 가지고 있지 않습니다. 이제 몇 가지 member를 추가할 텐데 member는 field, method가 될 수 있고 이 둘 모두에 대한 특수한 version이 될 수도 있습니다. member가 될 수 있는 각각의 항목은 아래와 같습니다.

Field : data를 저장하는데 사용되며 또한 3가지로 분류될 수 있습니다. 그중 첫 번째는 Constant라는 것으로 compiler가 해당 field의 값에 대해 값을 읽는 모든 code에 그대로 복사하여 처리함으로써 field의 값이 바뀔 수 없도록 합니다. 두 번째는 Read-Only인데 이는 class가 instance화 된 후에 값이 바뀔 수 없도록 하는 것입니다. 다만 instance화 되는 시점에 data는 외부로부터 설정될 수 있습니다. 마지막 세 번째는 Event로 하나 또는 그 이상의 method를 참조하는 data를 말합니다. 해당 method는 어떤 사건이 발생할 때 실행되는 것으로서 button의 click을 예로 들 수 있습니다. Event에 관한 자세한 내용은 추후에 알아볼 것입니다.
Method : 특정 구문을 실행하는데 사용되는 것으로 '함수'부분을 배워볼 때 몇 가지 예제를 만들어본 적 있었습니다. 또한 method는 4가지 정도로 분류될 수 있는데 그중 첫 번째는 Contructor(생성자)라고 하는 것으로 new keyword를 통해 class의 instance를 memory에 할당할 때 실행되는 method입니다. 두 번째 Property는 data를 저장하거나 읽을 때 실행되는 것으로 data는 일반적으로 field에 저장하지만 외부에 저장하거나 계산되어 처리될 수도 있습니다. 일반적으로 속성은 field의 memory 주소를 노출하기보다는 field를 capsule화 하는데 선호되는 방법입니다. 세 번째 Indexer는 'array'구문인 []을 사용해 data를 저장하거나 값을 가져올 때 실행되는 것이며 마지막 네 번째는 type을 대상으로 +나 /와 같은 연산자를 사용할 때 실행되는 것입니다.

(5) Class의 Instance생성

어떤 class를 사용하려면 해당 class에 대한 instance를 생성해야 하는데 만약 class가 정의된 것과 다른 project에서 사용하는 경우라면 해당 project에서 사용하고자 하는 class를 가진 assembly를 참조해야 합니다.

실제 이러한 과정을 거쳐보기 위해 csStudy05 solution에서 PeopleApp이라는 이름의 Console App project를 추가합니다. project가 생성되고 나면 해당 project에서 mouse 오른쪽 button을 눌러 'Add Project Reference...' menu를 선택합니다. 이어서 'NetLibraryStandard2' project를 확인하고 checkbox에 check 한 후 OK button을 눌러 해당 project를 참조추가한 뒤 project를 build 합니다.

(6) Type을 사용하기 위한 namespace importing

이제 Person class를 사용하기 위한 구문을 작성할 것입니다. PeopleApp의 Program.cs에서 기존 구문을 모두 삭제하고 Person class에 대한 namespace를 아래와 같이 추가합니다.

using CLIEL.Shared;

물론 위의 namespace를 전역적으로 import 할 수 있으나 project에서 namespace가 import 되는 Program.cs file이 있으며 사용할 type의 import문이 해당 file의 위에 존재한다면 해당 code를 읽는 누구에게나 명확해질 수 있는 장점도 있습니다.

그리고 Peron type의 instance를 생성하고 해당 instance를 통해 자체적인 설명을 출력하도록 합니다. 아래 예제의 new keyword는 개체를 memory에 할당하며 모든 내부 data를 초기화합니다.

Person kim = new();
Console.WriteLine(kim.ToString());

예제를 보면 ToString이라는 method를 호출하고 있는데 실제 Person class를 보면 아무것도 존재하지 않습니다. 그럼 어떻게 ToString method가 사용될 수 있을까? 이런 것이 가능한 이유는 잠시 후 알아보기로 하고 일단 project를 실행하여 아래와 같은 결과가 표시되는지를 확인합니다.

● using alias를 통한 namespace충돌 방지하기

흔한 경우는 아니지만 같은 이름의 type을 가진 2개의 namespace가 존재할 수도 있는데 이 둘의 namespace가 import 되면 ambiguity를 유발할 수 있습니다. 예를 들어

// Suncheon.Gagokdong.cs
namespace Suncheon
{
	public class Gagokdong
	{
	}
}
// Miryang.Gagokdong.cs
namespace Miryang
{
	public class Gagokdong
	{
	}
}
// Program.cs
using Suncheon;
using Miryang;

Gagokdong g = new();

위 예제의 경우 compiler는 아래와 같이 Error CS0104를 발생시키게 됩니다.

'Gagokdong' is an ambiguous reference between 'Suncheon.Gagokdong' and 'Miryang.Gagokdong'

이런 경우에는 namespace 중 하나에 alias를 정의함으로써 namespace가 구별될 수 있도록 해야 합니다.

using Suncheon;
using m = Miryang;

Gagokdong g1 = new();
m.Gagokdong g2 = new();

● using alias를 통한 type명 변경

alias가 필요한 또 다른 상황은 type의 이름을 변경하는 경우입니다. 예를 들어 Environment class를 많이 사용하는 경우라면 해당 type을 이름을 간소하게 변경해 아래와 같이 사용할 수 있을 것입니다.

using Env = System.Environment;

WriteLine(Env.OSVersion);
WriteLine(Env.MachineName);
WriteLine(Env.CurrentDirectory);

(7) 개체의 이해

비록 예제의 Person class는 명시적으로 어떤 type으로부터 상속되도록 구현하지 않았지만 모든 type은 직간접적으로 System.Object라는 이름의 특별한 type으로 부터 상속됩니다.

ToString method의 구현은 System.Object안에 이루어진 것이며 전체 namespace와 type명을 출력하게 됩니다.

Person class로 다시 돌아가 아래와 같이 compiler에게 Person은 System.Object type으로 부터 상속됨을 명시적으로 알려줄 수도 있습니다.

public class Person : System.Object
{
}

A class를 B class가 상속받을 때 A는 기반(base) 또는 superclass라고 하며 B는 파생(derived) 또는 subclass라고 합니다. 따라서 이 경우 System.Object는 기반(superclass) class가 되며 Person은 파생(subclass)이 됩니다.

참고로 C#에서 object keyword는 System.Object의 별칭에 해당하므로 아래와 같은 방법으로도 구현할 수 있습니다.

public class Person : object
{
}

● System.Object로 부터의 상속

위에서 처럼 Person class를 명시적으로 object로부터 상속받게 한 뒤 object가 가진 모든 member를 확인해 보도록 하겠습니다. code에서 object keyword를 click 하고 F12 key를 누르거나 object keyword를 mouse 오른쪽 button을 눌러 'Go to Definition'을 선택합니다.

그러면 Microsoft가 정의한 System.Object type과 해당 member들을 다음과 같이 확인해 볼 수 있습니다. 아직까지는 모든 항목에 대한 상속을 이해할 필요가 없지만 여기서 ToString이름의 method가 존재함을 알 수 있습니다.

	public class Object
	{
		//
		// Summary:
		//     Initializes a new instance of the System.Object class.
		public Object();

		//
		// Summary:
		//     Allows an object to try to free resources and perform other cleanup operations
		//     before it is reclaimed by garbage collection.
		~Object();

		//
		// Summary:
		//     Determines whether the specified object instances are considered equal.
		//
		// Parameters:
		//   objA:
		//     The first object to compare.
		//
		//   objB:
		//     The second object to compare.
		//
		// Returns:
		//     true if the objects are considered equal; otherwise, false. If both objA and
		//     objB are null, the method returns true.
		public static bool Equals(Object objA, Object objB);
		//
		// Summary:
		//     Determines whether the specified System.Object instances are the same instance.
		//
		// Parameters:
		//   objA:
		//     The first object to compare.
		//
		//   objB:
		//     The second object to compare.
		//
		// Returns:
		//     true if objA is the same instance as objB or if both are null; otherwise, false.
		public static bool ReferenceEquals(Object objA, Object objB);
		//
		// Summary:
		//     Determines whether the specified object is equal to the current object.
		//
		// Parameters:
		//   obj:
		//     The object to compare with the current object.
		//
		// Returns:
		//     true if the specified object is equal to the current object; otherwise, false.
		public virtual bool Equals(Object obj);
		//
		// Summary:
		//     Serves as the default hash function.
		//
		// Returns:
		//     A hash code for the current object.
		public virtual int GetHashCode();
		//
		// Summary:
		//     Gets the System.Type of the current instance.
		//
		// Returns:
		//     The exact runtime type of the current instance.
		public Type GetType();
		//
		// Summary:
		//     Returns a string that represents the current object.
		//
		// Returns:
		//     A string that represents the current object.
		public virtual string ToString();
		//
		// Summary:
		//     Creates a shallow copy of the current System.Object.
		//
		// Returns:
		//     A shallow copy of the current System.Object.
		protected Object MemberwiseClone();
	}

class에 상속이 지정되지 않으면 System.Object로부터 기본적으로 상속이 이루어집니다.

(8) Class의 기본 생성자 정의하기

C#12부터는 Class의 일부로서 하나의 생성자를 정의할 수 있습니다. 이를 기본생성자(primary constructor)라고 하는데 문법은 record에서의 positional data member와 동일하지만 실제 동작에서는 약간의 차이가 있습니다.

본래 class를 정의할 때 생성자는 class내부에 위치합니다.

public class AnimalClass
{
  public AnimalClass(string Name, string Species)
  {

  }
}

위 예제에서 기본생성자를 적용하게 되면 Class의 정의를 더욱 단순하게 구현할 수 있고

public class AnimalClass(string Name, string Species)
{

}

일반적인 class처럼 매개변수에 필요한 값을 전달하여 instance를 생성할 수 있습니다.

AnimalClass ac = new("Nyao", "Cat");

다만 record와 다르게 class에서는 매개변수에 필요한 속성에 public을 자동으로 구현해 주지 않기 때문에 값이 들어간 속성은 class외부에서 접근할 수 없습니다. 따라서 필요한 속성은 아래와 같이 추가해 줘야 합니다.

public class AnimalClass(string name, string species)
{
  public string Name { get; set; } = name;
  public string Species { get; set; } = species;
}

AnimalClass ac = new("Nyao", "Cat");
Console.WriteLine(ac.Name);

예제를 실행하면 다음과 같은 결과를 확인할 수 있습니다.

매개변수가 없는 생성자를 추가하는 경우에도 아래와 같은 방법으로 기본값을 기본 생성자로 전달할 수 있습니다.

public class AnimalClass(string name, string species)
{
  public string Name { get; set; } = name;
  public string Species { get; set; } = species;

  public AnimalClass() : this("Mong", "Dog") { }
}

AnimalClass ac = new();
Console.WriteLine(ac.Name);

아래 URL을 참고하면 class와 구조체에 대한 더 많은 기본 생성자정보를 확인할 수 있습니다.

Declare and use primary constructors in classes and structs - C# | Microsoft Learn

Declare and use primary constructors in classes and structs - C#

Learn how and when to declare primary constructors in your class and struct types. Primary constructors provide concise syntax to declare constructor parameters available anywhere in your type.

learn.microsoft.com

3. Field에 data 저장하기

이제 person 관한 정보를 저장하기 위해 class에 몇몇 field를 정의할 것입니다.

(1) Field 정의

사람은 자신의 이름과 생일이라는 날짜를 가지고 있으므로 이 두 개의 값으로 person을 구성할 것입니다. 이때 person class내부에서는 이 둘의 값을 capsule화 하여 외부에서 해당 값이 보일 수 있도록 해야 합니다.

Person class에서 사람의 이름과 생일을 저장하기 위한 2개의 public field를 선언하는 구문을 아래와 같이 추가합니다.

public class Person : object
{
	public string? Name;
	public DateTime DateOfBirth;
}

예제에서 DateOfBirth field에 대한 data type에는 여러 가지를 선택할 수 있습니다. .NET 6에서는 DateOnly type을 도입했는데 이 것은 시간을 제외하고 날짜만 저장하도록 합니다. 반면 DateTime은 날짜와 시간 모두를 저장할 수 있습니다. 또는 DateTimeOffset을 선택할 수도 있는데 이는 날짜, 시간, time zone까지도 저장합니다. 어느 것을 선택할지는 얼마만큼 상세한 정보의 저장이 필요한가에 달려 있습니다.

C#8부터 compiler는 string과 같은 참조 type이 null값을 가질 수 있는 경우 경고를 표시할 수 있으며 잠재적으로 NullReferenceException예외를 발생시킬 수 있습니다. .NET 6 이후부터 SDK는 이들 경고를 기본적으로 표시하도록 하고 있는데 해당 참조type에 ?의 접미사를 붙여 null을 허용하고 있음을 표시할 수 있고 그러면 경고문구는 나타나지 않을 것입니다. null가능과 이와 같은 경우를 어떻게 처리할 수 있는지에 대한 자세한 사항은 추후에 알아볼 것입니다.

field는 하나의 field에 여러 값을 저장해야 하는 경우 array나 list와 dictionary와 같은 collection을 포함해 어떤 type이든 사용할 수 있습니다. 예제에서는 단지 하나의 이름과 하나의 생일값만을 가집니다.

(2) 접근 한정자(Access modifier)

접근 한정자는 capsule화의 일부로서 member를 어떠한 방식으로 노출할지를 지정하는 것입니다. 예제의 class에서는 명시적으로 field에 public keyword를 적용했는데 만약 이렇게 하지 않았더라면 암시적으로 private이 적용되어 해당 member는 오로지 class의 내부에서만 접근 가능한 형태가 됩니다.

접근한정자는 총 4개의 종류가 있으며 추가로 2개의 접근 한정자 keyword를 결합해 field나 method와 같은 class의 member에 적용할 수 있습니다.

private	type안에서만 접근가능하며 아무런 접근한정자도 적용하지 않으면 private이 기본으로 적용됩니다.
internal	type내부와 같은 assembly안의 모든 type에서 접근할 수 있습니다.
protected	type내부와 해당 type을 상속한 type에서만 접근할 수 있습니다.
public	외부 어디서든 접근할 수 있습니다.
internal protected	type내부와 같은 assembly안의 모든 type 그리고 해당 type을 상속한 모든 type에서 접근할 수 있습니다. 'internal or protected'형태의 접근한정자와 동일합니다.
private protected	type내부와 type을 상속한 그리고 같은 assembly의 모든 type에서 접근할 수 있습니다. 'internal and protected'형태의 접근한정자와 동일하며 해당 한정자는 C# 7.2이후에서만 사용할 수 있습니다.

member에 암시적으로 적용되는 접근 한정자를 사용한다고 하더라도 이를 생략하지 말고 모든 member에 접근한정자 중 하나를 명시적으로 지정하는 것이 좋습니다. 일반적으로 field는 private 혹은 protected를 사용하며 field의 값을 설정하고 가져오기 위해 public속성을 생성하여 접근을 제한하는 데 사용합니다.

(3) Field에 값 설정하고 가져오기

Program.cs에서 kim을 instance화 한 이후에는 이름과 생일을 설정할 수 있는 구문을 추가할 수 있고 설정된 값을 아래와 같이 불러올 수 있습니다.

kim.Name = "kimya";
kim.DateOfBirth = new DateTime(1980, 12, 01);

Console.WriteLine($"{kim.Name}은 {kim.DateOfBirth}에 태어남.");

값을 확인하는데 보간문자열을 사용하고 있으며 실제 예제를 실행하면 다음과 같은 결과를 확인할 수 있습니다.

참고로 위 결과는 해당 PC의 지역화와 문화권설정에 따라 다르게 보일 수 있습니다.

여기서 DateOfBirth는 몇 가지 형식화된 값을 가져올 수 있는데 dddd로 요일의 이름을, d로는 날짜를 표현할 수 있습니다. MMMM은 월의 이름을 나타내며 소문자 m으로는 시간에서 분을 의미합니다. yyyy는 전체 연도를 표시하며 yy는 2 자릿수 연도를 표시합니다.

또한 C# 3.0부터 도입된 중괄호를 사용한 '개체 초기자' 구문을 사용해 field를 초기화할 수 있습니다.

기존 구문아래에 'hong'이름의 새로운 person개체를 생성하기 위한 구문을 추가합니다. 해당 예제에서 값을 가져올 때는 DateOfBirth속성에 특정 형식화를 적용하였습니다.

Person hong = new() {
	Name = "honggd",
	DateOfBirth = new (1982, 09, 29)
};

Console.WriteLine($"{kim.Name}은 {kim.DateOfBirth: yyyy-MM-dd}에 태어남.");

예제를 실행하면 결과는 다음과 같을 것입니다.

(4) Enum type을 사용한 값 저장

때로는 값이 option의 제한된 설정중 하나여야 하는 경우가 있습니다. 예를 들어 세계 7대 불가사의 중 좋아하는 한 가지를 선택하는 것처럼 다수 중에 하나의 값을 설정하거나 또는 이와 관련해 가보고 싶은 곳에 대한 bucket list처럼 여러 값을 설정하는 것입니다. 이러한 형태의 data를 저장하기 위해서 우리는 enum type을 정의할 수 있습니다.

Enum type은 내부적으로 문자열설명의 순람표(lookup table)와 함께 정수값을 사용함으로써 하나 또는 그 이상의 선택적 data를 저장하기에 효율적인 방법을 제공합니다.

NetLibraryStandard2 project에 WondersOfTheAncientWorld.cs이름의 file을 아래와 같이 추가합니다.

namespace NetLibraryStandard2
{
	public enum WondersOfTheAncientWorld
	{
		GreatPyramidOfGiza,
		HangingGardensOfBabylon,
		StatueOfZeusAtOlympia,
		TempleOfArtemisAtEphesus,
		MausoleumAtHalicarnassus,
		ColossusOfRhodes,
		LighthouseOfAlexandria
	}
}

이어서 Person.cs에서는 아래와 같은 field를 추가하고

public WondersOfTheAncientWorld FavoriteAncientWonder;

Program.cs에서 해당 field로 값을 설정하고 확인합니다.

Person hong = new()
{
	Name = "honggd",
	DateOfBirth = new(1982, 09, 29)
};

hong.FavoriteAncientWonder = NetLibraryStandard2.WondersOfTheAncientWorld.StatueOfZeusAtOlympia;

Console.WriteLine($"{hong.Name} : {hong.FavoriteAncientWonder} / {(int)hong.FavoriteAncientWonder}")

해당 project를 실행하면 다음과 같은 결과를 표시할 것입니다.

enum값은 내부적으로 효율성을 위해 int값을 사용해 저장합니다. 이때 int값은 자동적으로 0부터 할당되므로 예제의 enum에서 세 번째 불가사의항목은 2 값을 가지게 됩니다. 물론 필요에 따라서는 이 순서를 따르지 않은 다른 값을 저장하는 것도 가능합니다. 다만 값과 일치되는 것을 찾을 수 없는 경우에는 이름대신 int값을 출력하게 됩니다.

(5) Enum type을 사용한 다수값 저장하기

위에서 예로든 bucket list의 경우에는 enum에 대한 array나 collection을 생성할 수도 있을 것입니다. 하지만 더 좋은 방법이 있는데 enum flag를 사용한 단일값으로 여러 선택값을 결합하는 것입니다.

예제의 enum에 아래와 같이 [Flags] attribute를 적용하고 명시적으로 각 항목에 byte값이 사용되도록 한 뒤 실제 bit column마다 다른 값을 표현하여 값을 설정합니다.

[Flags]
public enum WondersOfTheAncientWorld : byte
{
	None = 0b_0000_0000, //0
	GreatPyramidOfGiza = 0b_0000_0001, //1
	HangingGardensOfBabylon = 0b_0000_0010, //2
	StatueOfZeusAtOlympia = 0b_0000_0100, //4
	TempleOfArtemisAtEphesus =  0b_0000_1000, //8
	MausoleumAtHalicarnassus = 0b_0001_0000, //16
	ColossusOfRhodes = 0b_0010_0000, //32
	LighthouseOfAlexandria = 0b_0100_0000 //64
}

예제에서는 명시적으로 memory에 저장된 bit를 확인할 때 겹치지 않는 각 항목에 값을 할당하였습니다. 또한 enum type에 는 System.Flags attribute를 적용했기 때문에 값이 반환될 때 int값 대신 자동적으로 comma로 분리된 다수의 값과 일치하는 문자열을 반환할 수 있습니다.

일반적으로 enum type은 내부적으로 int 변수를 사용하지만 그리 큰 값은 필요하지 않기 때문에 byte를 사용하면 4byte가 아닌 1byte만 있으면 되므로 75% 정도의 필요한 memory를 절약할 수 있습니다. 또 다른 예로 요일을 위한 enum을 정의할 때도 단지 7개 정도의 항목이 있으면 되기 때문에 byte의 사용이 유리할 수 있습니다.

위 예제를 통해 만약 Hanging Gardens of Babylon과 Mausoleum at Halicarnassus를 포함하는 bucket list를 표현하고자 한다면 16과 2에만 1bit의 설정을 주면 됩니다. 다시 말해 18 값을 저장하는 것입니다.

64	32	16	8	4	2	1
0	0	1	0	0	1	0

Person.cs에서는 아래와 같이 BucketList field를 추가하고

public WondersOfTheAncientWorld FavoriteAncientWonder;
public WondersOfTheAncientWorld BucketList;

Program.cs에서는 |(OR bit 논리) 연산자를 사용해 enum값을 결합하여 bucket list를 설정하는 구문을 추가합니다. 혹은 enum type으로 형변환하는 숫자 18의 값을 사용해 저장할 수도 있습니다. 다만 code를 읽기 어렵게 만들 수 있기 때문에 숫자를 직접적으로 사용하는 것은 권하지 않습니다.

hong.BucketList = WondersOfTheAncientWorld.HangingGardensOfBabylon | WondersOfTheAncientWorld.MausoleumAtHalicarnassus;
//혹은 이렇게도 가능 hong.BucketList = (WondersOfTheAncientWorld)18;
Console.WriteLine($"{hong.Name}의 bucket list {hong.BucketList}");

예제를 실행하면 다음과 같은 결과를 표시할 것입니다.

분리된 option의 결합을 저장할 때는 enum값을 사용합니다. 이때 option이 최대 8개라면 byte를, 16개라면 ushort를, 32개라면 uint를, 64 이상이라면 ulong을 사용합니다.

(6) Collection을 사용한 다수의 값 저장

만약 person에 대한 자녀를 저장해야 한다면 이를 위한 field도 추가해야 하며 이를 위해 어떠한 type이든 정렬된 collection을 저장할 수 있는 generic List<T> collection type을 사용할 것입니다. 이것은 자녀가 현재 person과 관련이 있지만 person자체에 대한 일부가 아닌 class의 instance이므로 class에 집계를 적용하는 하나의 예가 될 수 있습니다. 참고로 collection에 관해서는 추후에 자세히 다룰 것입니다.

Person.cs에서 person의 자녀를 나타내는 여러 Person intance를 저장할 field를 아래와 같이 선언합니다.

public WondersOfTheAncientWorld BucketList;
public List<Person> Children = new();

List<Person>은 Person에 대한 List입니다. 따라서 Children이름의 속성 type은 Person intance의 list에 해당하는 것입니다.

또한 collection은 item이 추가되기 전에 새로운 intance로 초기화되어야 합니다. 그렇지 않으면 field는 null이 되고 Add와 같은 member의 사용을 시도하게 되면 runtime 예외를 발생시키게 됩니다.

(7) generic(일반화) collection

List<T> type에서 <>는 C#에서 2005년 C# 2.0에서 도입된 일반화라 불리는 기능으로서 collection을 강력한 type으로 만들 수 있습니다. 이로 인해 compiler는 collection에 저장될 수 있는 개체의 type을 특정할 수 있고 따라서 code의 성능과 정확성을 향상됩니다.

강력한 type은 정적인 type과는 다른 의미를 가집니다. 예전 System.Collection type은 정적 type으로서 System.Object를 다루기 위한 것이었습니다. 그러나 새로운 System.Collection.Generic type은 강력한 type의 <T> instance를 다루기 위한 정적 type이라고 할 수 있습니다. (irony 하게도 generic이라는 용어는 좀 더 구체적인 정적 type을 사용할 수 있다는 것을 의미합니다.)

Program.cs에서 hong에 대한 2명의 자녀를 추가하고 얼마나 많은 자녀를 가지고 있는지, 그리고 그 자녀에 대한 이름이 무엇인지를 표시하는 구문을 작성합니다.

hong.Children.Add(new Person { Name = "kim" }); // C# 3.0 부터
hong.Children.Add(new() { Name = "lee" }); // C# 9.0 부터

Console.WriteLine($"{hong.Name}에게는 {hong.Children.Count} 명의 자녀가 있음 => ");

for (int i = 0; i < hong.Children.Count; i++)
{
	Console.WriteLine($" {hong.Children[i].Name}");
}

참고로 예제는 for문을 사용했으나 collection을 열거하기 위한 것으로 foreach문의 사용도 가능합니다.

위 예제를 실행하면 다음과 같은 결과를 표시합니다.

(8) 정적 field

예제를 통해 지금까지 만들어온 field는 모두 intance member이며 생성된 class의 각 instance에 대한 각각의 field에 다른 값이 존재합니다. 예제에서도 kim과 hong Person은 서로 다른 Name값을 가지고 있습니다.

하지만 때로는 모든 instance에 걸쳐 공유되는 단 하나의 값을 가지는 field가 필요할 때도 있습니다.

이는 field만이 정적 member가 될 수 있는 것은 아니기에 정적 member라고 하는데 static filed를 통해 이를 구현할 수 있습니다.

NetLibraryStandard2 project에 BankAccount.cs이름의 새로운 class file을 생성하고 해당 class에 3개의 field를 추가합니다. 이중 2개는 intance field이며 다른 하나는 static field입니다.

public class BankAccount
{
	public string AccountName;
	public decimal Balance;
	public static decimal InterestRate;
}

BankAccount의 각 intance는 자체적인 AccountName과 Balance값을 가지지만 이들 모든 instnace는 하나의 InterestRate값을 공유할 것입니다.

Program.cs에서는 InterestRate에 값을 설정하고 2개의 BankAccount에 대한 intance를 생성하는 구문을 추가합니다.

BankAccount.InterestRate = 0.012M;

BankAccount kbAccount = new();
kbAccount.AccountName = "kb";
kbAccount.Balance = 2400;

Console.WriteLine(format: "{0} earned {1:C} interest.", arg0: kbAccount.AccountName, arg1: kbAccount.Balance * BankAccount.InterestRate);

BankAccount hcAccount = new();
hcAccount.AccountName = "hc";
hcAccount.Balance = 98;

Console.WriteLine(format: "{0} earned {1:C} interest.", arg0: hcAccount.AccountName, arg1: hcAccount.Balance * BankAccount.InterestRate);

위 예제를 실행하면 다음과 같은 결과를 확인할 수 있습니다.

예제에서 1:C는 형식화 code로서 .NET에게 number를 통화형식으로 사용할 것을 알려주게 됩니다. 사용되는 통화형식은 설치된 운영체제의 설정을 따릅니다.

다만 현재 thread의 속성을 설정함으로써 통화기호나 다른 data형식을 결정하는 문화권을 조정할 수 있습니다. 예를 들어 영국으로의 문화권을 설정하고자 한다면 Program.cs상단에 아래와 같이 code를 작성할 수 있습니다.

Thread.CurrentThread.CurrentCulture = System.Globalization.CultureInfo.GetCultureInfo("en-GB");

앞서 언급했듯이 field만이 정적 member가 될 수 있는 것은 아닙니다. Constructor(생성자), method, property 등도 정적 member가 될 수 있습니다.

(9) constant field

field의 값이 절대 바뀔 수 없는 경우라면 const keyword를 사용해 compile time에 실제값을 할당할 수 있습니다.

Person.cs에서 Person에 대한 인종을 설정하는 string constant를 아래와 같이 추가합니다.

public List<Person> Children = new();
public const string Species = "Homo Sapiens";

constant field의 값을 가져오려면 class의 intance이름이 아닌 class자체의 이름을 사용해야 합니다. Program.cs에서 아래와 같이 hong의 이름과 함께 인종을 표시하는 구문을 추가합니다.

Console.WriteLine($"{hong.Name} is a {Person.Species}");

예제를 실행하면 다음과 같은 결과를 표시합니다.

Microsoft type에 대한 const field의 예로 System.Int32.MaxValue나 System.Math.PI 등을 들 수 있습니다. 이들의 값은 절대 바뀔 수 없습니다.

const사용 시에는 2가지 사항에 대해 주의해야 합니다. 우선 값은 반드시 선언과 동시에 할당되어야 하며 string이나 bool 또는 숫자같이 실제 표현가능한 값이어야 합니다. const field에 대한 모든 참조는 compile time에 실제값으로 바뀌게 되므로 향후 version에서 값이 바뀌게 될 때 새로운 값을 가져오기 위해 참조하는 모든 assembly를 recompile 하지 않으면 값은 반영되지 않습니다.

(10) 읽기 전용 field

값이 바뀔 수 없는 field에 대한 또 다른 방법으로 read-only field가 있습니다.

Person.cs에서 readonly field를 선언하고 거주 중인 행성의 이름을 저장합니다.

public readonly string HomePlanet = "Earth";

Program.cs에서는 hong의 이름과 함께 위에서 저장한 행성의 이름을 표시하는 구문을 추가합니다.

Console.WriteLine($"{hong.Name} is a {hong.HomePlanet}");

예제를 실행한 결과는 다음과 같습니다.

readonly field는 runtime에서 값을 읽어 들일 수 있으며 실행가능한 모든 구문에서 표현될 수 있습니다. 따라서 값의 설정을 위해 생성자를 사용하거나 field에 값을 직접 할당할 수 있습니다. readonly field에 대한 모든 참조는 live 참조로서 관련된 모든 기능은 호출 code에서 정확하게 반영될 것입니다. 이것이 const와 readonly와의 가장 중요한 차입니다.

경우에 따라서는 static readonly field를 선언할 수 있습니다. 이렇게 되면 type에 대한 모든 intance에 걸쳐 값이 해당 값을 공유할 수 있습니다.

(11) 생성자를 통한 field의 초기화

때로 field는 runtime에서 초기화가 필요한 경우도 있습니다. 이러한 동작은 class로 new keyword를 사용해 intance를 생성할 때 호출되는 생성자를 통해 구현할 수 있습니다. 생성자자는 모든 field가 type을 사용하는 code에 의해 설정되기 전에 실행됩니다.

Person.cs에서 읽기 전용 field인 HomePlanet다음에 새로운 읽기전용 field를 정의하고 생성자에서 Name과 Instantiated field를 설정하는 구문을 아래와 같이 추가합니다.

public readonly string HomePlanet = "Earth";
public readonly DateTime Instantiated;

public Person()
{
	Name = "Unknown";
	Instantiated = DateTime.Now;
}

그다음 Program.cs에서 새로운 person에 대한 intance를 생성하고 초기 field값을 표시하도록 합니다.

Person blankPerson = new();

Console.WriteLine(format: "{0} of {1} was created at {2:hh:mm:ss} on a {2:dddd}.", arg0: blankPerson.Name, arg1: blankPerson.HomePlanet, arg2: blankPerson.Instantiated);

예제를 실행하면 결과를 다음과 같을 것입니다.

(12) intance 생성 시 속성에 설정 강제하기

C# 11에서는 required 한정자를 도입하였는데 이를 속성이나 field에 사용한다면 compiler는 해당 속성이나 field의 값을 instance생성 시 설정하도록 요구하게 됩니다. 참고로 C# 11이므로 .NET 7 이상을 필요로 합니다.

csStudy05 solution에서 MyLibrary이름의 class library project를 .NET 8에(.NET 7부터 지원함) 맞춰 생성합니다. 그리고 해당 project에 Book.cs이름의 file을 추가하고 여기에 4개의 속성을 아래와 같이 추가합니다. 이때 아래 속성 중 2개는 required를 적용합니다.

namespace CLIEL.Shared
{
	public class Book
	{
		public required string? Isbn { get; set; }
		public required string? Title { get; set; }
		public string? Author { get; set; }
		public int PageCount { get; set; }
	}
}

예제에서 3개의 string 속성은 nullable입니다. 속성이나 field에 required를 적용하는 것이 null이 될 수 없다는 것을 뜻하는 것이 아닙니다. 단지 속성이나 field에 할당처리가 되어야 한다는 것을 말하는 것이기 때문에 명시적으로 null을 설정할 수도 있습니다.

Program.cs에서 Book에 대한 intance를 Isbn과 Title속성을 설정하지 않고 생성하려고 하면 다음과 같이 오류를 발생시키게 됩니다.

따라서 개체 초기화 구문을 통해 아래와 같이 2개의 required속성을 설정하도록 하면 정상적으로 instance가 생성될 것입니다.

Book book = new()
{
	Isbn = "123-4567890000",
	Title = "The Little Prince"
};

Console.WriteLine("{0}: {1} written by {2} has {3:N0} pages.", book.Isbn, book.Title, book.Author, book.PageCount);

다시 MyLibrary project의 Book.cs로 돌아와 이번에는 생성자 한쌍을 정의하는 구문을 추가하는데, 이때 아래와 같이 하나는 초기화 구문을 지원하도록 하고 2개의 required속성을 설정하도록 합니다. 이때 해당 생성자에는 [SetsRequiredMembers] attribute를 적용하여 compiler에게 생성자를 통해 required 속성이 설정되고 있음을 명시적으로 알려줘야 합니다.

public Book() { }

[SetsRequiredMembers]
public Book(string? isbn, string? title)
{
	Isbn = isbn;
	Title = title;
}

이를 통해 Program.cs에서는 이전에 Book의 초기화 문대신 아래와 같은 생성자를 통해 어떠한 required속성도 설정할 필요 없이 instance를 생성할 수 있게 됩니다.

Book book = new(isbn: "123-4567890000", title: "The Little Prince")
{
	Author = "Antoine de Saint-Exupéry",
	PageCount = 100
};

예제를 실행하면 아래와 같은 결과를 표시합니다.

(13) 생성자를 통해 field초기화 하기

어떤 경우는 field가 runtime에 초기화(값의 설정)가 되어야 할 때가 있는데 이는 new keyword를 통해 class를 intance화 할때 호출되는 생성자로 실현할 수 있습니다

Person.cs에서 readonly HomePlanet다음에 두 번째 readonly field인 Instantiated를 정의하고 Name과 Instantiated field에 값을 설정합니다.

public readonly DateTime Instantiated;
public Person()
{
   Name = "Unknown"; 
  Instantiated = DateTime.Now;
}

그런 다음 새로운 Person의 intance를 생성하고 초기화된 field의 값을 표시하도록 합니다.

Person blankPerson = new();
WriteLine("Name : {Name}, Instantiated : {Instantiated}");

예제를 실행하면 다음과 같은 결과를 표시할 것입니다.

(14) 다중 생성자 정의하기

필요하다면 하나의 type에 여러 생성자를 가질 수 있습니다. 이 것은 특히 개발자가 field에 대한 초기값을 설정하도록 권장하는데 유용하게 사용될 수 있습니다.

Person.cs에서 개발자가 Person의 Name과 HomePlanet에 초기값을 설정할 수 있는 두 번째 생성자를 정의합니다.

public Person(string initialName, string homePlanet)
{
	Name = initialName;
	HomePlanet = homePlanet;
	Instantiated = DateTime.Now;
}

Program.cs에서는 또 다른 Person의 Intance를 생성하는데 이때 두 개의 매개변수를 가진 두 번째 생성자를 사용하도록 합니다.

Person gunny = new(initialName: "Matthew Paige Damon", homePlanet: "Mars");
Console.WriteLine(format: "{0} of {1} was created at {2:hh:mm:ss} on a {2:dddd}.", arg0: gunny.Name, arg1: gunny.HomePlanet, arg2: gunny.Instantiated);

예제의 실행결과는 다음과 같습니다.

생성자는 다소 특별한 method로 분류될 수 있는데 method와 관련해서는 이어서 좀 더 자세히 알아보도록 하겠습니다.

3. Method의 호출과 작성

Method는 여러 구문을 실행하는 type의 member라고 할 수 있습니다. 즉 type에 속하는 함수입니다.

(1) 값을 반환하는 method

Method는 단일 값을 반환하거나 아무것도 반환하지 않을 수 있습니다. 어떤 동작을 수행하지만 값을 반환하지 않는 경우라면 method의 이름 앞에 void type을 사용해 표시하고 그렇지 않고 값을 반환한다면 method의 이름 앞에 반환하는 값의 type을 사용해 표시합니다.

예를 들어 아래 예제를 위해 2개의 method를 생성할 예정인데 각각의 method는 다음과 같습니다.

WriteToConsole : console에 text를 출력하는 method로서 동작만 수행할 뿐 아무런 값도 반환하지 않을 것이므로 해당 method에는 void keyword를 적용합니다.
GetOrigin : 해당 method는 text값을 반환하므로 method에 string keyword를 적용합니다.

Person.cs에서 위 2개의 method를 정의하는 구문을 아래와 같이 추가합니다.

public void WriteToConsole()
{
	WriteLine($"{Name} was born on a {DateOfBirth:dddd}.");

}

public string GetOrigin()
{
	return $"{Name} was born on {HomePlanet}.";
}

그리고 Program.cs에서는 위 method를 호출하는 구문을 아래와 같이 작성합니다.

Person hong = new()
{
	Name = "honggd",
	DateOfBirth = new(1982, 09, 29)
};

hong.WriteToConsole();
Console.WriteLine(hong.GetOrigin());

예제를 실행하면 다음과 같은 결과를 표시합니다.

(2) 매개변수를 정의하고 Method로 전달하기

method는 동작하는데 필요한 값을 얻기 위해 전달가능한 매개변수를 가질 수 있습니다. 매개변수는 변수의 선언과 비슷하게 정의될 수 있지만 이전 예제에서의 생성자와 같이 method의 괄호 안에 들어간다는 차이가 있습니다.

Person.cs에서 2개의 method를 정의하는데 첫 번째 method는 매개변수를 가지지 않고 두 번째 method는 하나의 매개변수를 가집니다.

public string SayHello()
{
	return $"{Name} says 'Hello!'";
}

public string SayHelloTo(string name)
{
	return $"{Name} says 'Hello, {name}!'";
}

Program.cs에서는 위 2개의 method를 호출하고 console에 반환값을 출력하는 구문을 아래와 같이 추가합니다.

Console.WriteLine(hong.SayHello());
Console.WriteLine(hong.SayHelloTo("kim"));

예제를 실행한 결과는 다음과 같습니다.

method를 호출하는 구문을 typing 할 때 IntelliSense는 tootip으로 이름과 함께 매개변수의 type, 그리고 method의 반환 type을 표시할 것입니다.

(3) Method overload

이름이 다른 2개의 method를 정의하는 대신 우리는 하나의 method에 같은 이름을 부여할 수 있습니다. 이 것은 method가 각각 다른 매개변수를 가지게 함으로써 가능합니다. 그리고 이미 이에 대한 예로서 위에서 생성자를 선언하면서 확인해 본 바가 있습니다.

Person.cs에서 SayHelloTo method의 이름을 SayHello로 변경합니다. 그리고 Program.cs에서도 역시 method의 호출 부분을 SayHello로 변경합니다. 이때 tootip을 통해서 해당 method가 1 of 2와 2 of 2를 통해 추가적인 overload가 있음을 다음과 같이 표시하게 됩니다.

overload 된 method를 사용하면 class의 method가 적은 것처럼 나타낼 수 있고 class자체를 더욱 간소화하게 만들 수 있습니다.

(4) 선택적 그리고 명명된 매개변수 전달

Method를 간소화하기 위한 또 다른 방법으로는 매개변수를 선택적으로 만드는 것입니다. 이는 method내부의 매개변수에 기본값을 할당함으로써 가능합니다. 이때 선택적 매개변수는 반드시 매개변수의 마지막에 와야 합니다.

Person.cs에서 아래와 같이 3개의 선택적 매개변수를 갖는 method를 정의합니다.

public string OptionalParameters(string command = "Run!", double number = 0.0, bool active = true)
{
	return string.Format(format: "command is {0}, number is {1}, active is {2}", arg0: command, arg1: number, arg2: active);
}

그리고 Program.cs에서는 method를 호출하고 console에 결과를 표시하도록 하는 구문을 아래와 같이 추가합니다.

Console.WriteLine(hong.OptionalParameters());

이때도 역시 IntelliSense는 tooltip을 통해 기본값을 가진 3개의 선택적 매개변수를 다음과 같이 표시할 것입니다.

예제를 실행한 결과는 다음과 같습니다.

이번에는 Program.cs에서 command 매개변수에 string을 number 매개변수에 double값을 아래와 같이 전달합니다.

Console.WriteLine(hong.OptionalParameters("Jump!", 95.5));

다시 예제를 실행하면 다음의 결과를 표시하게 됩니다.

command의 기본값과 number 매개변수의 기본값은 전달한 값으로 바뀌었으나 active의 기본값은 여전히 true를 갖고 있습니다.

● Method 호출 시 매개변수 명명하기

명명매개변수는 선언한 순서에 따라 값이 다른 순서로 전달될 수 있도록 하기 때문에 method를 호출할 때 종종 선택적 매개변수와 결합하여 사용하기도 합니다.

Program.cs에서 command 매개변수에 string값을, number 매개변수에 double값을 전달하도록 합니다. 이때, 명명된 매개변수를 사용하는데 순서를 이전과 다르게 지정합니다.

Console.WriteLine(hong.OptionalParameters(number: 52.7, command: "Hide!"));

예제를 실행하면 결과는 다음과 같습니다.

이러한 명명된 매개변수를 사용하면 일부 선택적 매개변수를 생략하는 데에도 사용할 수 있습니다. Program.cs에서 선택적 순서를 통해 command 매개변수로 string값을 전달하고 number 매개변수는 생략합니다. 또한 action 매개변수는 명명된 매개변수를 사용하도록 합니다.

Console.WriteLine(hong.OptionalParameters("Pooling!", active: false));

예제를 실행한 결과는 다음과 같습니다.

(5) 매개변수 전달 방식 제어하기

매개변수가 method로 전달될 때는 아래 3가지 중 하나의 방식이 사용될 수 있습니다.

값 (기본방식) : 입력전용으로 처리됩니다.
out 매개변수 : 출력전용으로 처리되며 매개변수 선언과 함께 기본값을 지정할 수 없고 초기화되지 않은 채로 남아있을 수 없습니다. 따라서 반드시 method내부에서 값이 설정되어야 합니다. 그렇지 않으면 compiler는 error를 발생시키게 될 것입니다.
ref 매개변수 : 입력과 출력으로 동시에 사용될 수 있습니다. out 매개변수와 같이 ref 매개변수 또한 기본값을 가질 수 없으며 이미 method외부에서 값이 설정되어 있기 때문에 method내부에서 반드시 값을 설정하는 처리를 필요로 하지 않습니다.
in 매개변수 : 매개변수의 값이 변경될 수 없으며 그러한 행위가 시도되면 compiler는 error를 발생시키게 됩니다.

입력과 출력으로 매개변수를 전달하는 예제를 만들어 보기 위해 Person.cs에서 4개의 매개변수를 가진 method를 정의합니다. 이 중 하나는 값매개변수이고 다른 하나는 in, ref, 마지막 하나는 out 매개변수입니다.

static void PassingParameters(int w, in int x, ref int y, out int z)
{
  z = 100;
  y++;
  //x++; x는 in입니다. 값을 변경하려 한다면 error가 발생합니다.
  w++;

  Console.WriteLine($"In the PassingParameters: w={w}, x={x}, y={y}, z={z}");
}

Program.cs에서는 3개의 int변수를 선언하고 이들을 method로 전달합니다.

int a = 10;
int b = 20;
int c = 30;
int d = 40;

Console.WriteLine($"Before: a = {a}, b = {b}, c = {c}, d = {d}");
PassingParameters(a, b, ref c, out d);
Console.WriteLine($"After: a = {a}, b = {b}, c = {c}, d = {d}");

예제를 실행하고 다음과 같은 결과를 확인합니다.

Before: a = 10, b = 20, c = 30, d = 40
In the PassingParameters: w=11, x=20, y=31, z=100
After: a = 10, b = 20, c = 31, d = 100

기본적으로 매개변수로 변수를 전달할 때는 변수 자체가 아닌 전달된 현재 값을 가져오게 됩니다. 따라서 w는 변숫값의 복사본을 가지게 되고 변수는 본래값 10을 계속 유지할 수 있습니다.

in 매개변수가 사용되는 경우에는 해당 변수에 대한 참조가 method로 전달됩니다. 그러므로 x는 b를 참조하게 됩니다. x는 PassingParameters method안에서 변경될 수 없지만 method밖에서 b의 값은 바뀔 수 있고 그러면 PassingParameters method에도 바뀐 값이 적용됩니다.

ref 매개변수로 변수를 전달하는 경우에는 method로 전달된 변수의 참조를 가져오게 됩니다. 따라서 y는 c에 대한 참조가 됩니다. c변수가 증가된 값을 가지게 되면 y 매개변수 역시 증가된 값을 가지게 됩니다.

out 매개변수로 변수를 전달하는 경우에는 method로 전달된 변수의 참조를 가져오게 됩니다. 따라서 z는 d에 대한 참조가 되고 d변숫값은 method안에서 실행되는 code에 의해 바뀌게 됩니다. 예제에서는 Before로의 출력을 위해 d변수에 값을 할당했지만 사실 이 부분만 아니면 변수 d에 값을 할당하지 않아도 됩니다. 해당 변수는 어쨌거나 다른 값으로 바뀌기 때문입니다.

● out 매개변수 간소화

C# 7부터는 out 매개변수를 사용하는 code를 더욱 간소화할 수 있게 되었습니다.

Program.cs에서 변수를 더 선언하고 f이름의 inline선언 out 매개변수를 추가합니다. f는 본래 존재하지 않던 변수지만 out 매개변수를 통해 method에서 처리되면서 해당 변수를 사용할 수 있게 됩니다.

int a = 10;
int b = 20;
int c = 30;

Console.WriteLine($"Before: a = {a}, b = {b}, c = {c}");
PassingParameters(a, b, ref c, out int d);
Console.WriteLine($"After: a = {a}, b = {b}, c = {c}, d = {d}");

예제를 실행한 결과는 다음과 같습니다.

Before: a = 10, b = 20, c = 30
In the PassingParameters: w=11, x=20, y=31, z=100
After: a = 10, b = 20, c = 31, d = 100

(6) ref return

C# 7부터 ref keyword는 method로의 매개변수 전달뿐만 아니라 return 값에도 적용될 수 있습니다. 결과를 반환할 때 실제 값이 아닌 참조를 반환하도록 함으로써 외부 변수가 내부 변수를 참조하고 method가 호출된 후 해당 값이 수정될 수 있도록 합니다.

Person.cs에서 하나의 array변수와 특정 index의 참조를 반환하는 method를 추가합니다.

private int[] position = new int[3];
public ref int GetValue(int index)
{
	return ref position[index];
}

Program.cs에서 해당 method를 호출하는 2개의 문을 추가합니다.

ref int v = ref hong.GetValue(1);

v = 10;

Console.WriteLine(hong.GetValue(1));

예제의 실행결과는 다음과 같습니다.

예제는 method내부 변수의 참조를 통해 외부에서 값을 변경하고 다시 method안에서 해당 값을 확인하고 있습니다.

(7) tuple을 사용한 다중 값 반환하기

Method는 기본적으로 하나의 type에 대한 하나의 값만을 반환할 수 있습니다. 여기서 type은 이전 예제와 같이 string이 될 수 있고 Person과 같이 복합 type이 될 수도 있습니다. 혹은 List<Person>과 같이 collection type을 반환하는 것도 가능합니다.

그런데 만약 GetTheData이름의 method를 만들어야 하는데 해당 method에서 string값과 int값을 둘 다 받아야 하는 경우라면 어떻게 할 수 있을까? 쉽게는 TextAndNumber와 같은 string field와 int field를 갖는 새로운 class를 정의하고 해당 type의 intance를 반환하도록 할 수 있을 것입니다.

public class TextAndNumber
{
	public string Text;
	public int Number;
}
public class Human
{
	public TextAndNumber GetTheData()
	{
		return new TextAndNumber
		{
			Text = "Hong",
			Number = 25
		};
	}
}

하지만 둘의 값을 결합하기 위해 꼭 class를 정의할 필요는 없습니다. C#은 이런 경우에 사용가능한 tuple이라는 것을 사용할 수 있는데 Tuple은 2개 혹은 그 이상의 값을 하나의 단위로 결합하기 위한 효율적인 방식을 제공합니다.

Tuple은 F#과 같은 어떤 언어에서는 첫 version부터 지원하기 시작했지만 .NET에서는 2010년 .NET 4.0부터 System.Tuple type을 통해 tuple을 지원하기 시작했습니다.

● C# 언어에서의 tuple지원

C#이 괄호(())를 사용해 tuple을 위한 언어 구문을 지원하는 것은 2017년 C# 7.0에서만 가능했습니다. 같은 시간 .NET은 일부 일반적인 scenaris에서 old version의 .NET 4.0 System.Tuple type보다 더 효율적인 새로운 System.VlueTuple type추가하였으며 이것으로 더욱 효율적인 구문을 사용할 수 있게 되었습니다.

Person.cs에서는 string과 int를 결합한 tuple을 반환하는 method를 정의하는 구문을 아래와 같이 추가합니다.

public (string, int) GetFruit()
{
	return ("Apples", 5);
}

그리고 Program.cs에서 위의 GetFruit method를 호출하고 tuple의 field를 출력하는 구문을 추가합니다. 이때 field는 Item1과 Item2라는 이름이 자동적으로 부여됩니다.

(string, int) fruit = hong.GetFruit();
Console.WriteLine($"{fruit.Item1} - {fruit.Item2}");

예제를 실행하면 다음과 같은 결과를 표시합니다.

● Tuple field의 Naming

tuple의 field에 접근하기 위해서는 기본적으로 Item1, Item2등의 이름을 사용할 수 있습니다.

하지만 명시적으로 각 field에 이름을 부여하는 것도 가능합니다. Person.cs에서 field의 이름과 함께 tuple을 반환하는 method를 아래와 같이 정의합니다.

public (string Name, int Number) GetNamedFruit()
{
	return (Name: "Apples", Number: 5);
}

Progam.cs에서는 method를 호출하는 구문을 추가하고 tuple의 field를 이름을 사용하여 출력하도록 합니다.

var fruitNamed = hong.GetNamedFruit();
Console.WriteLine($"There are {fruitNamed.Number} {fruitNamed.Name}.");

위 예제는 다음과 같은 형태로도 사용할 수 있습니다.

(int Number, string Name) fruitNamed = bob.GetNamedFruit();

예제를 실행하면 다음과 같은 결과를 볼 수 있습니다.

만약 다른 개체에서 생성된 tuple이라면 C# 7.1에서 도입된 tuple name inference(tuple 이름 추론)이라는 기능을 사용할 수도 있습니다.

다시 Program.cs에서 string과 int값으로 구성된 2개의 tuple을 생성합니다.

var thing1 = ("kim", 3);
Console.WriteLine($"{thing1.Item1} has {thing1.Item2} children.");

var thing2 = (hong.Name, hong.Children.Count);
Console.WriteLine($"{thing2.Name} has {thing2.Count} children.");

C# 7.0에서는 위 2가지 모두 Item1과 Item2라는 이름 체계를 사용합니다. 또한 C# 7.1부터는 thing2는 Name과 Count라는 이름을 추론할 수도 있습니다.

● Tuple 분해

Tuple은 또한 개별적인 변수로 분해될 수 있습니다. 이 방식은 명명된 field tuple과 같은 문법으로 구현되지만 tuple에 대한 변수가 없습니다.

//2개의 field를 가진 tupe변수로 받는것이 아닌
(string TheName, int TheNumber) tupleWithNamedFields = hong.GetNamedFruit();

//2개의 변수로 받음
(string Name, int Number) = hong.GetNamedFruit();

이렇게 함으로써 tuple자체를 각각의 새로운 변수로 분해하게 됩니다. Program.cs에서 GetFruit method로 반환된 tuple을 분해하는 구문을 아래와 같이 추가합니다.

(string Name, int Number) = hong.GetFruit();

Console.WriteLine($"Deconstructed: {Name}, {Number}");

● Tuple 별칭

Tuple을 별칭화 하는 건 C#12에 도입된 것으로 type을 명명하고 이를 변수를 선언할 때 type과 pamater의 이름으로서 사용할 수 있도록 하는 것입니다.

using UnnamedParameters = (string, int);

using NamedParamters = (string Name, int Number);

참고로 Tuple 별칭을 사용할 때는 title case(pascal case)를 사용합니다.

위와 같은 방식으로 tuple type을 선언하면 다음과 같이 매개변수 type이 동일한 경우 해당 tuple type으로 값을 받을 수 있습니다.

using NamedParamters = (string Name, int Number);

(string Name, int Number) = hong.GetNamedFruit();

● Type 해체

tuple만이 분해될 수 있는 유일한 type이 아닙니다. 모든 type은 개체를 부분적으로 분해할 수 있는 Deconstruct란 특별한 method를 가지고 있습니다. Person.cs에서는 부분적으로 나누고자 하는 out 매개변수가 정의된 2가지 Deconstruct method를 추가합니다.

public void Deconstruct(out string? name, out DateTime dob)
{
	name = Name;
	dob = DateOfBirth;
}

public void Deconstruct(out string? name, out DateTime dob, out WondersOfTheAncientWorld fav)
{
	name = Name;
	dob = DateOfBirth;
	fav = FavoriteAncientWonder;
}

예제에서 사용된 out keyword에 관해서는 추후에 자세히 알아볼 것입니다.

그리고 Program.cs에서 hong을 분해하는 구문을 아래와 같이 추가합니다.

var (name1, dob1) = hong;
Console.WriteLine($"Deconstructed: {name1}, {dob1}");

var (name2, dob2, fav2) = hong;
Console.WriteLine($"Deconstructed: {name2}, {dob2}, {fav2}");

개체를 tuple변수에 할당할 때 암시적으로 호출되므로 예제와 같이 Deconstruct method를 명시적으로 호출하지 않습니다.

이제 예제를 실행하면 아래와 같은 결과를 표시할 것입니다.

5. partial을 사용한 class분리

여러 team의 member로 구성된 대규모 project를 구축하는 경우 또는 크고 복잡한 class를 구현할 때는 여러 file에 걸쳐 class를 나누어 정의하는 것이 필요할 수 있는데 이것은 partial keyword를 통해 구현할 수 있습니다.

또 하나 예를 들어 database로부터 schema 정보를 읽는 개체-관계(object-relational) mapper와 같은 도구에 의해 자동적으로 생성된 Person class에 어떤 구문을 추가해야 한다면 해당 class가 partial로 정의되어 있을 때 우리는 class를 자동으로 생성된 code file과 임의로 작성된 code로 나눌 수 있습니다.

위와 같은 상황에 있다고 가정했을 때 Person class를 어떻게 작성할 수 있을지 예제를 통해 알아보도록 하겠습니다.

Person.cs에서 아래와 같이 partial keyword를 추가합니다.

public partial class Person : object

그런 뒤 NetLibraryStandard2 project에 PersonAutoGen.cs라는 이름의 file을 아래와 같이 추가합니다.

namespace CLIEL.Shared
{
	public partial class Person
	{
	}
}

앞으로 Person.cs에 작성될 code는 이제 PersonAutoGen.cs에서 작성할 것입니다.

6. Property와 Indexer를 통한 접근 제어

이전 예제에서는 Person의 origin과 name을 포함한 string을 반환하는 GetOrigin method를 생성했었습니다. Java와 같은 언어에서는 이와 같은 것을 많이 하는데 C#은 property라는 더 나은 방법을 갖고 있습니다.

property는 단순화된 method(또는 method의 쌍)으로서 값을 가져오거나 설정할 때 어떤 동작을 수행하며 field처럼 값을 확인할 수 있는데, 비교적 간단한 구문을 통해 이를 구현할 수 있습니다.

(1) 읽기 전용 property 정의

읽기 전용 property는 단지 get만 구현된 것을 말합니다.

PersonAutoGen.cs file의 Person class에서 아래 3개의 속성을 정의합니다.

첫 번째 속성은 C#의 모든 version에서 작동하는 property 구문을 사용한 GetOrigin method와 동일한 역할을 수행합니다.
두 번째 속성은 C# 6부터 사용가능한 lambda 표현식 본문인 => 구문을 사용해 환영 message를 반환합니다.
세 번째 속성은 person에 대한 age를 계산합니다.

public partial class Person
{
	public string Origin
	{
		get
		{
			return string.Format("{0} was born on {1}", arg0: Name, arg1: HomePlanet);
		}
	}

	public string Greeting => $"{Name} says 'Hello!'";
	public int Age => DateTime.Today.Year - DateOfBirth.Year;
}

Program.cs에서는 위 속성에 대한 값을 가져오는 구문을 아래와 같이 추가합니다.

Person hong = new()
{
	Name = "honggd",
	DateOfBirth = new(1982, 09, 29)
};

Console.WriteLine(hong.Origin);
Console.WriteLine(hong.Greeting);
Console.WriteLine(hong.Age);

예제를 실행하면 아래와 같은 결과를 확인할 수 있습니다.

(2) 설정 가능 property 정의

설정가능한 속성을 생성하려면 get뿐만 아니라 set부분 method를 같이 한쌍으로 제공해야 합니다.

PersonAutoGen.cs에서 get과 set method(getter와 setter)를 가진 string 속성을 아래와 같이 추가합니다.

public string? FavoriteIceCream { get; set; }

예제에서는 Person의 좋아하는 ice cream을 저장하기 위한 field를 정의하지 않았지만 위와 같은 code만으로 compiler는 자동적으로 필요한 field를 생성합니다.

때로는 속성의 값이 설정될 때 더 세세한 제어가 필요할 수 있는데 이런 경우에는 해당 기능에 필요한 구문과 함께 속성에 값을 저장하기 위한 private field를 임의로 생성해야 합니다.

PersonAutoGen.cs에서 string field와 get과 set을 가진 string 속성을 아래와 같이 정의합니다.

private string? favoritePrimaryColor;
public string? FavoritePrimaryColor
{
	get
	{
		return favoritePrimaryColor;
	}

	set
	{
		switch (value?.ToLower())
		{
			case "red":
			case "green":
			case "blue":
				favoritePrimaryColor = value;
				break;
			default:
				throw new ArgumentException($"{value} is not a primary color. Choose from: red, green, blue.");

		}
	}
}

되도록이면 getter와 setter에 너무 많은 code가 들어가지 않도록 해야 합니다. code가 너무 긴 경우에는 private method를 추가하여 getter와 setter에서 호출하도록 해 code를 간소화하는 것이 좋습니다.

Program.cs에서는 person의 FavoriteIceCream과 FavoritePrimaryColor를 설정하는 구문을 추가하고 설정값을 출력하도록 합니다.

hong.FavoriteIceCream = "Vanilla";
Console.WriteLine($"hong's favorite ice-cream flavor is {hong.FavoriteIceCream}.");

string color = "Red";
try
{
	hong.FavoritePrimaryColor = color;
	Console.WriteLine($"hong's favorite primary color is {hong.FavoritePrimaryColor}.");
}
catch (Exception ex)
{
	Console.WriteLine("Tried to set {0} to '{1}': {2}", nameof(hong.FavoritePrimaryColor), color, ex.Message);
}

예제를 실행하면 다음과 같은 결과를 표시할 것입니다.

color에는 red, green, blue 이외에 다른 값의 설정을 시도하면 다음과 같은 결과를 표시하게 됩니다.

field에 대한 값을 설정하고 읽을 때 되도록이면 GetAge나 SetAge와 같은 method의 사용을 피하고 속성을 사용하는 것이 좋습니다.

(3) Indexer 정의

Indexer는 호출 code가 배열문법을 통해 속성으로 접근할 수 있도록 합니다. 예를 들어 string type에서는 indexer를 정의하고 있으므로 호출 code가 string에 있는 각각의 문자에 아래와 같이 접근할 수 있습니다.

string alphabet = "abcdefghijklmnopqrstuvwxyz";
char letterF = alphabet[5]; // f

Person에서도 children으로의 접근을 간소화하기 위해 indexer를 정의할 수 있습니다.

PersonAutoGen.cs에서 child의 index를 통해 child를 설정하고 가져올 수 있는 indexer를 아래와 같이 정의합니다.

public Person this[int index]
{
	get { return Children[index]; }
	set { Children[index] = value; }
}

또한 indexer의 재정의를 통해 int값을 전달하는 것 외에 매개변수에 string 같은 다른 type을 사용할 수 있습니다.

PersonAutoGen.cs에서 child의 이름을 사용해 child를 설정하고 가져올 수 있는 indexer를 아래와 같이 정의합니다.

public Person this[string name]
{
	get
	{
		return Children.Find(p => p.Name == name);
	}
	set
	{
		Person found = Children.Find(p => p.Name == name);

		if (found is not null)
			found = value;
	}
}

List<T>와 같은 collection과 lambda 식에 관해서는 추후에 자세히 알아볼 것입니다.

Program.cs에서는 hong에 대한 2개의 children을 추가하고 각각의 방식을 통해 Child에 접근하는 문을 아래와 같이 추가합니다.

hong.Children.Add(new()
{
	Name = "gil",
	DateOfBirth = new(2014, 6, 28)
});

hong.Children.Add(new()
{
	Name = "young",
	DateOfBirth = new(2015, 10, 11)
});

//Children List 사용
Console.WriteLine($"Hong's first child is {hong.Children[0].Name}.");
Console.WriteLine($"Hong's second child is {hong.Children[1].Name}.");

//integer position indexer 사용
Console.WriteLine($"Hong's first child is {hong[0].Name}.");
Console.WriteLine($"Hong's second child is {hong[1].Name}.");

// indexer명 사용
Console.WriteLine($"Hong's child named Ella is {hong["gil"].Age} years old.");

예제를 실행하면 다음과 같은 결과를 표시할 것입니다.

7. Method 확장하기

기본적인 method의 활용은 이전에 이미 살펴본 바 있습니다. 자주 사용되는 것은 아니지만 method의 좀 더 효율적인 활용을 위해 추가적인 몇몇 사항들을 더 알아보고자 합니다.

+나 *와 같은 연산자는 숫자에만 적용될 수 있는 것은 아닙니다. 예를 들어 Person의 instance에 적용되어 +나 *와 같은 연산자에 동작할 수 있는 method를 생성하고 연산자를 재정의함으로써 2개의 Person에 +연산자를 적용하는 경우 결혼을, *연산자를 적용하는 경우 아이의 출산과 같은 동작을 구현할 수 있습니다.

Instance method는 개체 자체에서 동작하는 것이며 static(정적) method는 type에서 동작하는 것입니다. 어떤 것을 선택할지는 동작에 가장 접합한 것이 무엇이냐에 따라 달라집니다.

비슷한 동작을 수행하기 위한 정적 method와 instance method를 둘 다 정의하는 것은 때로는 현명한 수단이 될 수 있습니다. 예를 들어 string은 Compare라는 정적 method와 CompareTo라는 instance method를 가지고 있으며 개발자는 편의에 따라 어떤 것을 사용할지 선택할 수 있습니다.

(1) Method를 사용한 기능 구현

예제를 통해 static과 instance method를 사용한 기능을 구현해 볼 것입니다. PersonAutoGen.cs의 Person class에서 private field를 가진 읽기 전용 property를 추가하여 결혼을 했는지, 했으면 누구랑 했는지를 나타내도록 합니다.

private bool married = false;
public bool Married => married;

private Person? spouse = null;
public Person? Spouse => spouse;

그리고 하나의 instance method와 static method를 Person class에 추가하여 2개의 Person개체로 결혼할 수 있는 기능을 부여합니다.

public static void Marry(Person p1, Person p2)
{
	p1.Marry(p2);
}

//instance method
public void Marry(Person partner)
{
	if (married) return;

	spouse = partner;
	married = true;

	partner.Marry(this);
}

위 예제에서는 다음 2가지 사항에 주목해야 합니다.

Marry static method에서 Person개체는 p1과 p2 매개변수로 Marry instance method로 전달됩니다.
Marry instance method에서는 매개변수로 전달된 partner로 spouse가 설정되며 married bool 변수가 true로 설정됩니다.

이번에는 2개의 Person개체가 아이를 낳을 수 있도록 하는 instance와 static method를 하나씩 추가합니다.

public static Person Procreate(Person p1, Person p2)
{
	if (p1.Spouse != p2)
	{
		throw new ArgumentException("일단 결혼부터...");
	}

	Person baby = new()
	{
		Name = $"Baby of {p1.Name} and {p2.Name}",
		DateOfBirth = DateTime.Now
	};

	p1.Children.Add(baby);
	p2.Children.Add(baby);

	return baby;
}

public Person ProcreateWith(Person partner)
{
	return Procreate(this, partner);
}

위 예제에서는 아래 사항에 주목합니다.

Procreate static method에서 아이를 낳을 Person 개체는 매개변수 p1과 p2로 전달됩니다.
baby라는 새로운 Person class는 부모가 될 둘의 Person에 대한 이름의 결합으로 만들어지게 됩니다. 그러나 이렇게 설정된 이후에 반환된 baby 변수의 Name속성을 설정하게 됨으로써 해당 값은 바뀔 수 있습니다.
baby개체는 둘 부모의 Children collection으로 추가되고 반환됩니다. Class는 참조 type이므로 이때는 baby 개체의 복사본이 아닌 memory에 저장된 baby 개체의 참조가 추가됩니다. 참조 type과 값 type에 대한 자세한 차이점은 추후에 알아볼 것입니다.
ProcreateWith instance method에서 아이를 낳을 Person개체는 자신을 나타내며 Procreate static method로 전달된 this와 함께 partner이름의 매개변수로 전달하여 구현된 method를 재사용합니다. this는 class의 현재 instance를 참조하는 keyword입니다.

새로운 개체를 생성하거나 기존 개체를 수정하는 method는 개체에 대한 참조를 반환하도록 함으로써 method의 호출자가 결과에 접근할 수 있어야 합니다.

Program.cs에서는 3개의 Person개체를 생성하고 이들에 대한 결혼을 수행한 뒤 서로 아이들 낳을 수 있도록 합니다.

Person kim = new() { Name = "Kim" };
Person lee = new() { Name = "Lee" };
Person hong = new() { Name = "Hong" };

kim.Marry(lee);
Person.Marry(hong, kim);

Console.WriteLine($"{kim.Name} is married to {kim.Spouse?.Name ?? "nobody"}");
Console.WriteLine($"{lee.Name} is married to {lee.Spouse?.Name ?? "nobody"}");
Console.WriteLine($"{hong.Name} is married to {hong.Spouse?.Name ?? "nobody"}");

Person baby1 = kim.ProcreateWith(lee);
baby1.Name = "Baby1";
Console.WriteLine($"{baby1.Name} was born on {baby1.DateOfBirth}");

Person baby2 = Person.Procreate(hong, kim);
baby2.Name = "Baby2";
Console.WriteLine($"{kim.Name} has {kim.Children.Count} children.");
Console.WriteLine($"{lee.Name} has {lee.Children.Count} children.");
Console.WriteLine($"{hong.Name} has {hong.Children.Count} children.");

for (int i = 0; i < kim.Children.Count; i++)
{
	Console.WriteLine(format: "{0}'s child #{1} is named \"{2}\".", arg0: kim.Name, arg1: i, arg2: kim[i].Name);
}

예제의 마지막 부분에서는 문자열에 큰따옴표(")를 추가하기 위해 backslash문자를 사용했습니다. 예제를 실행하면 다음과 같은 결과를 나타낼 것입니다.

(2) 연산자를 사용한 기능 구현

System.String class에는 2개의 문자열 값을 연결하고 그 결과를 반환하는 Concat이라는 static method가 있습니다.

string s1 = "Hello ";
string s2 = "World!";
string s3 = string.Concat(s1, s2);
Console.WriteLine(s3);

Concat과 같은 method를 통해서도 가능하지만 아무래도 동일한 처리를 위해 가장 많이 사용되는 것은 +연산자일 것입니다.

string s3 = s1 + s2;

이를 통해 code에서 * 문자를 통해 2개의 Person 개체에 대한 출산을, 그리고 + 문자로는 혼인을 구현해 볼 것입니다.

앞서 상술한 동작을 위해서는 * 문자를 위한 static 연산자를 정의해야 합니다. 이 문법은 method와 비슷하지만 method의 이름대신 기호를 사용하기에 사실상 연산자가 method이며 이러한 방식으로 문법을 더욱 간소화하게 만들 수 있습니다.

PersonAutoGen.cs에서 + 기호를 위한 static 연산자를 아래와 같이 생성합니다.

public static bool operator +(Person p1, Person p2)
{
	Marry(p1, p2);

	return p1.Married && p2.Married;
}

연산자의 return type은 매개변수로 연산자에 전달된 type와 일치할 필요는 없으나 return type이 void가 될 수는 없습니다.

그리고 * 기호를 위한 static 연산자 또한 아래와 같이 생성합니다.

public static Person operator *(Person p1, Person p2)
{
	return Procreate(p1, p2);
}

method와 달리 연산자는 IntelliSense를 통해 type의 list에 나타나지 않습니다. 따라서 정의한 모든 연산자에 대한 method를 같이 만드는 것이 좋습니다. 왜냐하면 연산자를 사용할 수 있다는 것이 개발자에게는 분명하지 않을 수 있기 때문이며 연산자의 구현 부분에서는 method를 호출하여 작성한 code를 재사용합니다. method를 제공해야 하는 두 번째 이유는 연산자가 모든 언어의 compiler에서 지원하는 것이 아니기 때문입니다. 예를 들어 *와 같은 산술연산자가 비록 Visual Basic과 F#에서 지원되기는 하지만 다른 언어가 C#에서 지원되는 모든 연산자를 지원한다는 보장이 없습니다.

Program.cs에서는 hong과 kim의 혼인을 위해 호출한 static Marry method부분을 주석처리하고 Marry의 기능을 대체할 +연산자를 사용하여 if문에 넣고 code를 아래와 같이 바꿔줍니다.

if (kim + hong)
{
	Console.WriteLine($"{kim.Name} and {hong.Name} successfully got married.");
}

그리고 hong의 children을 순회하는 for문 위에서 아래와 같이 * 연산자를 사용해 kim과 그의 아내 lee와 hong사이에 두 명의 아이를 생성하는 구문을 추가합니다.

Person baby3 = kim * lee;
baby3.Name = "Baby3";
Person baby4 = hong * kim;
baby4.Name = "Baby4";

for (int i = 0; i < kim.Children.Count; i++)
{
	Console.WriteLine(format: "{0}'s child #{1} is named \"{2}\".", arg0: kim.Name, arg1: i, arg2: kim[i].Name);
}

예제를 실행하면 다음과 같은 결과를 확인할 수 있습니다.

(3) 지역함수를 사용한 기능 구현

C# 7.0에서 도입된 언어기능으로 지역함수를 정의하는 것이 있습니다.

지역함수는 지역변수와 동일한 method로서 지역함수가 정의된 method안에서만 접근 가능한 method입니다. 다른 언어에서는 때로 중첩된(nested) 또는 inner 함수라고도 합니다.

지역 함수는 method안이면 위, 아래, 중간 어디서든 정의될 수 있습니다.

예제를 통해 수열 계산을 구현하기 위한 지역함수를 사용할 것이며 이를 위해 PersonAutoGen.cs에서 스스로 결과를 계산하기 위해 내부에서 지역함수를 사용하는 Factorial 함수를 아래와 같이 정의합니다.

public static int Factorial(int number)
{
	if (number < 0)
	{
		throw new ArgumentException($"{nameof(number)} cannot be less than zero.");
	}

	return localFactorial(number);

	int localFactorial(int localNumber)
	{
		if (localNumber == 0) return 1;
		return localNumber * localFactorial(localNumber - 1);
	}
}

Program.cs에서는 Factorial함수를 호출하고 결과값을 console에 출력하는 구문을 예외처리와 함께 아래와 같이 추가합니다.

int number = 5;

try
{
	Console.WriteLine($"{number}! is {Person.Factorial(number)}"); 
}
catch (Exception ex)
{
	Console.WriteLine($"{ex.GetType()} says: {ex.Message} number was {number}.");
}

예제를 실행하면 다음과 같은 결과를 볼 수 있습니다.

number변수의 값을 -1로 변경하면 다음과 같은 예외를 확인할 수 있습니다.

8. 개체에 대한 pattern matching

아래 글을 통해 우리는 이미 기본적인 pattern matching을 사용해 본 바 있었습니다.

2024.01.17 - [.NET/C#] - [C# 12와 .NET 8] 3. 흐름제어, Type 변환, 예외 처리

[C# 12와 .NET 8] 3. 흐름제어, Type 변환, 예외 처리

이번에는 변수를 사용한 간단한 동작과 분기, pattern matching 수행, 구문 혹은 block의 반복과 여러 값을 저장하기 위한 array, 특정 type에서 다른 type으로의 변수나 표현식에 대한 변환, 예외 처리 그

lab.cliel.com

그리고 이제 pattern matching에 대한 좀 더 상세한 내용을 더 알아보고자 합니다.

(1) 비행 승객 정의하기

다음 예제를 통해서는 비행기에 탑승하는 다양한 유형의 승객을 표현하기 위한 class를 정의할 것이며 그들에 대한 표값을 결정하기 위해 pattern matching과 함께 switch 문을 사용할 것입니다.

NetLibraryStandard2 project에 FlightPatterns.cs이름의 file을 추가하고 다른 속성을 가진 3개의 승객유형을 아래와 같이 정의합니다.

namespace NetLibraryStandard2
{
	public class Passenger
	{
		public string? Name { get; set; }
	}

	public class BusinessClassPassenger : Passenger
	{
		public override string ToString()
		{
			return $"Business Class: {Name}";
		}
	}

	public class FirstClassPassenger : Passenger
	{
		public int AirMiles { get; set; }
		public override string ToString()
		{
			return $"First Class with {AirMiles:N0} air miles: {Name}";
		}
	}

	public class CoachClassPassenger : Passenger
	{
		public double CarryOnKG { get; set; }
		public override string ToString()
		{
			return $"Coach Class with {CarryOnKG:N2} KG carry on: {Name}";
		}
	}
}

ToString method에 대한 재정의 부분은 추후에 자세히 알아볼 것입니다.

Program.cs에서는 여러 유형과 속성에 대한 다섯 명의 승객을 포함하는 개체 배열을 정의하고 이들을 열거하면서 해당 승객에 대한 비용을 출력하는 구문을 아래와 같이 추가합니다.

Passenger[] passengers = {
	new FirstClassPassenger { AirMiles = 1_419, Name = "Suyoung" },
	new FirstClassPassenger { AirMiles = 16_562, Name = "Lyujung" },
	new BusinessClassPassenger { Name = "Junghee" },
	new CoachClassPassenger { CarryOnKG = 25.7, Name = "Dongsu" },
	new CoachClassPassenger { CarryOnKG = 0, Name = "Ayoung" },
};

foreach (Passenger passenger in passengers)
{
	decimal flightCost = passenger switch {
		FirstClassPassenger p when p.AirMiles > 35000 => 1500M,
		FirstClassPassenger p when p.AirMiles > 15000 => 1750M,
		FirstClassPassenger _ => 2000M,
		BusinessClassPassenger _ => 1000M,
		CoachClassPassenger p when p.CarryOnKG < 10.0 => 500M,
		CoachClassPassenger _ => 650M,
		_ => 800M
	};

	Console.WriteLine($"Flight costs {flightCost:C} for {passenger}");
}

위 예제에서는 아래 3가지 사항에 주목합니다.

개체에 대한 속성에 pattern match를 구현하기 위해 표현식에서 사용될 수 있는 p와 같은 지역변수 이름을 사용해야 합니다.
type에서만 pattern match를 구현하기 위해서는 지역변수를 사용하는 대신 _를 사용해 code를 단순화시킬 수 있습니다.
_ (under bar)는 또한 switch 표현식에서 기본 분기를 나타내기 위해 사용할 수 있습니다.

예제를 실행하면 다음과 같은 결과를 볼 수 있습니다.

(2) C# 9부터 적용된 향상된 pattern matching

위 예제에서는 C# 8에서 작동할 수 있는 code이며 C# 9부터는 좀 더 향상된 문법을 사용할 수 있습니다. type matching에서는 더 이상 _ (under bar) 문자를 사용할 필요가 없어졌습니다.

Program.cs에서 위 예제의 C# 8 문법을 주석처리하고 C# 9부터 사용되는 문법을 적용하여 first-class승객에 대한 중첩된 switch 표현식을 사용하도록 변경하고 >와 같은 조건부에 대한 새로운 지원을 추가합니다.

//FirstClassPassenger p when p.AirMiles > 35000 => 1500M,
//FirstClassPassenger p when p.AirMiles > 15000 => 1750M,
//FirstClassPassenger _ => 2000M,
FirstClassPassenger p => p.AirMiles switch
{
	> 35000 => 1500M,
	> 15000 => 1750M,
	_ => 2000M
},

예제를 실행하면 이전과 동일한 결과를 확인할 수 있습니다. 해당 예제와 같은 상황에서는 또한 중첩된 switch 표현식을 사용하고 싶지 않다면 속성 pattern을 관계형 pattern과 결합하여 사용할 수 있습니다.

FirstClassPassenger { AirMiles: > 35000 } => 1500,
FirstClassPassenger { AirMiles: > 15000 } => 1750M,
FirstClassPassenger => 2000M,

더 자세한 사항은 아래 공식문서를 통해 확인할 수 있습니다.

Pattern matching overview - C# guide - C# | Microsoft Learn

9. record 사용

Record라는 새로운 언어기능을 살펴보기 전에 C# 9부터 도입된 일부 관계된 기능을 먼저 알아보도록 하겠습니다.

(1) 초기화 전용(Init-only) 속성

우리는 여러 예제를 통해 개체에 대한 초기화 구문으로 개체의 instance를 생성해 왔고 초기 속성을 설정했습니다. 그런데 이들 속성은 instance이후에도 값이 바뀔 수 있습니다.

때로는 속성이 읽기 전용(read-only)과 같은 속성처럼 다뤄져야 하는 경우도 있으며 따라서 instance를 생성할 때 설정되고 이후에는 바뀔 수 없어야 하는 경우 새로운 init keyword를 사용해 이러한 고민을 해결할 수 있습니다.

NetLibraryStandard2 project에서 Records.cs이름의 새로운 file을 생성하고 2개의 불변(immutable) 속성을 가진 person class를 아래와 같이 생성합니다.

namespace NetLibraryStandard2
{
	public class ImmutablePerson
	{
		public string? FirstName { get; init; }
		public string? LastName { get; init; }
	}
}

그리고 Program.cs에서 위 ImmutablePerson에 대한 instance를 생성하고 속성 중 하나의 속성에 대한 값의 변경을 시도합니다.

ImmutablePerson hong = new()
{
	FirstName = "hong",
	LastName = "gildong"
};

hong.FirstName = "Geoff";

그러면 다음과 같은 error를 표시하게 될 것입니다.

FirstName을 개체 초기화에서 설정하지 않는다 하더라도 일단 초기화 이후에는 값을 설정할 수 없습니다. 만약 특정 속성에 대해 값이 값이 설정되도록 강제하려면 required keyword를 사용해야 합니다.

(2) Record의 이해

초기화 전용 속성은 C#에 일부 불변성을 제공하며 이러한 개념은 record를 통해서도 가져갈 수 있습니다. record는 class keyword대신 record keyword를 사용해 정의되며 개체 전체를 불변으로 만들 수 있고 비교동작시 값처럼 동작합니다. class와 record 그리고 값 type에 대한 자세한 사항은 추후에 다뤄볼 것입니다.

Record는 instance이후에 바뀔 수 있는 어떠한 속성이나 field로 가질 수 없습니다. 대신 이미 존재하는 것으로부터 새로운 record를 생성할 수는 있는데 이를 통해 바뀐 값으로의 instance를 얻을 수 있습니다. 이러한 방식을 non-destructive mutation이라고 하는데 C# 9부터 with keyword를 통해 도입하여 사용할 수 있습니다.

Records.cs에서 ImmutableVehicle이름의 record를 아래와 같이 추가합니다.

public record ImmutableVehicle
{
	public int Wheels { get; init; }
	public string? Color { get; init; }
	public string? Brand { get; init; }
}

Program.cs에서는 필요한 값을 통해 ImmutableVehicle에 대한 instance를 아래와 같이 생성할 수 있습니다. 해당 car instance는 이후 불변으로 속성은 값을 바꿀 수 없습니다.

ImmutableVehicle car = new()
{
	Brand = "Spark",
	Color = "Black",
	Wheels = 4
};

상술하였듯 with keyword를 사용해 기존 instance에 대한 값이 바뀐 복사본을 생성하고 각각의 속성값을 확인하도록 합니다.

ImmutableVehicle repaintedCar = car with { Color = "White" };

Console.WriteLine($"Original car color was {car.Color}.");
Console.WriteLine($"New car color is {repaintedCar.Color}.");

예제를 실행하면 아래와 같은 결과를 표시할 것입니다. 복사본에서 car의 color가 변경되었음에 주목하시기 바랍니다.

(3) Record 비교

Record 사용으로 인해 확인가능한 가장 중요한 변화중 하나는 Record를 서로 비교하는 경우 확인할 수 있습니다. 같은 속성과 값을 가진 2개의 Record는 같은 것으로 취급됩니다. 별것 아닌 것 같이 들릴 수도 있겠지만 class를 사용하는 경우는 같은 값을 가지고 있다 하더라도 기본적으로 참조 memory주소값을 비교하기 때문에 다른 것으로 취급됩니다.

public class AnimalClass
{
  public string Name { get; set; }
  public string Species { get; set; }
}

public record AnimalRecord
{
  public string Name { get; set; }
  public string Species { get; set; }
}

예제는 같은 형식으로 class와 record type을 각각 정의하고 있습니다. 이들에 대한 비교를 수행하기 위해 각각의 instance를 생성하고 아래와 같이 비교합니다.

AnimalClass ac1 = new() { Name = "nyao", Species = "Cat" };
AnimalClass ac2 = new() { Name = "nyao", Species = "Cat" };
Console.WriteLine($"ac1 == ac2: {ac1 == ac2}");

AnimalRecord ar1 = new() { Name = "Mong", Species = "Dog" };
AnimalRecord ar2 = new() { Name = "Mong", Species = "Dog" };
Console.WriteLine($"ar1 == ar2: {ar1 == ar2}");

예제를 실행하면 다음과 같은 결과를 확인할 수 있습니다.

첫 번째(class)는 같은 속성과 값을 가지고 있음에도 불구하고 같지 않다고 표시하고 있지만 두 번째(record)는 정확히 동일함으로 표시하고 있습니다.

(4) Record에서의 positional data member

Record를 정의하는 문법은 positional data member의 사용으로 훨씬 간소화될 수 있습니다.

● Record에서 data member 간소화

중괄호를 통한 개체초기화문을 사용하는 대신 위에서 이미 해본 것처럼 positional 매개변수를 생성자에서 제공할 수 있고 또한 개체를 개별적으로 분해하기 위한 형식분해를 같이 결합할 수도 있습니다.

public record ImmutableAnimal
{
	public string Name { get; init; }
	public string Species { get; init; }
	public ImmutableAnimal(string name, string species)
	{
		Name = name;
		Species = species;
	}
	public void Deconstruct(out string name, out string species)
	{
		name = Name;
		species = Species;
	}
}

다만 위와 같은 속성과 생성자, 형식분해는 자동으로 생성될 수 있습니다.

Record.cs에서 위 예제를 아래와 같이 positional record로 알려진 간소화문을 사용하여 record를 재작성해 정의합니다.

public record ImmutableAnimal(string Name, string Species);

다수의 line에 걸쳐 작성했던 record문을 위의 한 줄로 줄였습니다. Program.cs에서는 ImmutableAnimal에 대한 생성자와 형식분해문을 아래와 같이 사용합니다.

ImmutableAnimal oscar = new("Milan", "Labrador");

var (who, what) = oscar;
Console.WriteLine($"{who} is a {what}.");

예제를 실행하면 다음과 같은 결과를 확인할 수 있습니다.

(5) 가변성과 record

Record를 생각할때 초기화이후에 instance 속성과 값형 field의 값이 바뀔 수 없는 불변성(immutable)부터 떠올리기 쉽지만 이는 사실 record가 어떻게 정의되었는가에 따라 달라질 수 있습니다.

예를 들어 아래와 같이 Record가 사용되었을 경우

public record class C1
{
    public string? Name { get; set; }
}

public record class C2(string? Name);

public record struct S1
{
    public string? Name { get; set; }
}

public record struct S2(string? Name);

public readonly record struct S3(string? Name);

다음과 같이 각 type에 대한 instance를 생성하고 Name에 대한 초기값을 설정한 뒤 다시 Name에 대한 속성값을 변경합니다.

C1 c1 = new() { Name = "Hong" };
c1.Name = "Kim";
C2 c2 = new(Name: "Hong");
c2.Name = "Kim";

S1 s1 = new() { Name = "Hong" };
s1.Name = "Kim";
S2 s2 = new(Name: "Hong");
s2.Name = "Kim";
S3 s3 = new(Name: "Hong");
s3.Name = "Kim";

그런뒤 build를 시도하면 compiler error CS8852를 통해 이들 중 2개의 type이 초기화 이후에 불변성이 됨을 알 수 있습니다.

C1은 가변성이지만 C2는 불변이 되며 S1과 S2는 가변이지만 C3는 불변입니다. Microsoft는 record와 관련하여 몇가지 흥미로운 design을 적용하였습니다. 때문에 record, class, struct를 섞어서 사용할고 각각의 선언에서 다른 type을 사용할때 이들 동작에 대한 차이를 기억하고 있어야 합니다.

[C# 12와 .NET 8] 4. Debuging과 Testing

클리엘 — Mon, 22 Jan 2024 11:11:58 +0900

code의 재사용을 위한 함수의 작성과 개발동안의 logic error에 대한 debugging, runtime에서의 logging, code의 bug제거와 신뢰성 및 안정성을 높이기 위한 unit test 등은 개발과정에서 매우 중요한 요소로 취급되고 있습니다.

1. 함수 작성

programming에서의 기본적인 원칙은 흔히 DRY불리는 '반복하지 마라'입니다.

programming동안에 같은 구문을 작성하고 또 그것을 반복하고 있다면 이들 구문을 함수로 전환할 필요가 있습니다. 함수는 application전체에서 하나의 작은 작업의 단위를 처리하는 부분으로서 예로 부가세 계산 logic과 같은 것들을 들 수 있으며 이러한 함수는 회계 application의 여러 곳에서 재사용될 수 있습니다.

program에서 함수는 일반적으로 입력과 출력을 가지며 대게 한쪽 끝에서 원재료를 투입하고 다른 쪽에서 제조된 item이 나오는 black box로도 표현됩니다. 일단 생성된 것을 철저하게 debuging하고 test 한다면 향후에 해당 application을 유지관리하는데 상당한 도움이 될 것입니다.

함수는 OOP세계에서 class에 소속될 수 있는데 이때는 이를 Method라고 합니다. C#에서 함수는 Method와 같은 의미로 해석될 수 있습니다.

(1) top-level program과 function

.NET 6부터 console app의 기본 project template에서는 C# 9에서 도입된 top-level program을 사용하고 있습니다.

함수를 작성하면 자동적으로 생성된 Program class와 <Main>$ method에서 이들이 어떻게 작동하는지를 이해하는 것이 중요합니다.

아래 예제에서는 Program.cs에서 class를 import하고 해당 class의 method를 호출하고 있으며 또한 함수 하나를 정의하고 해당 함수를 호출하고 있습니다.

using static System.Console;

WriteLine("Hello, World!");

DoSomething();

void DoSomething()
{
	WriteLine("Doing something!");
}

compiler는 자동적으로 <Main>$ 함수와 함께 Program class를 생성하며 위 예제와 같이 입력된 구문과 함수를 <Main>$ method안으로 이동시킨 뒤 함수의 이름을 아래와 같이 바꾸게 됩니다.

using static System.Console;
partial class Program
{
	static void <Main>$(String[] args)
	{
		WriteLine("Hello, World!");
		<<Main>$>g__DoSomething|0_0();
		
		void <<Main>$>g__DoSomething|0_0()
		{
			WriteLine("Doing something!");
		}
	}
}

위와 같이 compiler가 어떤구문이 어디에 필요한지를 파악할 수 있도록 하기 위해서는 다음과 같이 규칙을 따라야 합니다.

Import문(using)은 Program.cs file의 상단에 위치해야 합니다.
<Main>$ function안으로 옮겨져야할 구문은 Program.cs file의 중간에 와야 합니다.
함수는 Program.cs file의 하단에 위치해야 하며 이들은 지역 함수가 됩니다.

특히 지역함수의 경우 일부 제한을 가질 수 있으므로 위 마지막 규칙은 기억하고 있어야 합니다.

예제에서 사용된 static이나 partial과 같은 keyword는 추후에 OOP를 다루는 과정에서 자세하게 살펴볼 것입니다.

함수를 정의하기 위한 보다 나은 방법은 분리된 file에서 함수를 정의하고 함수를 Program class에 정적(static) member로서 추가하는 것입니다.

//Function.cs와 같은 별도의 file에서 작성
partial class Program
{
	static void DoSomething()
	{
		Console.WriteLine("Doing something!");
	}
}

//Program.cs에서 작성
using static System.Console;
WriteLine("Hello, World!");
DoSomething();

compiler가 Program class를 <Main>$ 함수와 함께 정의할 때 위 구문을 <Main>$ method안으로 옮기게 되고 Program class의 member로서 상기 함수를 병합하여 아래와 같은 결과물을 만들게 됩니다.

using static System.Console;
partial class Program
{
	static void <Main>$(String[] args)
	{
		WriteLine("Hello, World!");
		DoSomething();
	}

	static void DoSomething() // define a function
	{
		WriteLine("Doing something!");
	}
}

Program.cs에서 호출될 모든 함수는 별도의 분리된 file에서 생성하고 partial Program class안에서 이들을 호출하는 방법으로 사용하면 자동적으로 생성된 Program class의 <Main>$ method안에 지역함수로 들어가는 대신 <Main>$ method와 동일한 수준으로 병합될 것입니다.

(2) 구구단

구구단을 공부하기 위해 구구단표를 만들어야 한다고 가정해 보면, 예를 들어 7단의 경우 아래와 같은 구구단을 생성할 수 있습니다.

7 × 1 = 7
7 × 2 = 14
7 × 3 = 21
...
7 × 9 = 63

구구단을 공부하는 수준에 따라서 10이나 12, 심지어 20까지의 곱셈이 들어간 표를 생성할 수도 있을 것입니다. 이전에 우리는 for문에 대해서 배웠고 일반적인 pattern에서 반복작업을 수행하는 데 사용할 수 있음을 알고 있습니다. 이를 통해 7단을 9 곱셈까지 표현하려면 다음과 같이 구현할 수 있습니다.

for (int row = 1; row <= 9; row++)
{
	Console.WriteLine($"{row} x 7 = {row * 7}");
}

하지만 위에서 처럼 항상 7단에 9곱셈까지 한정하여 표시하는 대신 이를 모든 숫자에 대한 원하는 만큼의 곱셈으로 표현하는 유연성을 가지기 위해서는 함수를 사용해야 합니다.

● 구구단 함수 만들기

이를 위해 만들어볼 함수는 임의의 숫자에 대한 구구단을 표시하며 임의의 숫자까지(기본값 9)의 곱셈을 표시하도록 할 것입니다.

예제를 위해 csStudy04 solution을 생성하고 WritingFunctions project를 추가합니다. 해당 project에서는 Function.cs file을 추가한 뒤 아래와 같이 partial Program class에 TimesTable이름의 함수를 정의합니다.

partial class Program
{
	static void TimesTable(byte number, byte size = 9)
	{
		Console.WriteLine($"This is the {number} times table with {size} rows:");

		for (int row = 1; row <= size; row++)
		{
			Console.WriteLine($"{number} x {row} = {number * row}");
		}

		Console.WriteLine();
	}
}

해당 예제는 다음의 특징을 가집니다.

TimesTable은 number이름의 매개변수로 전달된 byte값을 가져야 합니다.
TimesTable은 선택적으로 size라는 이름의 매개변수로 전달된 byte값을 가져야 합니다. 값이 전달되지 않으면 기본은 12가 됩니다.
TimesTable은 static method인 <Main>$에서 호출되어야 하므로 static method입니다.
TimesTable은 호출자에게 값을 반환하지 않으므로 함수의 이름앞에 void keyword를 사용하여 선언될 수 있습니다.
TimesTable은 전달된 수의 구구단을 출력하기 위해 number와 size를 사용하는 for문을 사용합니다.

Program.cs에서는 기존의 구문을 모두 삭제하고 number 매개변수의 byte값을 전달하여 위 함수를 호출하도록 합니다.

TimesTable(7);

project를 실행하면 다음의 결과를 표시합니다.

이번에는 7단에 20까지의 곱셈을 표시하도록 다음과 같이 함수를 호출합니다.

TimesTable(7, 20);

결과는 다음과 같습니다.

함수가 하나 또는 그 이상의 매개변수를 가지고 있을때 값을 전달하는 것만으로 충분한 의미를 제공하지 못한다면 해당 값과 함께 선택적으로 매개변수의 이름을 다음과 같이 지정할 수 있습니다.
TimesTable(number: 7, size: 20);

위와 같이 TimesTable함수를 호출할때는 0부터 255까지의 byte값을 전달해야 합니다. 매개변수가 byte형식이기 때문인데 따라서 int나, double, string과 같은 형식의 값을 전달하면 다음과 같이 error를 유발하게 됩니다.

(3) 인수와 매개변수

대부분의 개발자가 일상적으로 사용하는 단어로 인수와 매개변수라는 말이 있는데 개발자들 중에서도 이 2개의 용어를 혼동하는 경우가 많습니다. 엄밀히 말하면 이 2개의 용어는 전혀 다르지만 종종 같은 뜻으로 사용되는 경우가 있는 것입니다.

매개변수(parameter)는 함수안에서 정의되는 변수입니다. 예를 들어 Hire 함수 안에서 startDate는 매개변수입니다.

void Hire(DateTime startDate)
{
	// implementation
}

method가 호출될때 method의 매개변수로 전달한 data를 인수(argument)라고 합니다. 예를 들어 Hire 함수로 전달한 when이 인수가 됩니다.

DateTime when = new(year: 2022, month: 11, day: 8);
Hire(when);

인수를 전달할때 매개변수의 이름을 지정하고자 한다면 아래와 같이 할 수 있습니다.

DateTime when = new(year: 2022, month: 11, day: 8);
Hire(startDate: when);

결론적으로 Hire 함수를 호출한다고 했을 때 startDate는 매개변수, when은 인수가 됩니다.

Microsoft 공식 문서에서도 'named and optional arguments'와 'named and optional parameters'를 같은 의미로 사용하고 있습니다.

Named and Optional Arguments - C# Programming Guide | Microsoft Learn

Named and Optional Arguments - C# Programming Guide

Named arguments in C# specify arguments by name, not position. Optional arguments can be omitted.

learn.microsoft.com

이것은 하나의 단일 개체가 context에 따라 매개변수와 인수 둘 다 될 수 있기 때문에 약간 난해할 수 있습니다. 예를 들어 Hire 함수 안에서 startDate 매개변수는 SaveToDatabase처럼 다른 함수로 인수로서 전달될 수 있습니다.

void Hire(DateTime startDate)
{
	//Something Do
	SaveToDatabase(startDate, employeeRecord);
}

programming에서 가장 어려운것중 하나는 이름을 짓는 것입니다. 아래 예제는 C#에서 가장 중요한 Main 함수로서 'arguments'의 단축형인 args이름의 매개변수를 정의하고 있습니다.

static void Main(String[] args)
{

}

요약하자면 매개변수는 함수로의 입력을 정의하며 인수는 함수가 호출될때 함수로 전달되는 것입니다.

(4) 값을 반환하는 함수

위 함수는 looping과 console로의 출력을 수행하는 함수이지만 어떠한 값도 반환하지 않습니다. 하지만 모든 함수를 그렇게 만들 수는 없는데 예를 들어 매출이나 부가세 계산이 필요하다고 했을 때 Europe에서 부가가치세(VAT) 율은 Switzerland의 8%에서 Hungary의 27% 범위가 될 수 있고 미국에서는 Oregon 0%에서 California의 8.25% 범위까지 될 수 있습니다.

세율은 언제나 바뀔 수 있고 많은 요인에 따라 달라집니다. 예제에서 사용된 값은 정확한 값이 아닙니다.

아래 예제는 세계의 다양한 지역에서 세율을 계산하는 함수로서 Functions.cs에서 CalculateTax라는 이름의 함수를 추가합니다.

static decimal CalculateTax(decimal amount, string twoLetterRegionCode)
{
	decimal rate = 0.0M;

	switch (twoLetterRegionCode)
	{
		case "CH": // Switzerland
			rate = 0.08M;
			break;
		case "DK": // Denmark
		case "NO": // Norway
			rate = 0.25M;
			break;
		case "GB": // United Kingdom
		case "FR": // France
			rate = 0.2M;
			break;
		case "HU": // Hungary
			rate = 0.27M;
			break;
		case "OR": // Oregon
		case "AK": // Alaska
		case "MT": // Montana
			rate = 0.0M;
			break;
		case "ND": // North Dakota
		case "WI": // Wisconsin
		case "ME": // Maine
		case "VA": // Virginia
			rate = 0.05M;
			break;
		case "CA": // California
			rate = 0.0825M;
			break;
		default: // most US states
			rate = 0.06M;
			break;
	}

	return amount * rate;
}

위 예제에서는 다음 사항에 주목해야 합니다.

CalculateTax는 2개의 입력을 받고 있으며 amount라는 이름의 매개변수는 지출금액이 되고 twoLetterRegionCode이름의 매개변수는 지출이 이루어진 지역이 됩니다.
CalculateTax는 switch구문을 사용해 계산을 수행하며 10진수로서 지불해야할 sales tax나 VAT를 반환합니다. 따라서 함수이름 이전에 반환값의 data type으로 decimal형식의 값을 받을 수 있도록 해야 합니다.

Program.cs에서는 위에서 만든 CalculateTax함수를 호출하도록 하는데 이때 149와 같은 금액값과 FR 같은 정확한 지역 code를 전달해야 합니다.

decimal taxToPay = CalculateTax(amount: 149, twoLetterRegionCode: "FR");
Console.WriteLine($"You must pay {taxToPay} in tax.");

예제를 실행하면 다음과 같은 결과를 표시하게 됩니다.

위 예제에서 taxToPay는 '{taxToPay:C}'와 같은 방법으로 지역문화권을 통해 통화표시로 서식화할 수 있습니다. 예를 들어 대한민국의 경우 ￦28.9와 같이 표시됩니다.

● 숫자를 기수에서 서수로 변환하기

셈을 위해 사용되는 숫자를 기수라고 하며 1, 2, 3등을 예로 들 수 있습니다. 반면 서수는 순서에 사용되며 첫번째(1st), 두 번째(2nd), 세 번째(3rd)와 같은 것들을 말합니다. 아래 예제는 기수를 서수로 변환하는 함수로서 Function.cs에 CardinalToOrdinal이름으로 정의하였습니다. 이 함수는 기수의 int값을 서수의 문자열값으로 변환하므로 1은 1st, 2는 2nd, 3은 3rd등으로 변환됩니다.

static string CardinalToOrdinal(int number)
{
	int lastTwoDigits = number % 100;

	switch (lastTwoDigits)
	{
		case 11:
		case 12:
		case 13:
			return $"{number:N0}th";
		default:
			int lastDigit = number % 10;
			string suffix = lastDigit switch
			{
				1 => "st",
				2 => "nd",
				3 => "rd",
				_ => "th"
			};
			return $"{number:N0}{suffix}";
	}
}

위의 함수에서는 아래 사항에 주목합니다.

CardinalToOrdinal은 number라는 이름의 int type매개변수로 하나의 입력을 받으며 string type의 값을 반환합니다.
switch문은 11, 12, 13의 특정 case를 처리하기 위해 사용되었습니다.
switch표현식은 그외 다른 모든 case를 처리하는 데 사용되며 마지막 숫자가 1이면 st를, 2면 nd를, 3이면 rd접미사를 사용하고 그 외 다른 숫자라면 th접미사를 사용하도록 합니다.

이번에는 Function.cs에서 RunCardinalToOrdinal이름의 함수를 작성합니다. 해당 함수는 1~150까지 loop를 순회하면서 각 숫자에 대해 CardinalToOrdinal함수를 호출하고 console에 반환된 문자열을 출력합니다. 이때 공백문자를 통해 각 출력을 구분하고 있습니다.

static void RunCardinalToOrdinal()
{
	for (int number = 1; number <= 150; number++)
	{
		Console.Write($"{CardinalToOrdinal(number)} ");
	}

	Console.WriteLine();
}

Program.cs에서는 기존의 구문을 모두 주석처리하고 RunCardinalToOrdinal method를 아래와 같이 호출합니다.

RunCardinalToOrdinal();

예제를 실행하면 다음과 같은 결과를 표시할 것입니다.

(5) 재귀호출을 통한 계승 계산

계승은 시작되는 숫자에서 부터 1 작은 수를 곱하고 다시 그 숫자에 1 작은 수를 곱하여 시작수가 1이 될 때까지 계산합니다. 따라서 5의 계승은 5 Χ 4 Χ 3 Χ 1이 되므로 120입니다.

계승 함수는 음수가 아닌 아래와 같이 1, 2, 3, 4와 같은 정수를 위해서만 정의됩니다.

0! = 1
n! = n × (n − 1)!, for n ∈ { 1, 2, 3, ... }

계승은 '5!'와 같이 쓰며 여기서 느낌표를 계승이라고 표현하므로 '5! = 120은 5의 계승은 120이다.'라고 할 수 있습니다.

다음 예제는 Factorial함수로서 매개변수로 전달된 int값에 대한 계승을 계산할 것입니다. 여기서는 '재귀'라고 하는 방법을 사용했는데 이는 직접적이든 간접적이든 구현된 범위 안에서 자신을 호출하는 함수를 의미합니다.

static int Factorial(int number)
{
	if (number < 0)
		throw new ArgumentException(message: "factorial 함수는 정수만 사용할 수 있습니다. { number }", paramName: nameof(number));
	else if (number == 0)
		return 1;
	else
		return number * Factorial(number - 1);
}

전과 마찬가지로 위의 예제에서도 몇몇 주목할만한 부분이 존재합니다.

매개변수 number가 음수가 된다면 Factorial은 예외를 발생시킵니다.
매개변수 number가 0이라면 1을 반환합니다.
매개변수 number가 그외 다른 case가 되는 1보다 크다면 Factorial은 number보다 1적은 수를 전달하여 스스로를 호출함으로써 number에 대한 곱셈을 수행합니다.(재귀함수)

재귀는 어떤면에서 현명한 방법이 될 수 있지만 잘못하면 너무 많은 함수를 호출하면 함수가 호출될 때마다 memory를 사용하게 되어 결국에는 overflow를 일으킬 수 있는 등의 문제를 발생시킬 수 있습니다. 반복은 간결함이 떨어질 수 있지만 C#과 같은 언어에서 더 실용적인 해결책이 될 수 있습니다. 이와 관련하여 아래 link를 참고하시기 바랍니다.

Recursion (computer science) - Wikipedia

From Wikipedia, the free encyclopedia Use of functions that call themselves Tree created using the Logo programming language and relying heavily on recursion. Each branch can be seen as a smaller version of a tree. In computer science, recursion is a metho

en.wikipedia.org

Functions.cs에서 아래와 같이 RunFactorial이름의 함수를 추가합니다. 이 함수는 1부터 15까지의 숫자에 대한 factorial을 표시하기 위해 for문을 사용하며 N0 code를 사용해 소수점 0자리와 함께 , 로 천 단위 숫자를 분리하는 서식화를 적용하고 있습니다.

static void RunFactorial()
{
	for (int i = 1; i <= 15; i++)
	{
		Console.WriteLine($"{i}! = {Factorial(i):N0}");
	}
}

RunCardinalToOrdinal method의 호출부분을 주석처리하고 RunFactorial method를 호출하도록 한 뒤 예제를 실행하면 다음과 같은 결과를 표시하게 됩니다.

위의 결과를 통해서는 분명해 보이지 않을 수 있지만 13이상의 계승은 너무 큰 숫자로 int type을 overflow 합니다. 12! 는 479,001,600인데 이는 5억 가까이 됩니다. int변수로 저장가능한 최대 양수값은 20만입니다. 13! 은 6,227,020,800이므로 60억이며 이는 32bit integer로 저장될 때 어떠한 오류도 표시하지 않고 overflow로 처리됩니다.

물론 overflow가 발생하지 않도록 13!이상에서 32bit int대신 64bit long을 사용할 수 있지만 그런 조치를 함에도 불구하고 빠르게 overflow의 한계에 다시 도달하게 될 것입니다.

여기서 핵심은 숫자가 overflow될 수 있다는 것을 이해하고 직접 확인하는 것입니다. 12 이상의 factorial을 어떻게 계산할지를 공부하고자 하는 것이 아닙니다. 아래와 같이 Factorial함수를 수정하여 overflow를 확인할 수 있도록 합니다.

static int Factorial(int number)
{
	if (number < 0)
		throw new ArgumentException(message: $"factorial 함수는 정수만 사용할 수 있습니다. { number }", paramName: nameof(number));
	else if (number == 0)
		return 1;
	else
	{
		checked // overflow check
		{
			return number * Factorial(number - 1);
		}
	}
}

RunFactorial 함수도 for에서 시작되는 수를 -2로 변경하여 overflow와 Factorial method를 호출할 때의 예외를 처리될 수 있도록 합니다.

static void RunFactorial()
{
	for (int i = -2; i <= 15; i++)
	{
		try
		{
			Console.WriteLine($"{i}! = {Factorial(i):N0}");
		}
		catch (OverflowException)
		{
			Console.WriteLine($"{i}! 32bit integer에서는 처리할 수 없는 수입니다.");
		}
		catch (Exception ex)
		{
			Console.WriteLine($"{i}! throws {ex.GetType()}: {ex.Message}");
		}
	}
}

예제를 실행하면 결과는 다음과 같을 것입니다.

(6) XML주석을 통해 함수 설명하기

CardinalToOrdinal과 같은 함수를 호출할때는 보통 code editor는 기본적인 정보를 표시하는 tooltip을 보여주게 됩니다.

위와 같은 상황에서 사용자에게 보여질 정보는 XML주석을 통해 추가될 수 있습니다. CardinalToOrdinal함수 위에서 slashe문자 3개를 연속으로 입력합니다. 그러면 해당 함수가 number라는 하나의 매개변수를 갖는다고 인식하고 거기에 맞는 XML주석의 틀이 아래와 같이 표시될 것입니다.

/// <summary>
/// 
/// </summary>
/// <param name="number"></param>
/// <returns></returns>

해당 주석틀 안에 CardinalToOrdinal함수에 관한 적절한 정보를 입력하면 되는데 summary는 함수에 대한 대략적인 설명을, param에는 해당 매개변수에 대한 설명을, returns에는 반환값에 대한 설명을 입력하면 됩니다.

/// <summary>
/// 32-bit integer값을 전달하면 이에 맞는 서수로 변환하여 그 결과를 반환합니다.
/// </summary>
/// <param name="number">1, 2, 3과 같은 정수값을 입력합니다.</param>
/// <returns>1st, 2nd, 3rd와 같은 서수로 변환된 값입니다.</returns>

위와 같이 설명을 작성한 후 다시 함수의 호출 부분에서 mouse를 대면 다음과 같이 입력한 정보를 표시하게 됩니다.

이 기능은 Sandcastle처럼 주석을 문서로 변환하는 도구와 함께 사용되도록 설계된 것으로 아래 link를 통해 Sandcasle에 대한 좀 더 자세한 정보를 확인할 수 있습니다.

GitHub - EWSoftware/SHFB: Sandcastle Help File Builder (SHFB).

GitHub - EWSoftware/SHFB: Sandcastle Help File Builder (SHFB). A standalone GUI, Visual Studio integration package, and MSBuild

Sandcastle Help File Builder (SHFB). A standalone GUI, Visual Studio integration package, and MSBuild tasks providing full configuration and extensibility for building help files with the Sandcast...

github.com

code를 입력하거나 함수이름에 mouse를 올려둘때 나타나는 tooltip은 보조적 기능에 해당합니다.

지역함수의 경우 이들이 선언된 외부에서는 사용될 수 없기 때문에 XML 주석을 지원하지 않습니다. 따라서 이들에 대한 문서화를 생성하는 것은 의미가 없으며 Visual Studio 2022나 Visual Studio Code도 인식하지 못하므로 tooltip조차 사용되지 않습니다.

지역 함수를 제외하고 code상의 모든 함수에 XML주석을 추가하기를 권장합니다.

(7) 함수에서 lambda사용하기

F#은 Microsoft의 강력한 Type의 함수형 programming언어로서 C#과 같이 .NET하에서 실행되기 위해 IL로 compile 됩니다. 이러한 함수형 언어는 계산 system이 함수에 기반한 lambda계산에서 진화한 것인데 code는 일반적인 절차형 언어의 그것보다는 수학적 함수에 가깝습니다.

함수형 언어에서 주목해야할 중요한 특징으로는 다음과 같은 것들이 있습니다.

단위화(Modularty) : C#에서 함수를 정의할 때와 동일한 이점이 함수형 언어에도 적용됩니다. 이를 통해 크고 복잡한 code는 더 작은 조각으로 나누어질 수 있습니다.
불변성(Immutability) : 함수안에서 모든 변수는 바뀔 수 없습니다. 대신 기존에 존재하는 것으로부터 새로운 data값이 생성될 수 있습니다. 이러한 방식은 bug를 줄이는데도 도움이 됩니다.
관리성(Maintainability) : Code는 깔끔하고 명확합니다.(수학적 성향을 가진 개발자들을 위해!)

C# 6 이후 Microsoft는 더욱 함수적인 접근법을 지원하기 위해 언어에 기능추가를 시도해 왔습니다. 예를 들어 C# 7에서의 tuple과 pattern matching, C# 8에서의 non-null 참조 type, 그리고 C# 9에서 pattern matching의 향상과 record 즉, 불변개체등을 들 수 있습니다.

C# 6에서 Microsoft는 식본문함수member(expression-bodied function member)의 지원을 추가했으며 이전의 예제에서도 이를 활용한 바 있습니다. C#에서 lambda는 함수로부터 반환값을 표현하기 위해 => 문자를 사용합니다.

숫자의 Fibonacci 수열은 항상 0과 1로 시작합니다. 그러면 수열의 나머지는 이전 2개의 숫자를 같이 더하는 규칙을 통해 아래와 같이 생성됩니다.

0 1 1 2 3 5 8 13 21 34 55...

따라서 수열의 다음 순서는 34 + 55이므로 89가 됩니다.

위와 같은 Fibonacci수열로 명령적 함수와 선언적 함수를 구현하는것의 차이를 설명할 수 있습니다.

Function.cs에서 명령적 함수 형태로 FibImperative이름의 함수를 아래와 같이 추가합니다.

static int FibImperative(int term)
{
	if (term == 1)
	{
		return 0;
	}
	else if (term == 2)
	{
		return 1;
	}
	else
	{
		return FibImperative(term - 1) + FibImperative(term - 2);
	}
}

이어서 RunFibImperative이름의 함수를 추가합니다. 이 함수는 1부터 30까지 순회하는 for문안에서 FibImperative 함수를 호출합니다.

static void RunFibImperative()
{
	for (int i = 1; i <= 30; i++)
	{
		Console.WriteLine("The {0} term of the Fibonacci sequence is {1:N0}.", arg0: CardinalToOrdinal(i), arg1: FibImperative(term: i));
	}

}

Progam.cs에서는 기존의 구문을 모두 제거하고 RunFibImperative만을 호출하도록 합니다. 그리고 project를 실행하면 다음과 같은 결과를 확인할 수 있습니다.

다시 Function.cs로 돌아와 FibFunctional 함수를 추가합니다. 해당 함수는 선언적 형태로 작성되었습니다.

static int FibFunctional(int term) => term switch
{
	1 => 0,
	2 => 1,
	_ => FibFunctional(term - 1) + FibFunctional(term - 2)
};

그리고 1부터 30까지 순회하는 for문 안에서 위의 함수를 호출하는 RunFibFunctional 함수를 아래와 같이 추가합니다.

static void RunFibFunctional()
{
	for (int i = 1; i <= 30; i++)
	{
		Console.WriteLine("The {0} term of the Fibonacci sequence is {1:N0}.", arg0: CardinalToOrdinal(i), arg1: FibFunctional(term: i));
	}
}

그리고 역시 Progam.cs안에서 RunFibImperative 함수를 호출하도록 하고 예제를 실행하면 이전과 동일한 결과가 됨을 알 수 있습니다.

2. Debugging

개발과정에서는 문제점을 해결하기 위해 debugging이라는 과정을 거쳐야 하며 실제 그렇게 하기 위한 방법에 대해 알아보고자 합니다. 이를 위해 개발자는 Visual Studio 2022나 Visual Studio Code와 같은 debugging 도구를 가진 code editor를 사용할 수 있습니다.

어떤 경우는 Visual Studio Code에서 OmniSharp debugger를 설정하는 것이 어렵다고 느껴질 수 있는데 이에 대한 정보는 아래 link를 참고할 수 있습니다.

omnisharp-vscode/debugger.md at master · OmniSharp/omnisharp-vscode · GitHub

GitHub - OmniSharp/omnisharp-vscode: Official C# support for Visual Studio Code (powered by OmniSharp)

Official C# support for Visual Studio Code (powered by OmniSharp) - GitHub - OmniSharp/omnisharp-vscode: Official C# support for Visual Studio Code (powered by OmniSharp)

github.com

(1) debugging에서 Visual Studio Code에 통합된 Terminal 사용하기

기본적으로 OmmiSharp은 debugging동안에 내부 console을 사용하도록 console을 설정하는데 여기서 한가지 문제점은 ReadLine method를 통한 text입력과 같은 상호작용을 지원하지 않는다는 것입니다. 따라서 console대신 통합 termianl을 대신 사용할 수 있도록 설정을 변경할 것입니다.

breakpoint를 걸고 단계적으로 code를 진행함으로서 debugging 하고자 하는 project의 folder로 들어간 뒤 .vscode folder로 들어가면 launch.json file을 볼 수 있습니다. 해당 file을 열어 console의 설정을 'internalConsole'에서 'integratedTerminal'로 변경합니다.

{
    "version": "0.3.2",
    "configurations": [
    {
        "console": "integratedTerminal",
    ]
}

(2) 고의적인 bug로 code 생성하기

예제로서 실제 code editor의 debugger도구를 사용해 bug를 찾고 수정해볼 텐데 이를 위해 해당 bug 가진 console app을 생성합니다.

csStudy04 solution에서 'Debugging'이라는 이름의 project를 생성한 뒤 Program.cs를 아래와 같이 수정합니다.

double Add(double a, double b)
{
	return a * b;
}

그리고 해당 함수의 위에서 아래와 같이 몇개의 변수를 선언하고 값을 설정하는 구문과 함께 위 함수를 호출하는 구문을 추가합니다.

double a = 4.5;
double b = 2.5;
double answer = Add(a, b);

Console.WriteLine($"{a} + {b} = {answer}");

위 예제를 실행하면 다음과 같은 결과를 확인할 수 있습니다.

결과를 보면 4.5와 2.5를 더한 7이 나와야 하지만 11.25가 나옴으로써 code안에 bug가 있음을 알 수 있습니다.

(3) 중단점설정및 debugging

중단점(Breakpoint)은 Program의 상태를 확인하고 bug를 찾기 위해 실행 중 멈추고자 하는 code의 line을 표시하는 것입니다.

Visual Studio 2022의 code editor에서 a이름의 변수를 선언한 구문이 있는 첫 행을 click 합니다. 그리고 Debug->Toggle Breakpoint menu 또는 F9 key를 누릅니다. 그러면 다음과 같이 붉은색 원이 좌변 여백공간에 표시되고 해당 구문이 Breakpoint가 설정되었음을 알리기 위해 붉은색으로 강조될 것입니다.

이렇게 설정된 Breakpoint는 같은 동작을 통해 설정이나 해제를 반복할 수 있습니다. 또한 여백자체를 mouse 왼쪽 click해도 마찬가지 동작을 수행합니다. 여백을 오른쪽 click 하면 삭제, 비활성 혹은 조건변경이나 현재 breakpoint에 대한 동작을 의미하는 더 많은 option을 표시합니다.

이제 Debug->Start Debugging이나 F5 key를 누르면 Visual Studio는 console application을 시작하게 되고 실행시점이 설정해둔 breakpoint에 도달하게 되면 일시적으로 실행을 멈추게 됩니다. 이 상태를 break mode라고 하며 Visual Studio안에서 Locals(지역변수의 현재 값을 표시하는 창), Watch 1(정의한 모든 watch 표현식을 표시), Call Stack, Exception Settings 그리고 Immediate창을 확장하여 표시합니다. 또한 다음으로 실행될 line은 노란색으로 표시되며 여백으로부터 노란색 화살표가 해당 line을 다음과 같이 표시합니다.

(4) Debugging toolbar

Visual Studio 2022는 Standard toolbar와 Debug toolbar라는 2개의 group으로 debug관련 button들을 가지고 있습니다. Standard toolbar는 debugging을 시작하거나 계속진행하고 동작중인 code의 변경사항을 hot reload하기 위한 것이며 그 외 tool의 나머지는 Debug toolbar로 분리되어 있습니다.

Start/Continue/F5 : 이 button은 상황에 따라 다르게 동작합니다. project의 동작을 시작하거나 현재 위치에서 code의 종료시 또는 다른 breakpoint까지 실행을 계속 진행하도록 합니다.
Hot Reload : 이 button은 compile된 code의 변경사항을 app을 재실행하지 않고도 다시 load 하도록 합니다.
Break All : 이 button은 동작중인 app에서 다음 가능한 code의 line으로 일시중지합니다.
Stop Debugging/Stop/Shift + F5 (붉은색 사각형) : 이 button은 debugging session을 중지합니다.
Restart/Ctrl or Cmd + Shift + F5 (원형 화살표) : 이 button은 현재 debugging session을 중지한 뒤 곧장 program에 debgger를 연결시킨 뒤 다시 실행합니다.
Show Next Statement : 이 button은 현재 cursor를 다음 실행될 구문으로 이동시킵니다.
Step Info/F11, Step Over/F10, Step Out/Shift + F11 (반점이 있는 파란색 화살표) : 이들 button은 code구문을 다양한 방법을 통해 단계적으로 실행시킴으로써 실행 순간을 확인할 수 있도록 합니다.
Show Threads in Source : 이 button은 debugging중인 application에 대한 thread를 검사하고 작업할 수 있도록 합니다.

(5) Debugging Windows

debugging하는 동안 Visual Studio 2022에서는 여러 window화면을 통해 code를 단계적으로 실행하면서 변숫값의 변화등을 관찰하는 등 여러 유용한 정보를 확인할 수 있습니다.

debugging시에 가장 많이 사용되는 windows창으로는 아래와 같은 것들이 있습니다.

VARIABLES : Locals를 포함해 모든 지역변수에 대한 이름, 값, type등을 자동적으로 확인할 수 있습니다. 이를 통해 code를 단계적으로 실행하는 동안 그때그때 변화되는 정보를 관찰합니다.
WATCH / Watch 1 : 변수의 값과 임의로 입력한 표현식을 나타냅니다.
CALL STACK : 함수 호출간 stack정보를 표시합니다.
BREAKPOINTS : 모든 breakpoint를 표시하고 이들을 세밀하게 제어할 수 있습니다.

break mode인 경우에는 edit의 아래에서 다음 window화면을 사용할 수 있습니다.

DEBUG CONSOLE 또는 Immediate Window : code와의 상호작용을 통해 program의 상태를 질의할 수 있습니다. 예를 들어 변수의 이름을 입력해 해당 변수의 값을 확인하거나 1 + 2와 같은 식을 요청하여 그 결과를 확인할 수 있습니다.

(6) code의 단계적 실행

Visual Studio를 통해 code를 단계적으로 실행하려면 Debug -> Step Info menu를 선택하거나 toolbar에 있는 Step Into button 또는 F11키를 눌러줍니다. 그러면 노란색 강조 부분이 다음 line으로 이동하게 됩니다.

Debug -> Step Over menu를 선택하거나 toolbar에 있는 Step Over button 또는 F10키를 눌러도 노란색 강조부분이 다음 line으로 이동해서 이전과 동일하다고 생각될 수 있습니다. 그러나 현재 단계적으로 실행되고 있는 부분이 method라면 Step Into는 debugge가 method실행 내부로 들어가게 되므로 method의 모든 line을 단계적으로 실행하게 되지만 Step Over는 method전체를 한 번에 실행한 후 method다음의 line으로 이동한다는 차이가 있습니다.

Step Into를 눌러 method안으로 진입합니다. 이때 mouse pointer를 매개변수 a나 b위에 올려두면 tooltip을 통해 해당 변수의 현재값을 표시할 것입니다.

이번에는 a * b식을 선택한 뒤 mouse 오른쪽 button을 눌러 Add Watch를 선택합니다. 해당 식은 Watch 1창으로 추가되고 a와 b의 *연산에 대한 결과가 11.25 임을 표시하게 됩니다.

Watch 1 window에서 해당 식에 다시 mouse 오른쪽 button을 눌러 Delete Watch를 선택하여 추가된 a * b식을 삭제합니다.

이제 결과를 확인하여 문제가 무엇인지를 확인했으니 함수에서 *기호를 +로 변경합니다.

debugging을 멈추고 다시 재 compile을 수행한 다음 toolbar에서 Restart button이나 Ctrl + Shift + F5 key를 눌러 debugging을 재시작합니다.

이번에는 함수를 단계적으로 실행하고 계산되는 정확성을 확인한 후 Continue button을 누르거나 F5 key를 눌러줍니다.

(7) breakpoint 활용하기

breakpoint자체도 여러 유용한 설정을 적용할 수 있습니다.

우선 debugging중이라면 toolbar의 Stop button을 누르거나 Debug -> Stop Debugging menu 또는 Shift + F5 key를 눌러 debugging을 중지합니다.

Debug->Delete All Breakpoints menu를 선택해 현재 설정된 모든 breakpoint를 삭제합니다.

code상에 Console.WriteLine구문을 click 하고 F9 key 또는 Debug -> Toggle Breakpoint menu를 선택해 breakpoint를 설정합니다.

이어서 breakpoint를 mouse오른쪽 button으로 click한 후 Conditions menu를 선택합니다.

해당 설정화면에서 다음과 같이 answer변수가 9이상이 되어야 한다는 수식을 입력하고 'Close' button을 눌러줍니다. 이때 Is true는 입력한 수식으로 breakpoint가 작동하기 위해서는 true가 되어야 한다는 것을 의미합니다.

이렇게 설정한 후 다시 debugging을 시도하면 breakpoint가 작동하지 않음을 알 수 있습니다. condition으로 입력한 수식의 조건이 맞지 않기 때문입니다. 따라서 같은 방법으로 condition을 6으로 설정한 뒤 다시 debugging을 시도하면 이번에는 breakpoint가 작동하게 될 것입니다.

이번에는 조금 다르게 condition을 설정해볼텐데 condition설정화면에서 'Add condition'을 click 하여 새로운 condition을 입력할 수 있도록 합니다. 그리고 Hit count의 값을 다음과 같이 3으로 설정합니다.

해당 설정은 breakpoint가 작동하기 위해서 중단점 부분의 구문이 3번 평가되어야 함을 의미합니다.

설정이 완료된 후 breakpoint로 mouse를 올리게 되면 다음과 같이 설정상태가 tooltip으로 표시되는데 이를 통해 condition설정화면을 다시 열지 않고도 현재의 설정상태를 확인할 수 있습니다.

3. Hot reload

hot reload는 app을 debugging하는 중에도 code를 변경하고 그 즉시 변경된 사항을 반영하여 app의 실행을 확인해 볼 수 있도록 하는 기능입니다. app이 가진 bug를 빠르게 수정할 수 있게 하는 것으로 'Edit and Continue'이라고도 합니다. code를 변경할 수 있도록 hot reload가 지원하는 code의 목록은 아래 link에서 확인할 수 있습니다.

Supported Code Changes (C# and Visual Basic) - Visual Studio (Windows) | Microsoft Learn

Supported Code Changes (C# and Visual Basic) - Visual Studio (Windows)

Understand what code changes are supported when you are using the Edit and Continue feature while debugging a C# or Visual Basic project in Visual Studio.

learn.microsoft.com

.NET 6가 release 되기 전 Microsoft의 직원은 Hot reload를 Visual Studio 전용기능을 만들려고 시도했는데 Microsoft내 open-source관련 부서에서는 이와 같은 결정을 뒤집어 command-line에서도 사용가능하도록 하였습니다.

'csStudy04' solution에서 'HotReloading' project를 추가하고 Program.cs에서 기존 구문을 모두 제거한 뒤 2초마다 console로 message를 출력하는 아래 예제를 작성합니다.

while (true)
{
	Console.WriteLine("Hello, Hot Reload!");
	await Task.Delay(2000);
}

(1) Visual Studio 2022에서 Hot reload사용하기

project를 실행하고 매2초마다 console에 출력되는 message를 확인합니다. 이 상태에서 Debug->Apply Code Changes menu를 선택하거나 toolbar의 Hot Reload button을 click 하여 message를 'Hello to Goodbye'로 변경합니다. 그러면 message는 console app을 재시작하지 않고도 변경사항이 적용될 것입니다.

'Hot Reload' button의 mene를 내려 'Hot Reload on File Save'를 check하면 source code의 file이 저장될 때마다 변경사항이 자동작으로 반영될 것입니다.

(2) Visual Studio Code와 commnad line에서 Hot reload사용하기

Visual Studio Code에서는 console app을 실행할때 Hot Reload를 사용하기 위해서 특별한 명령을 내려야 합니다. Visual Studio Code의 TERMINAL이나 Windows Terminal을 열고 해당 project가 존재하는 folder로 이동한 뒤 'dotnet watch'명령을 내립니다. 그러면 다음과 같이 console app이 hot reload가 활성화되어 app이 실행될 것입니다.

이 상태에서 이전과 마찬가지로 message를 'Hello to Goodbye'로 변경하여 2초후에 해당 변경내용이 적용되는지 확인합니다.

app의 실행을 중단하고자 한다면 'Ctrl + C' key를 누릅니다.

4. 개발중에서와 runtime에서의 Logging

code에서 모든 bug가 제거되었다고 판단된다면 release version compile 하고 사람들이 사용할 수 있도록 application을 배포할 수 있을 것입니다. 하지만 그럼에도 불구하고 code상에는 잠재적인 bug가 존재할 수 있고 runtime동안에 예상하지 못한 에러가 유발될 수 있습니다.

사용자는 오류가 발생했을때를 기억하고 그때 자신이 무엇을 했는지에 대해 자세하게 설명하지 못하는 경우가 대부분입니다. 따라서 문제점을 파악하고 수정할 수 있도록 오류상황을 재현하기 위해 필요한 정보를 제공할 때 이러한 정보에 의존해서는 안됩니다. 대신 관련된 event를 기록함으로써 code에 대한 문제점을 측정할 수 있습니다.

무슨 일이 일어나고 있는지에 대한 log를 위해, 특히 예외가 발생했을 때를 위해 application전역에 관련 code를 추가합니다. 그리고 이러한 log를 검토하여 문제점을 추적하고 이를 해결하기 위해 사용해야 합니다.

(1) logging option

.NET은 logging기능을 추가함으로써 code를 측정하기 위한 몇몇 기본적인 방법을 포함하고 있습니다. 여기서 우리는 기본적인 부분만을 살펴볼 것입니다. 사실 logging은 제삼자가 Microsoft가 제공하는 것을 확장한 강력한 solution의 풍부한 생태계로 만들어져 온 영역입니다. 따라서 어떤 것이 필요한지는 필요한 상황에 따라 달라질 수 있으므로 특정한 것을 사용하라고 권장할 수는 없습니다. 그러나 대개 아래 항목의 logging을 많이 사용하는 것으로 보입니다.

Apache log4net
NLog
Serilog

(2) Debug와 Trace를 사용한 추적

우선 code에 간단한 logging을 추가하기 위한 2가 유형이 존재하는데 그것이 바로 Debug와 Trace입니다.

Debug : 개발하는 동안에 작성되는 logging을 위해 사용되는 class입니다.
Trace : 개발과 runtime둘다 작성되는 logging을 위해 사용되는 class입니다.

지금까지의 예제를 통해 우리는 Console app에서 무엇인가를 출력하기 위해 WriteLine method를 사용했었습니다. Debug와 Trace class도 비슷하게 무엇인가를 출력하기 위해 사용되는데 이 출력의 대상이 trace listener가 되며 trace listener는 WriteLine method를 호출할 때 원하는 곳 어디든 출력을 쓰도록 구성할 수 있는 type입니다. .NET에서는 console로의 출력을 포함해 자체적으로 제공하는 몇몇 trace listener가 존재하고 있고 필요하다면 TraceListener type에서 상속하여 자신만의 listener를 직접 만들 수도 있습니다.

● 기본 trace listener로 작성하기

하나의 trace listener인 DefaultTraceListener class가 자동적으로 구성되고 Visual Studio의 Debug window에 기록되면 code를 사용해 다른 trace listener를 구성할 수 있습니다.

csStudy04 solution에서 Instrumenting이름의 project를 추가하고 Program.cs에서 기존구문을 모두 제거한 뒤 System.Diagnostics namespace를 import 하고 뒤이어 Debug와 Trace class에서 message를 기록하도록 합니다.

using System.Diagnostics;

Debug.WriteLine("Debug says, I am watching!");
Trace.WriteLine("Trace says, I am watching!");

Visual Studio에서 View -> Output menu를 선택하고 'Show output from'에서 'Debug'를 선택한 다음 Instrumenting console app의 debugging을 시작합니다. Visual Studio 2022 Output window에서 assembly DLL의 loaded 다른 debugging정보와 함께 2개의 message가 표시됨을 볼 수 있을 것입니다.

Debug says, I am watching!
Trace says, I am watching!

(3) trace listener 구성

이번에는 text file에 기록하는 trace listener를 설정해 볼 것입니다.

Debug와 Trace에서 WriteLine을 호출하기 전에 바탕화면으로 새로운 text file을 생성하고 해당 file로 log를 기록하는 trace listener를 전달하는 구문과 함께 buffer로 자동 flush 되도록 설정하는 code를 추가합니다.

using System.Diagnostics;

string logPath = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.DesktopDirectory), "log.txt");
Console.WriteLine($"Writing to: {logPath}");

TextWriterTraceListener logFile = new(File.CreateText(logPath));
Trace.Listeners.Add(logFile);
Trace.AutoFlush = true;

file을 나타내는 모든 type은 대게 성능향상을 위해 buffer를 구현합니다. file로 즉시 기록하는 대신 작성된 data를 memory buffer에 담아두고 buffer가 일정용량을 차지하게 되면 그때까지의 data전체를 file로 기록하는 것입니다. 이러한 동작으로 인해 예제를 실행할 때는 즉각적인 결과를 학인할 수 없을 수도 있습니다. 예제의 AutoFlush는 Flush method가 매번 기록 후에 호출되도록 합니다.

Visual Studio에서는 toolbar에 있는 Solution Configrurations의 drop-down목록에서 Release를 선택하고 Debug->Start Without Debugging menu를 선택해 예제를 실행합니다. 그런 뒤 바탕화면에서 log.txt file을 열어 'Trace says, I am watching!'문구가 기록되어 있는지 확인합니다.

Debug설정으로 app을 동작시킬 때는 Debug와 Trace가 활성화되어 trace listener로 기록을 수행할 것입니다. 반면 Release설정으로 app이 동작될 때는 오로지 Trace만 trace listener로 기록을 시도합니다. 따라서 Debug.WriteLine의 호출은 application을 release version으로 build 하게 되면 자동으로 제거되고 따라서 성능에 영향을 주지 않을 것이므로 code전역에서 자유롭게 사용할 수 있습니다.

(4) trace 수준 전환하기

Trace.WriteLine를 호출하는 것은 release이후에도 code에 남아있으며 이들에 대한 output은 trace switch르 통해 어느 정도 제어할 수 있습니다.

trace switch의 값은 숫자나 단어로 설정할 수 있습니다. 예를 들어 숫자 3은 아래 표에서와 같이 Info라는 단어로 바뀔 수 있습니다.

Number	Word	Description
0	Off	아무것도 출력하지 않습니다.
1	Error	Error만 출력합니다.
2	Warning	Error와 Warning만 출력합니다.
3	Info	Error와 Warning, Infomation만 출력합니다.
4	verbose	전체 수준을 모두 출력합니다.

trace switch를 사용하기 위해서는 우선 필요한 NuGet package를 설치하여 JSON appsettings file로부터 구성설정값을 load 할 수 있도록 해야 합니다.

● Project에 package 추가하기

Visual Studio의 project에서 mouse 오른쪽 button을 눌러 'Manage NuGet Packages'를 선택합니다. 그리고 Browse tab을 선택한 뒤 'Microsoft.Extensions.Configuration'을 입력하고 아래 항목의 NuGet package를 검색해 설치합니다.

Microsoft.Extensions.Configuration.Binder
Microsoft.Extensions.Configuration.Json

이외에도 XML file이나 INI, 환경 변수, command line에서 설정을 loading 하는 package도 존재합니다. 따라서 project의 환경설정에 가장 적합한 것을 사용하면 됩니다.

● Project package 확인

NuGet package가 설치되고 나면 project file의 <ItemGroup> section에서 다음과 같이 참조를 확인할 수 있습니다.

<ItemGroup>
	<PackageReference Include="Microsoft.Extensions.Configuration.Binder" Version="8.0.1" />
	<PackageReference Include="Microsoft.Extensions.Configuration.Json" Version="8.0.0" />
</ItemGroup>

이제 project에 'appsettings.json'이름의 file을 추가하고 LogSwitch이름의 설정을 Level값과 함께 정의합니다.

{
    "LogSwitch": {
        "Value": "Info"
    }
}

Microsoft는 .NET 7의 최종 release이후 7.0.3 version의 Microsoft.Extensions.Configuration.Binder package에 존재해 있던 bug를 수정하였습니다. 이 bug는 이전 version에서 설정을 읽는 방식때문에 예외가 발생할 수 있습니다. Microsoft.Extensions.Configuration.Binder 7.0.3이전까지는 Level속성을 "Level": "Info"처럼 설정하는게 가능했지만 bug가 수정된 이후에는 내부 class에서 Value속성이 설정되어야 하기 때문에 예외를 발생시킬 수 있으므로 Value속성을 설정하거나 아니면 둘의 속성값 모두를 설정해야 합니다.

https://github.com/dotnet/runtime/issues/82998

추가된 appsettings.json file에서 mouse오른쪽 button을 눌러 'Properties'를 선택한 다음 'Copy to Output Directory'설정을 'Copy if newer'로 변경합니다. 이 설정은 project folder에서 project의 console app을 동작시키는 Visual Studio Code와는 달리 Instrumenting\bin\Debug\net7.0 또는 Instrumenting\ bin\Release\net7.0에서 project app을 동작시키게 되므로 필요한 설정입니다.

Program.cs에서는 다음과 같이 Microsoft.Extensions.Configuration를 import 하고

using Microsoft.Extensions.Configuration;

file의 끝에서는 아래와 같은 구문을 추가합니다. 해당 문은 현재 folder에서 appsettings.json file을 확인하기 위한 configuration builder를 생성하고 설정을 build 하며 trace switch를 생성한 후 여기에 설정을 binding 함으로써 level을 설정하고 4개의 switch level을 출력하도록 합니다.

Console.WriteLine("Reading from appsettings.json in {0}", arg0: Directory.GetCurrentDirectory());

ConfigurationBuilder builder = new();
builder.SetBasePath(Directory.GetCurrentDirectory());
builder.AddJsonFile("appsettings.json", optional: true, reloadOnChange: true);

IConfigurationRoot configuration = builder.Build();

TraceSwitch ts = new(displayName: "LogSwitch", description: "This switch is set via a JSON config.");

configuration.GetSection("LogSwitch").Bind(ts);

Trace.WriteLineIf(ts.TraceError, "Trace error");
Trace.WriteLineIf(ts.TraceWarning, "Trace warning");
Trace.WriteLineIf(ts.TraceInfo, "Trace information");
Trace.WriteLineIf(ts.TraceVerbose, "Trace verbose");

Console.ReadLine();

Bind구문에 breakpoint를 설정하고 debugging을 시작합니다. debugging이 시작된 뒤 Locals window에서 ts변수식을 확장해 보면 다음과 같이 Level과 TraceError, TraceWarning 등이 모두 false로 되어 있음을 확인할 수 있습니다.

이 상태에서 Step Into 또는 Step Over button을 누르거나 F11 또는 F10 key를 눌러 Bind method를 호출하여 ts 변수식에서 level이 Info로 변경되는 것을 확인합니다.

계속해서 4개의 Trace.WriteLineIf의 호출 부분을 실행함으로써 Info로 변경된 모든 level이 Verbose를 제외하고 Output - Debug window에 표시됨을 확인합니다.

Debugging을 중지하고 이번에는 appsettings.json에서 'Value'의 값을 2(warning)로 변경한 뒤 'Solution Configurations'의 설정을 Release로 선택하고 Debug -> Start Without Debugging으로 console app을 실행합니다.

그리고 바탕화면의 log.txt file을 열어보면 4개의 trace level 중에서 trace error와 warning level만이 출력되어 있음을 확인할 수 있습니다.

Trace says, I am watching!
Trace error
Trace warning

만약 어떠한 인수도 전달하지 않았다면 기본 trace switch level은 0(OFF)이 되고, 그러면 어떠한 switch level로 출력되지 않을 것입니다.

(5) source code에 관한 Logging 정보

log를 사용할 때 때로는 source code file의 이름이나 method이름, 혹은 line number와 같은 source code의 정보를 포함하고 싶을 수 있습니다. 심지어 C# 10부터는 함수의 인수로 전달된 모든 수식을 문자열값으로 가져올 수 있으므로 이를 log화 하는 것도 가능하게 되었습니다.

이러한 모든 정보는 함수의 매개변수에 아래 table에 나타난 특별한 attribute를 적용함으로써 가져올 수 있습니다.

[CallerMemberName] string member = ""	member라는 이름의 string 매개변수에 매개변수가 정의된 해당 method를 실행하는 method나 property이름을 설정합니다.
[CallerFilePath] string filepath = ""	filepath라는 이름의 string 매개변수에 매개변수가 정의된 해당 method를 실행하는 구문을 포함한 source code file의 이름을 설정합니다.
[CallerLineNumber] int line = 0	line이라는 int 매개변수에 매개변수가 정의된 해당 method를 실행하는 구문을 가진 source code file의 line번호를 설정합니다.
[CallerArgumentExpression( nameof(argumentExpression))] string expression = ""	expression이라는 string 매개변수에 argumentExpression이름의 매개변수로 전달된 식을 설정합니다.

해당 매개변수는 기본값을 할당하여 선택적 매개변수로 만들어야 합니다. 그럼 예제를 통해 실제 어떻게 해당 attribute를 사용할 수 있는지 알아보겠습니다.

Instrumenting project에서 Methods.cs이름의 class file을 추가하고 해당 file에 LogSourceDetails이름의 함수를 정의합니다. 이 함수는 호출 code에 대한 정보를 log 하기 위해 위에서 설명한 4개의 attribute를 사용합니다.

partial class Program
{
	static void LogSourceDetails(bool condition, [CallerMemberName] string member = "", [CallerFilePath] string filepath = "", [CallerLineNumber] int line = 0, [CallerArgumentExpression(nameof(condition))] string expression = "")
	{
		Trace.WriteLine(string.Format("[{0}]\n {1} on line {2}. Expression: {3}", filepath, member, line, expression));
	}
}

Program.cs에서는 file의 마지막 Console.ReadLine()를 호출하기 전에 LogSourceDetails함수로 전달될 식에서 사용되는 변수를 선언하고 값을 할당하는 구문을 추가합니다.

Trace.WriteLineIf(ts.TraceVerbose, "Trace verbose");

int unitsInStock = 12;
LogSourceDetails(unitsInStock > 10);

Console.ReadLine();

예제에서는 고정된 값의 식을 사용하지만 실제 project에서는 사용자에 의해 동적으로 생성되는 식이 될 수 있습니다.

debugging 없이 예제를 실행한 뒤 console app을 닫고 바탕화면의 log.txt를 보면 다음과 같이 file이 기록되어 있음을 확인할 수 있습니다.

[C:\Users\clicl\source\repos\csStudy04\Instrumenting\Program.cs]
<Main>$ on line 32. Expression: unitsInStock > 10

5. 단위 TEST

완성된 application에서 오류를 수정하기보다는 가급적 개발과정에서 오류를 발견하는 것이 훨씬 좋다는 건 두말할 나위가 없을 것입니다.

이를 위해 단위 test라는 것이 존재하며 개발 중에서 bug를 찾기 위한 좋은 방법입니다. 어떤 개발자는 실제 code를 작성하기 전에 단위 test를 먼저 생성하는 원칙을 따르고 있으며 이러한 개발 방법을 TDD(Test-Driven Development)라고 합니다.

Microsoft는 단위 test를 위한 framework로 MSTest를 제공하고 있으며 NUnit라는 또 다른 framework도 존재합니다. 여러 가지 단위 test framework를 사용할 수 있지만 예제에서는 xUnit.net을 사용할 것입니다. 이 framework는 무료이며 open-source입니다.

(1) Testing type

단위 test는 test를 위한 여러 유형 중의 하나이며 아래 표와 같은 다른 test 유형도 존재합니다.

Unit	code의 작은 단위에 대한 test로서 method나 function과 같은 것입니다. 단위 test는 필요한 경우 이들을 mocking함으로서 의존성으로 부터 격리된 code의 단위를 수행합니다. 일반적인 입력과 예상되는 출력, 한계 test를 위한 극한입력, 잘못된 입력을 통한 예외처리 test등 여러 test를 가질 수 있습니다.
Integration	작은 단위와 큰 component가 하나의 software로서 작동할 수 있는지를 test하는 것으로 source code가 없는 외부 component와의 통합을 포함합니다.
System	Software가 작동할 전체 system 환경을 test합니다.
Performance	Software의 성능을 test하는 것으로 수초이내에 data가 채워진 web page를 반환해야 하는 경우등을 들 수 있습니다.
Load	얼마나 많은 요청을 software가 필요한 성능을 유지하면서 동시적으로 처리할 수 있는가에 대한 test로서 10000명의 사용자가 동시에 방문하는 경우등을 들 수 있습니다.
User Acceptance	사용자가 software를 사용하여 만족스럽게 필요한 작업을 수행할 수 있는지의 여부를 test합니다.

(2) test를 수행하는 class library 생성

가장 먼저 test를 수행하는 함수를 만들어야 합니다. 이를 위해 기존 예제의 console app project와는 별개의 class library project를 생성해야 하며 해당 class library는 다른 .NET application에서 참조되고 배포될 수 있는 code의 package입니다.

csStudy04 solution에서 'CalculatorLib'이름의 class library project를 생성하고 'Class1.cs'이름의 file을 ' Calculator.cs'로 변경한 후 해당 file을 아래와 같이 작성합니다. (고의적으로 잘못된 code를 사용하는 것이므로 있는 그대로 작성합니다.)

namespace CalculatorLib
{
	public class Calculator
	{
		public double Add(double a, double b)
		{
			return a * b;
		}
	}
}

그리고 해당 project를 build 합니다.

다음으로 csStudy04 soluction에 'CalculatorLibUnitTests'이름의 xUnit Test Project를 추가한 뒤 해당 project에서 위에서 만든 CalculatorLib를 참조추가하고

해당 project를 build 합니다.

(3) 단위 test 작성

단위 test는 세 부분으로 구성됩니다.

Arrange : 입력과 출력을 위한 변수를 선언하고 instance 하는 부분입니다.
Act : test 할 단위를 실행하는 부분입니다. 지금의 경우에는 test할 method를 호출하는 것이 됩니다.
Assert : 출력에 관한 하나 또는 그 이상의 assertion을 만드는 부분으로 assertion은 결과가 true가 아니면 test는 실패했음을 표시합니다.

이제 Calculator class에 대한 몇 가지 단위 test를 만들어볼 것입니다.

우선 'UnitTest1.cs'file을 'CalculatorUnitTests.cs'로 변경하고 file안에서 CalculatorLib namespace를 import 합니다. 그리고 CalculatorUnitTests class에 2개의 method를 추가할 텐데 하나는 2와 2를 더하는 것이고 다른 하나는 2와 3을 더하는 method입니다.

using CalculatorLib;

namespace CalculatorLibUnitTests
{
	public class CalculatorUnitTests
	{
		[Fact]
		public void TestAdding2And2()
		{
			// arrange 
			double a = 2;
			double b = 2;
			double expected = 4;
			Calculator calc = new();

			// act
			double actual = calc.Add(a, b);

			// assert
			Assert.Equal(expected, actual);
		}

		[Fact]
		public void TestAdding2And3()
		{
			// arrange 
			double a = 2;
			double b = 3;
			double expected = 5;
			Calculator calc = new();

			// act
			double actual = calc.Add(a, b);

			// assert
			Assert.Equal(expected, actual);
		}
	}
}

● 단위 test 실행하기

위에까지 진행하면 이제 단위 test를 실행할 준비가 완료된 것입니다. Visual Studio에서 Test -> Run All Tests menu를 선택합니다. 그러면 Test Explorer에서 2개의 test동작에 대한 결과를 표시할 텐데 아마도 하나는 성공(passed), 다른 하나는 실패(Failed)로 표시할 것입니다.

● bug 수정하기

Add method에서 a * b부분을 a + b로 변경하고 다시 test를 실행합니다. 그러면 이번에는 모든 method가 test에 통과했음을 표시할 것입니다.

6. 함수에서의 예외 throwing과 catching

예외 처리에 관해서는 아래 글에서 try-catch문을 사용해 본 바 있습니다.

[.NET/C#] - [C# 12와 .NET 8] 3. 흐름제어, Type 변환, 예외 처리

[C# 12와 .NET 8] 3. 흐름제어, Type 변환, 예외 처리

lab.cliel.com

그러나 문제를 완화하기 위한 충분한 정보를 가지고 있는 경우에만 예외를 catch 하고 처리해야 합니다. 그럴 수 없는 경우에 예외는 상위 수준으로 호출 stack을 통해 전달되도록 해야 합니다.

(1) usage error와 execution error

Usage error는 개발자가 함수를 잘못 사용하는 경우와 같은 것이며 일반적으로 매개변수로 잘못된 값을 전달하는 경우를 들 수 있습니다. 이런 경우에는 개발자가 정확한 값을 전달하도록 code를 변경함으로써 처리할 수 있습니다. programming을 처음 접하는 경우에는 모든 error가 usage error라고 추정함으로써 예외를 피할 수 있을 것이라 생각하기도 하지만 실제로 그렇게 하는 것은 불가능하며 Usage error는 application이 제품화되어 실행되기 전에 모두 수정되어야 합니다.

Execution error는 application이 code를 보완하여 수정할 수 없는 실행 시에 발생하는 것입니다. Execution error는 세부적으로 program error와 system error로 분리될 수 있습니다. 만약 application에서 network resource에 접근하려 할 때 network가 down 된 상태라면 예외를 기록하고 잠시 기다렸다 다시 시도함으로써 예외를 처리할 수 있을 것입니다. 하지만 memory부족과 같은 system error의 경우에는 처리가 쉽지 않을 수 있습니다. 존재하지 않는 file을 열려고 하는 경우에는 이에 대한 error를 catch 하고 program상에서 신규 file을 생성함으로써 처리할 수 있습니다. Program error는 code를 개선함으로써 수정할 수 있지만 System error는 종종 code의 개선만으로 해결할 수 없는 경우가 많습니다.

(2) 함수에서의 일반적인 예외

흔한 경우는 아니지만 usage error를 나타내기 위해 새로운 예외 type을 정의하는 경우도 있으며 .NET은 이미 사용가능한 많은 type을 정의하고 있습니다.

매개변수와 함께 함수를 정의할 때 code에서는 매개변수의 값을 확인하고 적절하게 작동할 수 없도록 하는 값을 가진 경우 예외를 발생시킬 수 있습니다.

예를 들어 함수의 인수가 null이라면 ArgumentNullException를 발생시킬 수 있을 것입니다. 그 외 다른 문제라면 ArgumentException, NotSupportedException 또는 InvalidOperationException을 발생시킬 수도 있고 어떠한 문제든 아래와 같은 code를 통해 문제점을 설명하는 message로 사람들(일반적으로 class library나 함수에 대한 개발자 또는 GUI app에서 최상위 수준인 경우 최종 사용자)에게 상세내용을 제공해 줄 수도 있습니다.

static void Withdraw(string accountName, decimal amount)
{
	if (accountName is null)
	{
		throw new ArgumentNullException(paramName: nameof(accountName));
	}
	if (amount < 0)
	{
		throw new ArgumentException(message: $"{nameof(amount)} cannot be less than zero.");
	}
}

새로운 exception가 발생할 때 if문을 사용하는 대신 .NET 6부터는 인수가 null인 경우 예외를 발생시키는 편리한 method를 도입하였고 아래와 같이 사용할 수 있습니다.

static void Withdraw(string accountName, decimal amount)
{
	ArgumentNullException.ThrowIfNull(accountName);
}

C# 11 preview에서는 null 확인 연산자인!! 을 도입하여 위에서와 같은 기능을 수행하도록 하였으나 정식 version에서 제거되었습니다.

static void Withdraw(string accountName!!, decimal amount)

이러한 usage error를 잡기 위해서는 꼭 try-catch문을 사용할 필요는 없습니다. 이러한 예외로 인해 함수를 호출하는 개발자는 문제를 방지하기 위해 application이 배포되기 전 code를 수정해야 합니다. 이는 code가 usage error type의 예외를 발생시킬 필요가 없다는 것을 의미하는 것이 아니지만 다른 개발자들이 함수를 정확히 호출할 수 있도록 해야 합니다.

(3) call stack

.NET console application의 주요 진입점은 Program class의 Main(명시적으로 method를 정의한 경우, top-level program기능으로 만들어진 것이라면 <Main>$입니다.)이라는 이름의 method입니다.

Main method는 다른 method를 호출할 것이고 해당 method는 또 다른 method를 호출할 수 있을 것입니다. 그리고 이들 method는 현재 project나 참조된 project 또는 NuGet package에 존재할 수 있습니다.

이제 위 그림과 비슷한 method chain을 만들어 봄으로서 예로서 제시된 예외를 catch 하고 이를 적절한 처리하는 방법에 관해 알아볼 것입니다. csStudy04 solution에서 'CallStackExceptionHandlingLib'이름의 Class Library project를 추가하고 Class1.cs file을 Calculator.cs로 변경한 뒤 Calculator.cs를 아래와 같이 변경합니다.

namespace CallStackExceptionHandlingLib
{
	public class Calculator
	{
		public static void Gamma() // public so it can be called from outside
		{
			Console.WriteLine("In Gamma");
			Delta();
		}
		private static void Delta()
		// private so it can only be called internally
		{
			Console.WriteLine("In Delta");
			File.OpenText("bad file path");
		}
	}
}

이번에는 같은 solution에 Console App형식의 'CallStackExceptionHandling' project를 추가하고 해당 project에서 CallStackExceptionHandlingLib를 참조 추가합니다. 그리고 Program.cs에서 기존 구문을 삭제하고 2개의 method를 정의한 뒤 아래와 같이 class library의 method와 이들 method를 연쇄적으로 호출하도록 하는 구문을 추가합니다.

using CallStackExceptionHandlingLib;
using static System.Console;

WriteLine("In Main");
Alpha();

void Alpha()
{
	WriteLine("In Alpha");
	Beta();
}

void Beta()
{
	WriteLine("In Beta");
	Calculator.Gamma();
}

이제 debugging 없이 project를 실행하면 다음과 같은 결과를 표시할 것입니다.

call stack은 밑에서부터 거슬러 올라가야 하는데 이를 통해 우리는 다음과 같은 사항을 확인해 볼 수 있습니다.

처음 호출되는 것은 Program class에서 자동으로 생성된 <Main>$ entry point입니다. 여기에서 string배열을 통해 인수가 전달됩니다.
두 번째로 호출되는 것은 '<<Main>$>g_Alpha|0_0'함수입니다.(C# compiler는 Alpha를 지역함수로 추가할 때 이름을 바꾸게 됩니다.)
세 번째로 호출되는 것은 Beta 함수입니다.
네 번째로 호출되는 것은 Gamma 함수입니다.
다섯 번째로 호출되는 것은 Delta 함수입니다. 이 함수에서는 옳지 않은 경로를 전달하여 file열기를 시도하는데 이때 예외를 발생시키게 됩니다. 이때 try-catch를 가진 모든 함수는 이 예외를 잡아낼 것입니다. 그렇지 않다면 위 결과와 같이 call stack의 상세와 함께 예외를 표시하게 되는 최상위에 도달할 때까지 자동적으로 call stack의 위로 예외를 전달하게 됩니다.

debugging 하기 위한 code의 단계적 실행이 필요하지 않다면 code를 debugger 없이 실행할 수 있습니다. 이 경우 debugger를 연결하지 않는 것이 특히 중요합니다. 그러면 예외가 catch 되고 이를 위 결과와 같이 표시하는 대신 GUI dialog box를 통해 표시할 것입니다.

(4) 예외를 catch 할 수 있는 곳

개발자 입장에서는 처리가 실패한 곳에서 예외를 catch 할지, call stack의 상위에서 집중적으로 예외를 catch 할지를 결정할 수 있습니다. 이는 통해 code를 단순화시키고 표준화시키는데 도움이 됩니다. 예외를 호출하면 하나이상의 예외유형이 발생할 수 있지만 call stack의 현재 지점에서 이들을 처리할 필요는 없습니다.

(5) 예외 재발생

때로는 예외를 catch 하여 이를 기록하고 해당 예외를 다시 발생시키고 싶은 경우도 있습니다. 예를 들어 application에서 호출될 저수준 class library를 작성하는 경우 해당 code에서는 error를 수정하기에 충분한 정보를 가지지 못할 수 있지만 이를 호출하는 application에서는 더 많은 정보를 가지고 있을 수 있습니다. 따라서 code에서는 error가 발생한 경우의 log를 기록하고 call stack의 상위로 예외를 던져 호출 application에서 이를 처리할지를 결정하도록 할 수 있습니다.

이를 위해 catch block안에서는 예외를 던지는 3가지 방법이 있습니다.

본래 call stack에서 catch 된 예외를 다시 발생시키기 위해 throw를 호출합니다.
call stack의 현재 수준에서 예외가 발생한 것처럼 catch 된 예외를 발생시키려면 catch된 예외와함께 'throw ex'처럼 throw를 호출합니다. 그러나 이는 debugging을 위해 필요한 정보를 잠재적으로 잃어버릴 수 있기 때문에 좋지 않은 방법이지만 예외(Exception)에서 민감한 정보를 포함하고 있는 경우 이를 고의적으로 삭제하기 위해서는 유용할 수 있습니다.
호출자가 문제를 이해하는데 도움이 될 수 있는 message같이 더 많은 정보를 포함할 수 있는 다른 예외로 catch 된 예외를 wrap합니다. 이를 새로운 예외를 발생시키고 catch된 예외를 innerException 매개변수로서 전달합니다.

예제에서 Gamma function을 호출할 때 예외가 발생했다면 해당 예외를 catch 하고 예외를 다시 발생시키기 위한 위의 3가지 방법 중 하나를 아래와 같이 수행할 수 있습니다.

void Beta()
{
	WriteLine("In Beta");

	try {
		Calculator.Gamma();
	}
	catch(Exception ex)
	{
		WriteLine(ex.Message.ToString());
		throw ex;
	}
}

위 code를 실제 작성하면 throw ex밑에 녹색 밑줄이 표시되면서 call stack 정보를 손실할 수 있다는 경고를 표시할 수 있습니다.

예제를 실행하면 call stack에 대한 일부 상세정보를 제외한 결과를 다음과 같이 표시할 것입니다.

위 예제에서 throw ex를 throw로만 변경하고 다시 project를 실행하면 이번에는 call stack의 모든 상세를 포함한 결과를 표시합니다.

(6) tester-doer pattern 구현하기

tester-doer pattern은 일부 예외의 발생을 방지할 수 있습니다.(완전히 없애는 것이 아닙니다.) 이 pattern은 2개의 함수를 함께 사용하는 것으로 하나는 test를 수행하고 다른 하나는 test를 통과하지 못했다면 실패할 동작을 수행합니다.

.NET은 이러한 pattern을 자체적으로 구현하고 있습니다. 예를 들어 Add method를 호출하여 collection에 item을 추가하기 전에 이것이 읽기 전용인지를 확인하는 test를 수행함으로써 Add method가 실패되고 예외를 발생시킬 수 있습니다.

또 다른 예로 은행에서 돈을 출금하기 전 초과인출여부를 확인하는 test를 아래와 같이 수행하는 것입니다.

if (!bankAccount.IsOverdrawn())
{
	bankAccount.Withdraw(amount);
}

● tester-doer patten의 문제점

tester-doer pattern은 성능 overhead를 일으킬 수 있습니다. 따라서 test와 작동함수를 하나의 단일 함수로 결합한 try pattern을 구현할 수도 있는데 TryParse가 바로 이러한 방식으로 구현된 것입니다.

tester-doer pattern의 또 다른 문제점은 다중 thread를 사용할 때 발생합니다. 이러한 경우 하나의 thread에서는 test함수를 호출하고 문제가 없음을 반환할 수 있습니다. 하지만 그때 다른 thread가 상태변경을 시도하는 것입니다. 그러면 원래 thread는 모든 것이 문제가 없다고 판단하고 자신의 실행을 계속 수행하지만 사실은 그렇지 않은 것입니다. 이러한 경우를 race condition이라고 합니다.

만약 자체 try pattern 함수를 구현했다면 해당 함수의 실행이 실패하는 경우를 대비해 해당 type의 기본값으로 out 매개변수를 설정하고 false를 반환하는 것이 좋습니다.

static bool TryParse(string? input, out Person value)
{
	if (Failure)
	{
		value = default(Person);
		return false;
	}
	
	// 성공한 경우
	value = new Person() { ... };
	return true;
}