주의 : 공부하면서 정리한 것이라서 잘못된 내용이 포함되어 있을 수 있습니다.



WPF 작업을 하다가 보면 직접 스크롤 뷰어의 동작을 제어하고 싶을 경우가 있습니다. 예를 들어 CustomControl 에서 마우스를 드래깅하면 스크롤이 갱신되는 것과 같은 작업을 원할 수 있습니다.


이 경우에 몇 ScrollViewer 를 직접 상속하는 커스텀 컨트롤을 만드는 것도 방법이지만, 다른 컨트롤을 상속해야 하는 경우에는 이런 방법을 사용할 수 없습니다.


하지만 왠만한 건 다 구현되어 있는 WPF 답게, WPF 는 스크롤에 대한 동작을 ScrollViewer 의 Content 로 지정된 컨트롤에서 제어할 수 있도록 하는 기능을 제공하고 있습니다.


그것은 IScrollInfo 라는 인터페이스를 통해서 이루어집니다. 이것은 24 개의 프라퍼티와 메서드를 구현할 것을 요구하는데요, 개수만 보면 정말 질릴 정도입니다. 하지만 기본 개념만 알고 있다면, 매우 편리하게 사용할 수 있다는 것을 알 수 있습니다.


Layouts of ScrollViewer & Content


일단 레이아웃에 대해서 간단히 살펴 보도록 하겠습니다.


그림1. ScrollViewer 와 Content 의 레이아웃.


그림1 에서 ScrollViewer 는 자신이 Content 로 포함하고 있는 컨트롤의 일부를 보여 주고 있습니다( 그림에는 "ScrollView" 라고 되어 있는데, "ScrollViewer" 입니다 ). 일반적으로 XAML 에서 다음과 같이 표현되겠죠.



FlowChartView 라는 것은 제가 개인적으로 만들고 있는 커스텀 컨트롤입니다. 다들 아실거라 생각하지만, 부연하자면, <ScrollViewer>, </ScrollViewer> 마커( marker ) 사이에 들어 가는 컨트롤은 ScrollViewer.Content 에 할당됩니다. 그래서 제가 위에서 계속 "Content 로 포함하고 있는" 이라는 표현을 쓰고 있는 겁니다. 


어쨌든 이렇게 하면 자동으로 스크롤 뷰어가 내부 내용을 인지하게 됩니다. 




하지만 안타깝게도 제가 만든 컨트롤은 크기를 지정하지 않았습니다. 내부에 Canvas 를 가지고 있으며, 그것의 크기가 결정되지 않았기 때문입니다. 그래서 ScrollViewer 는 Content 의 크기를 알 수 없습니다.


<ngv:FlowChartView Width="500" Height="500"/> 이런 식으로 크기를 지정하면 썸을 볼 수는 있습니다만, 사용자가 생성하는 노드들에 의해 크기가 결정되는 Canvas 를 만드려는 의도가 있으므로, 크기를 지정하는 것은 바람직하지 않습니다. 필자가 스크롤링하고자 하는 것은 FlowChartView 자체가 아니가 그 안에 들어 있는 Canvas 이기 때문이죠.


이야기가 다른 곳으로 샜는데, 다시 본론으로 돌아가도록 하겠습니다. 


  • Content 의 좌상단을 ( 0, 0 ) 이라고 할 때, Viewport 의 위치는 ( HorizontalOffset, VerticalOffset ) 으로 표현됩니다. 위의 그림1 에서 표현한 경우라면 HorizontalOffset VerticalOffset 은 모두 양수값이겠죠. 이것은 디바이스의 픽셀 값이 아니라, 사용자가 생각하는 논리적인 픽셀값을 의미합니다.
  • ViewportWidthViewportHeight 는 스크롤 뷰가 보여 줘야 하는 픽셀 단위의 크기를 말합니다.
  • ExtentWidth ExtentHeight 는 Content 의 픽셀 단위의 크기를 의미합니다.

레이아웃 자체는 매우 단순하며 IScrollInfo 의 메서드들은 위의 세 종류의 프라퍼티들을 결정하거나 이 프라퍼티들을 사용해서 스크롤링이 가능한지 여부를 판단하는 역할을 수행합니다.


FlowChartView 에서 IScrollInfo 인터페이스를 구현하도록 하겠습니다. 



먼저 위에 나온 프라퍼티의 기본값을 결정해 보도록 하죠.


  • ViewportWidth : FlowChartView 의 ActualWidth.
  • ViewportHeight : FlowChartView 의 ActualHeight.
  • HorizontalOffset : 0.
  • VerticalOffset : 0.
  • ExtentWidth : 1920. 물론 나중에는 실제 Content 의 크기를 계산해서 넣어 줘야 합니다.
  • ExtentHeight : 1080. 이것도 나중에는 실제 크기를 계산해서 넣어 줘야 합니다.





FlowChartView_SizeChanged() 메서드에서는 CanHorizontallyScroll CanVerticallyScroll 을 설정하는데요, 스크롤바를 제어할 수 있는지 여부를 의미하는 파라퍼티들입니다. 만약 CanHorizontallyScroll 이 false 를 반환한다면, ScrollViewer.HorizontalScrollBarVisibility Visible 일 때는 스크롤바가 딤( dim )될테고 Auto 일때는 접힐( collasped ) 것입니다.




하지만 아직까지 스크롤바를 누르거나 어떤 동작을 해도 아무 것도 변하지 않을 겁니다. 왜냐하면 입력에 대한 정의를 하나도 하지 않았기 때문입니다.


ScrollViewer Inputs


IScrollInfo 의 일부 메서드는 ScrollViewer 에 입력이 들어 왔을 때 어떤 동작을 수행해야 하는지를 결정합니다.


예를 들어 오른쪽에 있는 Vertical Scroll 영역의 썸 이외의 부분을 클릭하면 PageDown() 메서드가 호출됩니다. 



이제 PageDown() 메서드에서 적절한 동작을 해 주시면 됩니다. 예를 들어 다음과 같이 계산하는 것이 가능합니다.



즉 전체 ExtentHeight ViewportHeight 크기로 분할했을 때의 시작 위치를 지정하면 됩니다. 하지만 안타깝게도 균등 분할이 될 수 없으므로, 시작 위치는 반드시 0 이어야 하고 마지막 위치는 반드시 ExtentHeight - ViewportHeight 여야겠죠.


위는 단지 예일 뿐입니다. PageDown() 으로 이동해야 할 크기를 정해 놓고 사용할 수도 있고 썸을 제외한 나머지 부분을 균등분할해서 크기를 결정할 수도 있겠죠.



원래 PageDown() 내에서 VerticalOffset 을 결정할 수 있겠지만, 이런 메서드는 매우 많습니다. LineLeft/Right/Up/Down(), MouseWheelLeft/Right/Up/Down(), PageLeft/Right/Up/Down() 등의 메서드가 존재합니다. 그런데 이런 계산을 할 때마다 예외처리하는 것이 불편하기 때문에 SetVerticalOffset() 과 SetHorizontalOffset() 을 사용해서 최종적인 예외 처리 및 위치 결정을 수행합니다.


여기까지 하면 스크롤 바를 눌렀을 때 썸이 이동하는 것을 확인할 수 있습니다.



하지만 칸텐츠가 같이 이동하지 않고 있음을 발견할 수 있습니다. 마지막으로 구현해야 할 것이 하나 남아 있습니다. 실제로 FlowChartView 의 자식인 Canavs 위치를 이동시켜 줘야 합니다. 지금까지는 단지 ScrollViewer 와 관련한 작업만 한 거였습니다. 이것 때문에 저도 당황했었는데요, [ 1 ] 에서 답을 찾을 수 있었습니다.


현재 제가 구현하는 FlowChartView 의 ControlTemplate 에서 Canvas 요소는 다음과 같이 들어 가 있습니다. 그러므로 "PART_NodeViewsContainer" 의 위치를 변경해 주면 됩니다.



SetVerticalOffset() 에서 InvalidateArrange() 를 호출해 주고, 다음과 같이 ArrangeOverride() 에서 위치를 갱신합니다.



제 구현에서는 Canvas 컨테이너의 크기가 중요하지 않으므로 Size 에 0 을 넣었지만, 다른 사람들은 올바른 수치를 넣으면 됩니다. 그리고 스크롤을 했을 때의 칸텐츠 위치는 Viewport 에 대해서 상대적으로 이동해야 하므로 HorizontalOffset VerticalOffset 을 음수값으로 넣고 있습니다.


이제 스크롤링할 때 정상적으로 칸텐츠가 스크롤되는 것을 확인할 수 있습니다.



아! 깜박 잊은 게 하나 있는데요, FlowCharView 를 클릭하면 MakeVisible() 이 호출되면서 원래 위치로 돌아가 버립니다. 그러므로 MakeVisible() 에서도 꼭 InvalidateArrange() 를 호출해 줘야 합니다.



참고자료


[ 1 ] C# WPF Tutorial - Implementing IScrollInfo [Advanced], C#4 ALL.

'Programming > .NET' 카테고리의 다른 글

[ 번역 ] .NET 에서 클래스를 선택할까? 구조체를 선택할까?  (0) 2016.02.12
[ 8 ] Control Template  (0) 2012.10.24
[ 7 ] Style  (0) 2012.10.22
[ 6 ] WPF Content Model  (0) 2012.10.19
[ 5 ] DataTemplate  (0) 2012.10.17
[ 4 ] DataBinding  (0) 2012.10.14
[ 3 ] Dependency property.  (0) 2012.10.11
[ 2 ] XAML  (0) 2012.10.10
[ 1 ] WPF Architecture.  (0) 2012.10.08
[ 6 ] Proerty, indexer, attribute  (0) 2012.10.05

원문 : Choosing Between Class and Struct.

주의 : 번역이 개판이므로 이상하면 원문을 참조하세요.

주의 : 허락받고 번역한 것이 아니므로 언제든 내려갈 수 있습니다.

 

모든 프레임워크 설계자가 설계를 함에 있어서 직면하게 되는 기본적인 결정중 하나는 클래스( 참조형, reference type )로서 타입을 설계할 것이냐 아니면 구조체( 값형, value type )으로서 타입을 설계할 것이냐입니다. 참조형과 값형의 행위의 차이를 잘 이해하는 것은 이 결정을 내리는 데 있어서 핵심적입니다.

 

우리가 고려해야 할 참조형과 값형의 첫 번째 차이는 다음과 같습니다. 참조형은 힙( heap )에 할당되며 garbage-collected 된다는 것입니다. 반면에 값형은 스택( stack )에 생성되거나 그것을 포함하는 타입 내부에 포함( inline in )됩니다. 그리고 값형은 스택이 언와인드( unwind )되거나 그것을 포함하는 타입이 해제될 때 같이 해제됩니다. 그러므로 값형의 할당과 해제는 일반적으로 참조형의 할당과 해제보다는 빠릅니다.

 

다음으로, 참조형 배열은 행 외( out-of-line )에서 할당됩니다. 이는 그 배열의 요소들이 단지 힙에 존재하는 참조형 인스턴스에 대한 참조일 뿐임을 의미합니다. 값형 배열은 인라인( inline )에 할당됩니다. 이는 그 배열의 요소들이 값형에 대한 실제 인스턴스임을 의미합니다. 그러므로 값 형 배열의 할당과 해제는 참조형 배열의 할당과 해제보다 훨씬 빠릅니다. 또한 대부분의 경우에 값형 배열은 더 나은 참조 국부성( locality of reference )을 지닙니다( 역주 : 메모리 주소가 가까워 연산 속도가 빠릅니다 ).

 

다음 차이는 메모리 사용( usage )과 관련이 있습니다. 값형은 참조형이나 값형이 구현하는 인터페이스 중의 하나로 캐스팅될 때 박싱( box )됩니다. 그것들은 다시 값형으로 캐스팅될 때 언박싱( unbox )됩니다. 박싱된 것은 힙에 할당된 오브젝트이며 garbage-collected 됩니다. 너무 많이 박싱과 언박싱을 되풀이하는 것은 힙, garbage collector 에 부정적인 영향을 줄 수 있으며, 극단적으로 응용프로그램의 성능을 저하시킵니다. 반면에 참조형들이 캐스팅될 때는 그러한 박싱이 발생하지 않습니다.

 

다음으로, 참조형 할당은 참조를 복사합니다. 반면에 값형 할당은 전체 값을 복사합니다. 그러므로 큰 참조형에 대한 할당은 큰 값형에 대한 할당보다 빠릅니다.

 

마지막으로, 참조형은 참조로 전달됩니다. 반면에 값형은 값으로 전달됩니다. 참조형 인스턴스에 대한 변경은 그 인스턴스를 가리키는 모든 참조들에 영향을 미칩니다. 값형 인스턴스들은 값으로 전달될 때 복사됩니다. 값형 인스턴스가 변경되면, 그것은 다른 복사본들에 영향을 미치지 않습니다. 복사는 사용자에 의해 명시적으로 이루어지는 것이 아니라 인자로 값이 넘어 가거나 값이 반환될 때 묵시적으로 이루어지기 때문에, 값형이 변경될 수 있도록 하는 것은 많은 사용자들을 혼란스럽게 만들 수 있습니다. 그러므로 값형은 불변성( immutable )을 가져야 합니다.

 

경험적으로 볼 때, 프레임워크 내에 존재하는 대부분의 타입들은 클래스여야 합니다. 그러나 값형의 특징상 구조체를 사용하는 것이 더 적절하게 만드는 특정 상황들이 존재합니다.

 

고려해야 하는 경우 만약 특정 타입의 인스턴스가 작고 보통 빨리 해제되는 경우나 보통 다른 오브젝트에 포함( embedded )되는 경우에는 클래스 대신 구조체를 정의하십시오.

 

피해야 하는 경우 타입이 다음과 같은 특징들을 모두 가지고 있지 않는 한, 구조체를 정의하지 마십시오( 역주 :  ).

    • 논리적으로 기본형( int, double 등 )과 유사하게 단일 값을 표현한다.
    • 인스턴스가 16 바이트 이하의 크기를 가진다.
    • 불변성( immutable )을 가진다.
    • 자주 박싱되지 않아야 할 것이다.

 

다른 경우에는, 타입을 클래스로서 정의해야 합니다.

'Programming > .NET' 카테고리의 다른 글

WPF IScrollInfo  (0) 2019.02.17
[ 8 ] Control Template  (0) 2012.10.24
[ 7 ] Style  (0) 2012.10.22
[ 6 ] WPF Content Model  (0) 2012.10.19
[ 5 ] DataTemplate  (0) 2012.10.17
[ 4 ] DataBinding  (0) 2012.10.14
[ 3 ] Dependency property.  (0) 2012.10.11
[ 2 ] XAML  (0) 2012.10.10
[ 1 ] WPF Architecture.  (0) 2012.10.08
[ 6 ] Proerty, indexer, attribute  (0) 2012.10.05

Control template 과 관련한 내용입니다.


WPF_Control_Template.pdf


'Programming > .NET' 카테고리의 다른 글

WPF IScrollInfo  (0) 2019.02.17
[ 번역 ] .NET 에서 클래스를 선택할까? 구조체를 선택할까?  (0) 2016.02.12
[ 7 ] Style  (0) 2012.10.22
[ 6 ] WPF Content Model  (0) 2012.10.19
[ 5 ] DataTemplate  (0) 2012.10.17
[ 4 ] DataBinding  (0) 2012.10.14
[ 3 ] Dependency property.  (0) 2012.10.11
[ 2 ] XAML  (0) 2012.10.10
[ 1 ] WPF Architecture.  (0) 2012.10.08
[ 6 ] Proerty, indexer, attribute  (0) 2012.10.05

WPF style 에 대한 내용입니다.


WPF_Style.pdf


'Programming > .NET' 카테고리의 다른 글

WPF IScrollInfo  (0) 2019.02.17
[ 번역 ] .NET 에서 클래스를 선택할까? 구조체를 선택할까?  (0) 2016.02.12
[ 8 ] Control Template  (0) 2012.10.24
[ 6 ] WPF Content Model  (0) 2012.10.19
[ 5 ] DataTemplate  (0) 2012.10.17
[ 4 ] DataBinding  (0) 2012.10.14
[ 3 ] Dependency property.  (0) 2012.10.11
[ 2 ] XAML  (0) 2012.10.10
[ 1 ] WPF Architecture.  (0) 2012.10.08
[ 6 ] Proerty, indexer, attribute  (0) 2012.10.05

WPF customization 을 위해서는 반드시 알아야할 content model.



WPF_Content_Model.pdf


'Programming > .NET' 카테고리의 다른 글

WPF IScrollInfo  (0) 2019.02.17
[ 번역 ] .NET 에서 클래스를 선택할까? 구조체를 선택할까?  (0) 2016.02.12
[ 8 ] Control Template  (0) 2012.10.24
[ 7 ] Style  (0) 2012.10.22
[ 5 ] DataTemplate  (0) 2012.10.17
[ 4 ] DataBinding  (0) 2012.10.14
[ 3 ] Dependency property.  (0) 2012.10.11
[ 2 ] XAML  (0) 2012.10.10
[ 1 ] WPF Architecture.  (0) 2012.10.08
[ 6 ] Proerty, indexer, attribute  (0) 2012.10.05

DataTemplate 과 관련한 내용입니다.


WPF_DataTemplate.pdf


'Programming > .NET' 카테고리의 다른 글

WPF IScrollInfo  (0) 2019.02.17
[ 번역 ] .NET 에서 클래스를 선택할까? 구조체를 선택할까?  (0) 2016.02.12
[ 8 ] Control Template  (0) 2012.10.24
[ 7 ] Style  (0) 2012.10.22
[ 6 ] WPF Content Model  (0) 2012.10.19
[ 4 ] DataBinding  (0) 2012.10.14
[ 3 ] Dependency property.  (0) 2012.10.11
[ 2 ] XAML  (0) 2012.10.10
[ 1 ] WPF Architecture.  (0) 2012.10.08
[ 6 ] Proerty, indexer, attribute  (0) 2012.10.05

DataBinding 에 대한 내용을 정리.


WPF_DataBinding.pdf


DataBindingLab.zip


'Programming > .NET' 카테고리의 다른 글

[ 번역 ] .NET 에서 클래스를 선택할까? 구조체를 선택할까?  (0) 2016.02.12
[ 8 ] Control Template  (0) 2012.10.24
[ 7 ] Style  (0) 2012.10.22
[ 6 ] WPF Content Model  (0) 2012.10.19
[ 5 ] DataTemplate  (0) 2012.10.17
[ 3 ] Dependency property.  (0) 2012.10.11
[ 2 ] XAML  (0) 2012.10.10
[ 1 ] WPF Architecture.  (0) 2012.10.08
[ 6 ] Proerty, indexer, attribute  (0) 2012.10.05
[ 5 ] Delegate and event.  (0) 2012.10.02

Dependency property 에 대한 내용입니다.


WPF_DependencyProperty.pdf


'Programming > .NET' 카테고리의 다른 글

[ 8 ] Control Template  (0) 2012.10.24
[ 7 ] Style  (0) 2012.10.22
[ 6 ] WPF Content Model  (0) 2012.10.19
[ 5 ] DataTemplate  (0) 2012.10.17
[ 4 ] DataBinding  (0) 2012.10.14
[ 2 ] XAML  (0) 2012.10.10
[ 1 ] WPF Architecture.  (0) 2012.10.08
[ 6 ] Proerty, indexer, attribute  (0) 2012.10.05
[ 5 ] Delegate and event.  (0) 2012.10.02
[ 4 ] Classes and structs  (0) 2012.09.27

XAML overview 와 compilation.


WPF_XAML.pdf


'Programming > .NET' 카테고리의 다른 글

[ 7 ] Style  (0) 2012.10.22
[ 6 ] WPF Content Model  (0) 2012.10.19
[ 5 ] DataTemplate  (0) 2012.10.17
[ 4 ] DataBinding  (0) 2012.10.14
[ 3 ] Dependency property.  (0) 2012.10.11
[ 1 ] WPF Architecture.  (0) 2012.10.08
[ 6 ] Proerty, indexer, attribute  (0) 2012.10.05
[ 5 ] Delegate and event.  (0) 2012.10.02
[ 4 ] Classes and structs  (0) 2012.09.27
Extension Methods  (0) 2012.09.26

'Programming > .NET' 카테고리의 다른 글

[ 6 ] WPF Content Model  (0) 2012.10.19
[ 5 ] DataTemplate  (0) 2012.10.17
[ 4 ] DataBinding  (0) 2012.10.14
[ 3 ] Dependency property.  (0) 2012.10.11
[ 2 ] XAML  (0) 2012.10.10
[ 6 ] Proerty, indexer, attribute  (0) 2012.10.05
[ 5 ] Delegate and event.  (0) 2012.10.02
[ 4 ] Classes and structs  (0) 2012.09.27
Extension Methods  (0) 2012.09.26
[ 3 ] .NET Garbage Collection.  (0) 2012.09.25

Property, indexer, attribute 에 대해서 MSDN 을 요약하면서 보충한 내용입니다.


CS_PropertyIndexerAttribute.pdf


PropertyIndexerAttribute.zip


'Programming > .NET' 카테고리의 다른 글

[ 5 ] DataTemplate  (0) 2012.10.17
[ 4 ] DataBinding  (0) 2012.10.14
[ 3 ] Dependency property.  (0) 2012.10.11
[ 2 ] XAML  (0) 2012.10.10
[ 1 ] WPF Architecture.  (0) 2012.10.08
[ 5 ] Delegate and event.  (0) 2012.10.02
[ 4 ] Classes and structs  (0) 2012.09.27
Extension Methods  (0) 2012.09.26
[ 3 ] .NET Garbage Collection.  (0) 2012.09.25
[ 2 ] C# Types  (0) 2012.09.25

Delegate 와 event 에 대해 정리한 글입니다.


CS_delegate_event.pdf


DelegateAndEvent.zip


'Programming > .NET' 카테고리의 다른 글

[ 4 ] DataBinding  (0) 2012.10.14
[ 3 ] Dependency property.  (0) 2012.10.11
[ 2 ] XAML  (0) 2012.10.10
[ 1 ] WPF Architecture.  (0) 2012.10.08
[ 6 ] Proerty, indexer, attribute  (0) 2012.10.05
[ 4 ] Classes and structs  (0) 2012.09.27
Extension Methods  (0) 2012.09.26
[ 3 ] .NET Garbage Collection.  (0) 2012.09.25
[ 2 ] C# Types  (0) 2012.09.25
[ 1 ] .NET Framework 4.0 소개.  (0) 2012.09.20

MSDN 의 내용을 요약하면서 보강한 PT 입니다.


http://msdn.microsoft.com/en-us/library/ms173109(v=vs.100).aspx


CS_Class_Structure.pdf


'Programming > .NET' 카테고리의 다른 글

[ 4 ] DataBinding  (0) 2012.10.14
[ 3 ] Dependency property.  (0) 2012.10.11
[ 2 ] XAML  (0) 2012.10.10
[ 1 ] WPF Architecture.  (0) 2012.10.08
[ 6 ] Proerty, indexer, attribute  (0) 2012.10.05
[ 5 ] Delegate and event.  (0) 2012.10.02
Extension Methods  (0) 2012.09.26
[ 3 ] .NET Garbage Collection.  (0) 2012.09.25
[ 2 ] C# Types  (0) 2012.09.25
[ 1 ] .NET Framework 4.0 소개.  (0) 2012.09.20

Googling 을 하다가 난감한 용법을 만나게 되었다.


    void Foo( this MyClass arg );


대체 method 의 parameter 에 this qualifier 를 붙이는 것이 무슨 의미일까 고민하다가, 결국에는 다시 googling 을 했다.

어떤 고마우신 분이 이 주제에 대해서 blogging 을 했고, 이를 Extension Methods 라고 부른다는 것을 알게 되었다.


아래쪽의 예제를 보면 이것이 얼마나 강력한 기능인가를 알 수 있으며, .NET 언어들이 가지는 확장성에 놀라게 된다.


New "Orcas" Language Feature : Extension Methods.


자세한 내용은 위의 링크를 참조하기 바란다. 여기에서는 일부분만 번역하고 요약하도록 하겠다.




Extension Method 란?


Extension method 는 개발자가 현재 존재하는 CLR type 의 public contract 에 새로운 method 를 추가할 수 있도록 해 주는데, 이 때 그것을 sub-classing 하거나 원래 type 을 recompile 할 필요가 없다. Extension method 는 오늘날의 동적 언어들에서 유명하게 지원하는 "duck typing" 의 유연성을 strongly-typed language 의 성능 및 compile-time 유효화와 합쳐질 수 있도록 한다.

Extension Method 는 여러 가지 유용한 시나리오를 가능하게 하며, "Orcas" 릴리즈의 일부로 .NET 과 함께 소개된 LINQ query framework 를 정말 강력하게 만드는데 도움을 준다.


예제


String 변수가 유효한 이메일 주소인지를 확인하고자 한다고 하자. 당신은 아마도 ( static method 를 가진 ) 서로 다른 클래스를 구현하게 될 것이다.


    string email = Request.QueryString["email"];
    if ( EmailValidator.IsValid(email) ){   }


새로운 "extension method"를 사용하면, 유용한 "IsValidEmailAddress()" method 를 String 클래스 자체에 추가할 수 있다. 그리고 코드를 다음과 같이 작성할 수 있다.


    string email = Request.QueryString["email"];
    if ( email.IsValidEmailAddress() ){   }


새로운 IsValidEmailAddress() method 를 현존하는 String type 에 어떻게 추가할까? 우리는 static method 를 포함하는 static class 를 다음과 같이 정의한다.


    public static class ScottGuExtensions
    {
        public static bool IsValidEmailAddress(this string s)
        {
            Regex regex = new Regex(@"^[\w-\.]+@([\w-]+\.)+[\w-]{2,4}$");
            return regex.IsMatch(s);
        }
    }


'Programming > .NET' 카테고리의 다른 글

[ 4 ] DataBinding  (0) 2012.10.14
[ 3 ] Dependency property.  (0) 2012.10.11
[ 2 ] XAML  (0) 2012.10.10
[ 1 ] WPF Architecture.  (0) 2012.10.08
[ 6 ] Proerty, indexer, attribute  (0) 2012.10.05
[ 5 ] Delegate and event.  (0) 2012.10.02
[ 4 ] Classes and structs  (0) 2012.09.27
[ 3 ] .NET Garbage Collection.  (0) 2012.09.25
[ 2 ] C# Types  (0) 2012.09.25
[ 1 ] .NET Framework 4.0 소개.  (0) 2012.09.20

.NET 의 garbage collection 을 정리한 내용입니다. http://msdn.microsoft.com/en-us/library/hh156531.aspx 에 기반하고 있습니다.


NET_Garbage_Collection.pdf


'Programming > .NET' 카테고리의 다른 글

[ 4 ] DataBinding  (0) 2012.10.14
[ 3 ] Dependency property.  (0) 2012.10.11
[ 2 ] XAML  (0) 2012.10.10
[ 1 ] WPF Architecture.  (0) 2012.10.08
[ 6 ] Proerty, indexer, attribute  (0) 2012.10.05
[ 5 ] Delegate and event.  (0) 2012.10.02
[ 4 ] Classes and structs  (0) 2012.09.27
Extension Methods  (0) 2012.09.26
[ 2 ] C# Types  (0) 2012.09.25
[ 1 ] .NET Framework 4.0 소개.  (0) 2012.09.20

CTS( Common Type System ) 와 관련한 내용을 위주로 정리했습니다. MSDN 의 Types section 을 요약하면서 내용을 보충한 것입니다.

CS_Types.pdf

'Programming > .NET' 카테고리의 다른 글

[ 4 ] DataBinding  (0) 2012.10.14
[ 3 ] Dependency property.  (0) 2012.10.11
[ 2 ] XAML  (0) 2012.10.10
[ 1 ] WPF Architecture.  (0) 2012.10.08
[ 6 ] Proerty, indexer, attribute  (0) 2012.10.05
[ 5 ] Delegate and event.  (0) 2012.10.02
[ 4 ] Classes and structs  (0) 2012.09.27
Extension Methods  (0) 2012.09.26
[ 3 ] .NET Garbage Collection.  (0) 2012.09.25
[ 1 ] .NET Framework 4.0 소개.  (0) 2012.09.20

원문 : Introducing the .NET Framework 4.0

주의 : 번역이 개판이므로 반드시 원문을 참조하십시오.

주의 : 가독성을 높이기 위해 잘 알려진 용어나 발음이 유사한 용어는 한글로 표기합니다.

주의 : 허락받고 번역한 것이 아니므로 언제든 내려갈 수 있습니다.


Introducing the .NET Framework 4.0.


Visual Basic 2010 개발자로서, 당신은 응용프로그램을 향상시킬 수 있는 개념과 기술에 대해 이해할 필요가 있다; Microsoft .NET Framework 가 그것이다. .NET Framework( 혹은 단순하게 .NET 이라 부르기도 함 )는 당신이 생성하려고 하는 차세대 응용프로그램을 만들기 위한 기반을 제공한다. 비록 .NET Framework 의 모든 관점에 대해서 다루는 것은 불가능하지만, 이 장에서 당신은 .NET Framework 구조에 대한 기본, 그것이 단순한 platform 이 아닌 이유, 그리고 Base Class Library 및 도구들에 대한 개념에 들을 배우게 된다. 이 장은 이 책의 나머지 부분에서 전반적으로 사용하게 되는 중요한 개념과 기술에 대해서도 소개한다.


What Is the .NET Framework.


Microsoft .NET Framework 은 복잡한 기술인데, 이는 차세대 응용프로그램들을 빌드하고, 실행하고, 관리하기 위한 기반을 제공한다. 레이어를 가지고 표현해 보면, .NET Framework 는 Microsoft Windows 운영 체제와 당신의 응용프로그램 사이에 위치한 레이어이다. .NET 은 platform 이지만, 기술( technology )로서 정의되어 있기도 하다. 왜냐하면 그것은 운영체제와 관련이 있는  라이브러리, 실행 도구, 관계 및 통합과 같은 부분들을 포함하고 있기 때문이다. Microsoft Visual Studio 2010 은 새로운 버전의 .NET Framework 4.0 에 의존한다. Visual Basic 2010, C# 4.0, F# 2010 과 같은 것들은 .NET Framework 에 의존하는 .NET 언어이며, 이들은 .NET Framework 4.0 을 위한 응용프로그램을 빌드할 수 있다. 이 새로운 버전의 기술은 몇 가지 중요한 기능을 소개하는데, 그것들에 대해서는 나중에 설명할 것이다. 이 장에서 당신은 .NET Framework 에서 가장 중요한 기능들에 대해 훓어 볼 것이고, 이를 통해 당신은 Visual Basic 2010 을 사용해서 빌드된 응용프로그램이 빌드되고 실행되는 방법에 대해서 알게 될 것이다.


Where Is the .NET Framework.


Microsoft Visual Studio 2010 을 설치할 때, 설치 프로세스는 .NET Framework 4.0 을 설치한다. .NET 은 %windir%\Microsoft\Framework\4.0 이라는 이름의 폴더에 설치된다. 만약 이 폴더를 Windows Explorer 로 열어 본다면, 당신은 하위 폴더들과 라이브러리들, 그리고 실행 도구들을 찾아볼 수 있다. 대부분의 DLL 라이브러리들은 Base Class Library 를 구성한다. 반면에 대부분의 실행 도구들은 서로 다른 종류의 작업들을 Visual Studio 2010 에 의해 실행된다. 하지만 그것들을 커맨드라인에서 실행할 수도 있다. 이 장의 뒷 부분에서 우리는 Base Class Library 에 대해서 설명하고, 그 도구들에 대한 개관을 제공할 것이다; 지금은 Vbc.exe 라는 이름을 가진 파일의 위치만 알고 있으면 된다. 그 파일은 Visual Basic Compiler 이며 커맨드라인 도구이다. 대부분의 경우에 당신은 직접 Visual Basic Compiler 를 실행할 필요가 없다. 왜냐하면 당신은 Visual Basic 응용프로그램들을 Visual Studio 2010 내부에서 작성하여 빌드할 것이며, IDE 가 당신을 위해서 컴파일러를 실행할 것이기 때문이다. 그러나 당신이 Windows 의 노트패드를 사용해 매우 복잡한 응용프로그램을 만들고 나서 Vbc 를 실행할 수 있다는 것을 언급해둘 필요는 있다. 마지막으로 .NET Framework 4.0 은 Microsoft 로부터 무료로 얻을 수 있다는 것도 언급해 둘 필요가 있다. 이는 Visual Basic 컴파일러도 .NET 과 함께 무료로 제공된다는 것이며, 이는 2002 년에 처음 릴리즈되었던 버전으로부터 이어진 .NET 개발을 특별하게 만들어 주는 철학이다.


The .NET Framework Architecture.


.NET Framework 의 구조를 더 잘 이해하기 위해서는, 그것을 레이어로 형태의 구조로 생각하라. 그림 1.1 은 .NET Framework 4.0 의 구조를 고수준에서 표현한 것을 보여 준다.


그림 1.1 .NET Framework 4.0 구조.


첫 번째 level 은 운영체제이다; .NET 레이어는 시스템과 응용프로그램 사이에 위치한다. 두 번째 level 은 Common Language Runtime( CLR )인데, 이는 대부분의 작업을 처리하는 .NET Framework 의 일부이다. 우리는 이 장의 뒷 부분에서 CLR 에 대해서 논의할 것이다. 다음 level 은 Base Class Library( BCL )인데, 이는 응용프로그램을 생성할 때 당신의 코드와 Visual Basic 에 의해서 사용될 수 있는 모든 .NET 오브젝트들을 제공한다. BCL 은 WPF, Windows Forms, ASP.NET, WCF 등과 같은 응용프로그램을 빌드하면서 사용하는 몇 가지 .NET 기술들에 대한 기반을 제공하기도 한다. 마지막 level 은 이전 레이어들에 의존하는 응용프로그램을 의미한다.


이전 버전과의 차이점.

당신이 Visual Basic 2008 에서 Visual Basic 2010 으로 업그레이드했다면, 가장 큰 차이점은 .NET 4.0 이 standalone infrastructure 라는 것을 깨닫게 된다는 것이다. .NET Framework 3.5 는 이전에 설치된 .NET 2.0 과 .NET 3.0 을 필요로 하는 incremental framework 이었다는 것을 기억할 것이다. 예를 들어 LINQ 는 .NET 3.5 의 일부이지만, WPF 는 .NET 3.0 의 일부이며, Windows Forms 는 .NET 2.0 의 일부이다( 그림 1.2 를 보라 ). .NET 4.0 을 사용하면 이러한 incremental structure 가 사라진다. 그리고 모든 framework, BCL, 그리고 도구들이 새로운 버전의 일부가 된다.


그림 1.2. .NET Framework 3.5 SP1 의 incremental architecture.



BCL 에 의해 노출되는 다양한 framework 들이 이 책에서 나중에 논의되지만, 이 장에서는 라이브러리에 대한 개관을 보게 될 것이고, 그것들이 작동하는 방식과, 당신이 그것을 사용하는 방법에 대해서 이해할 수 있을 것이다. 그러나 BCL 을 테스트해 보기 전에, Common Language Runtime 을 살펴 보자.


The Common Language Runtime.


이름이 의미하고 있듯이, Common Language Runtime 은 모든 .NET 언어들에 대한 공통적인 기반( infrastructure )를 제공한다. 이 기반은 응용프로그램의 실행을 제어할 책임이 있고, 메모리 관리나 시스템 리소스에 대한 접근, 보안 서비스 등과 같은 작업들을 관리할 책임이 있다. 이러한 종류의 공통 기반은 서로 다른 Win32 프로그래밍 언어들과의 차이를 메꾸는 가교 역할을 한다. 왜냐하면 모든 .NET 언어들은 같은 기능을 가지기 때문이다. 더우기 Common Language Runtime 은 응용프로그램이 관리되는( managed ) 환경에서 실행될 수 있도록 해 준다. "관리되는"이라는 용어는 .NET 개발에서 기본적인데, 다음 절에서 설명한다.


Writing Managed Code.


Visual Studio 2010 개발에 대해서 이야기할 때, 더욱 일반적으로는 .NET 개발에 대해 이야기할 때, 당신은 managed code 를 작성하는 것에 대해서 자주 들었을 것이다. 첫 번째 버전의 .NET 이전에( 혹은 아직 .NET 개발 환경이 아닐 때 ), 개발자가 시스템 리소스와 운영 체제와 상호작용하기 위한 책임을 가지는 유일한 사람이었다. 예를 들어 운영 체제의 일부에 접근하거나 오브젝트들을 위한 메모리 할당을 관리하는 것을 고려하는 것은 개발자가 고려해야만 하는 작업이었다. 다르게 표현하면, 응용프로글매은 시스템과 직접적으로 상호작용하지만, 당신이 쉽게 이해할 수 있듯이 이러한 접근은 보안 이슈뿐만 아니라 위험할 수도 있는 피해들 때문에 큰 제약을 가지고 있다. 대신에 .NET Framework 은 관뢰되는 환경을 제공한다. 이는 응용프로그램이 운영체제가 아니라 .NET Framework 과 통신한다는 것을 의미하며, .NET 런타임은 응용프로그램의 실행 뿐만아니라, 메모리 관리, 리소스 관리, 시스템 리소스들에 대한 접근까지 관리할 책임이 있다. 예를 들어 Common Language Runtime 은 만약 응용프로그램이 .NET 보안 영역에 따라 완전히 신뢰되는( full-trusted ) 것으로 간주되지 않으면, 그것이 특정 시스템 리소스에 접근하는 것을 방지할 수 있다.


시스템에 연결.

당신은 여전히 운영체제와 직접적으로 상호작용할 수 있다. 예를 들어 Windows API 를 실행하는 것이다( 이는 Platform Invoke 나 P/Invoke 라고 알려져 있기도 하다 ).  이 기술은 엄격히 요구될 때만 사용될 수 있는 비관리 코드를 작성하는 것으로 알려져 있다.이 주제는 49 장의 "Platform Invokes and Interoperability with the COM Architecture" 에서 논의된다.


관리 코드의 작성과 Common Language Runtime 의 존재는 응용프로그램이 컴파일러에 의해 생성되는 방식에도 영향을 미친다.


.NET Assemblies.


Visual Basic 6 나 Visual C++ 과 같은 전통적인 Win32 개발 환경에서, 당신의 소스 코드는 컴파일러에 의해서 분석되는데, 그것은 이진 실행 파일들을 생성한다. 그 파일들은 운영체제에 의해 직접적으로 해석되고 실행될 수 있다. 실제로 Visual Basic 6 와 C++ 에 의해서 빌드된 Win32 응용프로그램은 런타임을 사용하지만, 다른 프로그래밍 언어를 사용해서 개발된 응용프로그램을 가지고 있다면, 적절한 런타임을 설치해야만 한다. .NET 개발에서는 모든 것이 매우 다르다. 당신이 응용프로그램을 개발하는 데 사용하고 있는 .NET 언어가 무엇이든 간에, 컴파일러는 어셈블리( assembly )를 생성한다. 이는 .NET 실행 코드를 포함하고 있으며, 두 종류의 필수 요소로 구성된다 : MSIL 코드와 메타데이터( metadata ). MSIL 은 Microsoft Intermediate Language 이다. 이는 개체지향적이며, ( CPU 의존적인 명령어 집합을 구현하는 실행파일을 빌드하기 보다는 ) CPU 독리적인 명령어 집합을 제공하는 고수준 어셈블리 프로그래밍 언어이다. MSIL 은 서로 다른 .NET 언어로 작성된 같은 프로그래밍 작업들이 같은 IL 코드를 생성한다는 의미의 공통 언어이다. 메타데이터는 코드 내에 구현된 타입들과 관련된 정보 집합이다. 그러한 정보는 서명( signature ), 함수, 프로시저, 타입의 멤버, 외부에서 참조되는 타입의 멤버들을 포함할 수 있다. 기본적으로 메타데이터의 목적은 .NET Framework 에 대한 코드를 기술하는데 있다. 어셈블리가 .exe 확장자를 가질 수 있음에도 불구하고, 앞에서 언급한 구조 때문에 그것은 운영체제에 의해 직접적으로 실행될 수 없다. 사실 당신이 .NET 응용프로그램을 실행할 때 운영체제는 그것을 .NET 어셈블리로 인식하고( 왜냐하면 .NET 과 Windows 사이에는 엄격한 협력이 존재하기 때문이다 ), Just-In-Time 컴파일러를 실행한다.


The execution Process and the Just-In-Time ( JIT ) Compiler.


.NET 컴파일러들은 IL 코드와 메타데이터를 포함하는 어셈블리들을 생성한다. 실행을 위해 어셈블리를 시작( launch )하면, .NET Framework 은 모든 정보를 패키징( package )하며 그것들을 운영체제가 이해하고 실행할 수 있는 실행파일로 번역한다. 이 작업은 Just-In-Time( JIT ) 컴파일러가 책임진다. JIT 는 코드를 실행 전에 실시간에( on-the-fly ) 컴팡리하며, 컴팡리된 코드를 실행할 수 있는 상태로 유지시킨다. 그것은 method level 에서 동작한다. 이는 그 코드가 실행되기 전에 응용프로그램의 진입점( 보통 Sub Main )을 먼저 찾은 다음에, 진입점에 의해서 참조되거나 실행되는 다른 프로시저나 함수들( .NET 용어로는 메서드들 )을 컴파일한다는 것을 의미한다. 만약 외부 어셈블리에 정의된 코드를 가지고 있다면, 그 메서드가 실행되기 전에 JIT 컴파일러가 어셈블리를 메모리에 로드한 다음에 코드를 컴파일한다. 물론 외부 어셈블리를 메모리에 로딩하는 것은 시간이 걸리는 작업이며 성능에 영향을 미치지만, 좀처럼 거의 사용하지 않는 메서드들을 외부 어셈블리에 배치하는 것은 좋은 아이디어일 수 있으며, 비슷한 방식으로 거의 사용하지 않는 코드들을 독립된 메서드들에 배치하는 것도 좋은 아이디어일 수 있다.


The Base Class Library.


.NET Framework 의 Base Class Library( BCL )는 수 천개의 재사용 가능한 타입( type )들을 제공하는데, 당신은 그것들을 당신의 코드에서 사용할 수 있으며, 그것들은 Windows Presentation Foundation, ASP.NET, LINQ 등과 같은 모든 .NET 기술들을 다루고 있다. Base Class Library 에서 정의된 타입들은 비관리 코드와 Windows APIs 를 호출하지 않고, 외부 컴포넌트에 대한 의존없이 수백만개의 일을 할 수 있도록 해 준다. 타입은 오브젝트가 표현해야 하는 것이 무엇인지를 진술하는 것이다. 예를 들어 String 과 Integer 는 타입이다. 그리고 당신은 String 타입의 변수( 즉 텍스트 메시지 )를 가지거나, Integer 타입의 변수( 즉 숫자 )를 가질 수 있다. 타입은 Class 와는 다르다. 사실 타입은 두 종류이다 : 참조형( reference type )과 값형( value type ). 이 주제는 4장의 "Data Types and Expressions"에서 다룬다 - 클래스는 단지 참조형일 뿐이다. BCL 에서 타입들은 네임스페이스( namespace ) 내에 들어가 있는데, 네임스페이스는 타입들의 컨테이너처럼 동작하고, 그것의 이름은 그것들이 가리키고 있는 기술과 엄밀한 관련이 있다. 예를 들어 System.Windows.Forms 네임스페이스는 Windows Forms 응용프로그램을 사용해 작업하기 위한 타입들을 구현하며, System.Web 은 Web 응용프로그램을 사용해 작업하기 위한 타입을 구현하는 식이다. 3장 "The Anatomy of a Visual Basic Project" 와 9장 "Organizing Types Within Namespaces" 에서 더욱 세부적인 네임스페이스에 대한 설명을 찾아볼 수 있다. 기본적으로 System 으로 시작하고 있는 네임스페이스의 이름은 BCL 의 일부이다. Microsoft 라고 시작하는 이름을 가진 일부 네임스페이스들이 있는데, 그것들도 BCL 의 일부이다. 이러한 네임스페이스들은 ( 코드 생성과 같은 ) 특별한 시나리오에서 그것들을 당신의 코드에서 사용할 수 있기는 하지만, 보통의 경우에는 Visual Studio 개발 환경과 Visual Basic 컴파일러에 의해서 사용된다. 


BCL 은 몇 개의 어셈블리로 구성된다. 가장 중요한 것은 MsCorlib.dll( Microsoft Core library )인데, 그것은 .NET Framework 의 일부이며, 당신의 프로젝트에서 항상 요구될 것이다. 다른 어셈블리들은 특정 기술에 따라 자주 사용될 수도 있다; 예를 들어 System.ServiceModel.dll 어셈블리는 BCL 을 Windows Communication Foundation main infrastructure 와 통합한다. 또한 어떤 네임스페이스는 다른 기술을 위한 infrastructure 를 제공하지 않으며, 그것들은 특별한 시나리오에서만 사용된다; 결국 그것들은 MsCorlib( Microsoft Core Library )의 외부 어셈블리에서 정의된다. 이러한 모든 어셈블리들과 네임스페이스들은 적절한 장에서 소개될 것이다.


.NET Language.


Microsoft 는 .NET Framework 4.0 을 위한 몇 개의 프로그래밍 언어를 제공한다. Visual Studio 2010 을 사용해, 당신은 다음과 같은 통합된 프로그래밍 언어들을 사용해 응용프로그램을 개발할 수 있다 :

  • Visual Basic 2010.
  • Visual C# 4.
  • Visual F# 2010.
  • Visual C++ 2010.

Visual J# 은 더이상 .NET Framework 패밀리의 일부가 아니다. 당신의 Phython 과 Ruby 와 같은 동적 언어들에 대한 Microsoft 식의 구현을 사용해 네이티브 언어들을 통합할 수도 있는데, 그것들은 각각 IronPython 과 IronRuby 로 알려져 있다.


IronPython 과 IronRuby 는 어디에 있는가?

IronPython 과 IronRuby 는 현재 Microsoft 에서 개발중이며, CodePlex 커뮤니티의 오픈소스 프로젝트로서 이용가능하다. 당신은 IronPython 을 http://ironpython.codeplex.com 에서 받을 수 있다. 당신은 IronRuby 를 http://ironruby.codeplex.com 에서 찾을 수 있다.


Fortran, Forth, Pascal 과 같은 유명한 프로그래밍 언어의 .NET 을 위한 서드파티( third-party ) 구현들도 있느데, 이것들에 대해 논의하는 것은 이는 이 장이나 이 책의 목적이 아니다. 하지만 이 언어들이 .NET Framework base class library 의 이점 및 VB 나 C# 과 같은 infrastructure 를 취한다는 것을 아는 것은 중요하다. 이는 Common Language Runtime 이 모든 .NET 프로그래밍 언어들을 위한 공통 기반을 제공하고 있기 때문에 가능하다.


.NET Framework Tools.


.NET Framework 은 몇 개의 커맨드라인 도구들을 제공하는데, 이것들은 응용프로그램을 생성하는데 필요하다. 그 도구들 중에 는 Vbc.exe( Visual Basic Compiler ), Csc.exe( Visual C# compiler ), MSBuild.exe( the build engine for Visual Studio )와 같은 컴파일러들이 있다. 이러한 모든 도구들은 C:\Windows\Microsoft.NET\Framework\v4.0 폴더에 저장되어 있다. 대부분의 경우에, 당신은 직접 .NET Framework 도구들을 실행할 필요는 없다. 왜냐하면 당신은 Microsoft Visual Studio 2010 Integrated Development Environment 를 사용해서 작업을 할 거이고, 이는 필요할 때 적절한 도구를 실행해 줄 책임이 있기 때문이다. 우리가 아직 어떤 주제들에 대해서 이야기하지 않았기 때문에, 여기에서 모든 도구들을 나열하지는 않겠다. Visual Studio 에 의해 실행되는 .NET 도구들에 대한 정보에 대해서는 특정 도구들을 포함하는 특별한 주제를 논의할 때 이야기하는 것으로 한다.


Windows Software Development Kit.


Visual Studio 2008 부터, 설치 프로세스는 당신의 컴퓨터에 .NET Framework 와 개발 환경과 함께 Windows SDK 도 설치할 것이다. 이 software development kit 은 부가적인 도구들과 라이브러리들을 제공하는데, 이것들은 .NET Framework 을 위한 응용프로그램을 개발하는데 유용하다. 이전 버전의 .NET Framework 과 Microsoft Windows 운영체제에서는 당신이 두 개의 패키지를 설치해야만 했고, 예전에는 .NET Framework SDK 와 Microsoft Platform SDK 라고 불렸었다. Windows Vista 가 소개되면서, .NET Framework 은 운영체제의 코어중 일부가 되었다; Microsoft 는 Windows SDK 를 릴리즈했는데, 그것은 관리 및 비관리 응용프로그램 모두를 빌드하는데 사용되는 도구들을 제공한다. Windows SDK 는 C:\Program Files\Microsoft SDKs\Windows\v7.0A 폴더에 설치되는데, 이는 배포( deployment ), 코드 분석, Windows Communication Foundation 프로젝트를 위한 프락시( proxy ) 클래스 생성과 같은 어셈블리들을 빌드하는 작업들을 위해 Microsoft Visual Studio 에 의해서 사용되는 부가적인 도구들을 포함하고 있다. 또한 이 경우에도 당신은 이들 도구를 직접 실행할 필요가 없다. 왜냐하면 Visual Studio 가 당신을 위해서 이를 처리해 줄 것이기 때문이다. 적절한 장에서 Windows SDK 의 도구들에 대한 정보를 찾아볼 수 있다.


What's New in .NET Framework 4.0.


만약 당신이 .NET Framework 3.5 를 사용한 개발 경험을 가지고 있다면, 그것이 incremental architecture 를 가지고 있다는 것을 알고 있을 것이다. 이는 ( LINQ 와 같은 이 버전의 전통적인 기술들을 포함한 ) .NET 3.5 가 Windows Forms 와 같은 핵심 .NET 기능 및 기술들을 위해서 .NET 2.0 에 의존한다는 것을 의미한다. 반면에 Windows Presentation Foundation, Windows Workflow Foundation, CardSpace 등과 같은 framework 을 위해서는 .NET Framework 3.0 을 요구한다. 이는 .NET Framework 3.5 가 이전 버전이 prerequisite 로서 설치되어 있을 것을 요구한다는 것을 의미한다. .NET Framework 4.0 은 완전히 독립적인 기술이며, 이는 다른 버전이 설치될 것을 요구하지 않는다. .NET Framework 3.0, 3.5 에 대한 지식을 가지고 있다고 가정하고, 당신의 편의를 위해 .NET 4.5 에서 새롭게 추가된 기능을 정리했다 :

  • Windows Presentation Foundation.
  • Windows Communication Foundation.
  • ASP.NET( 이제 Ajax 와 MVC 를 포함 ).
  • ADO.NET Entity Framework.
  • Visual Studio Tools for Office.
  • Windows Workflow Foundation.

이 새로운 버전의 기술들은 단지 부가적인 기능을 추가한 것뿐만 아니라, 구조가 변경되고 개선되었다. .NET Framework 4.0 은 이전 버전에서 직접 설치해야만 했거나 .NET 3.5 Service Pack 1 의 일부였던 framework 들도 포함하고 있다 :

  • ADO.NET Data Services.
  • Parallel Extensions for the Task Parallel Library, or TPL for shot( related to the parallel computing ).
  • Code Contracts.

Windows Forms 기술은 여전히 .NET Framework 2.0 에 있다. 거기에는 얼마 안 되는 부가적인 사용자 컨트롤( user control )들만 있으며, 그것들은 30 장의 "Creating Windows Forms 4.0 Application" 에서 논의된다.


Summary.


.NET Framework 을 이해하는 것은 Visual Basic 2010 을 사용하여 응용프로그램을 개발하는데 있어서 매우 중요하다. 왜냐하면 당신은 .NET Framework 을 위한 응용프로그램을 빌드할 것이기 때문이다. 이 장은 Common Language Runtime 과 Base Class Library, 그리고 응용프로그램이 컴파일되고 실행되는 방식과 같은 .NET Framework 4.0 의 고수준 개관 및 핵심 개념들을 제공했다. 또한 가장 중요한 커맨드라인 도구들과 .NET 언어들에 대한 개관도 제공했다.


'Programming > .NET' 카테고리의 다른 글

[ 4 ] DataBinding  (0) 2012.10.14
[ 3 ] Dependency property.  (0) 2012.10.11
[ 2 ] XAML  (0) 2012.10.10
[ 1 ] WPF Architecture.  (0) 2012.10.08
[ 6 ] Proerty, indexer, attribute  (0) 2012.10.05
[ 5 ] Delegate and event.  (0) 2012.10.02
[ 4 ] Classes and structs  (0) 2012.09.27
Extension Methods  (0) 2012.09.26
[ 3 ] .NET Garbage Collection.  (0) 2012.09.25
[ 2 ] C# Types  (0) 2012.09.25

+ Recent posts