XAML 또는 C# 코드백

XAML 또는 C# 코드백

저는 XAML을 사용하는 것을 좋아하지 않습니다. 저는 C#으로 모든 것을 코딩하는 것을 선호하지만, 제가 잘못하고 있다고 생각합니다.

어떤 경우에 XAML을 사용하는 것이 더 좋으며 언제 C#을 사용합니까?당신의 경험은 무엇입니까?

C#에서 전체 창을 만드는 것은 코드의 혼란일 수 있습니다.WPF의 가장 좋은 점은 XAML을 사용하면 설계와 논리를 분리하여 코드를 훨씬 쉽게 읽을 수 있다는 것입니다.

동적 컨트롤을 만들어야 할 때는 C#을 사용하겠지만, 일반 디자인, 정적 스토리보드, 스타일, 데이터 템플릿 등은 XAML에 보관하는 편입니다.

WPF의 MVVM에서 이 비디오를 확인하십시오.XAML, 코드백 및 기타 추상화에 대한 WPF 애플리케이션 구성 방법에 대해 머리를 싸매고 싶다면 여기서 시작하는 것이 좋습니다.

XAML은 분명히 지나칠 수 있습니다. XAML에 정의된 전체 사용자 인터페이스(논리, 이벤트 처리 관계 등)를 원하는 사람들은 아마도 요점을 놓치고 있을 것입니다.

XAML의 목적은 사물이 어떻게 보여야 하는지를 결정하기 위한 공통 형식을 제공하는 것입니다.그것은 단지 어떻게 물건들을 배치하고, 어떻게 색을 칠하고, 어떻게 시각적으로 스타일링하는지에 대한 설명이어야 합니다.

C#은 프로그래밍 기능 - 재사용(유형과 기능 정의), 변수, 절차 프로그래밍, 심지어 선언적 또는 기능 스타일을 참조하는 측면에서 영구적인 헤드스타트를 가지고 있기 때문에 C#의 다른 측면을 대체하려고 시도하는 것은 의미가 거의 없습니다.

개인적으로 저는 Linq 표현과 함께 UI를 만드는 것을 정말 좋아합니다!

궁극적인 부조리는 그들이 워크플로우 작업을 버튼의 자식으로 사용하여 공급한 샘플에 의해 도달했습니다.Click프로그램 전체가 XAML에 있었습니다. "멋진" 것처럼 들리지만, 문제는 그것이 동등한 C#이나 VB보다 훨씬 더 추하고 읽을 수 없다는 것이었습니다.NET 프로그램, 따라서 C#에서 사용할 준비가 된 모든 것은 더 장황하고 박락한 동등한 것으로 대체되어야 합니다.더 추악한 구문으로 이 번역으로 실제로 얻은 것은 아무것도 없습니다. 같은 프로그램일 뿐입니다.XML은 일반 프로그래밍 언어의 구문에 대한 빈약한 기초입니다.great-than 기호는 다음과 같이 써야 한다는 사실에서 시작합니다.>!

병렬 환경에서 Microsoft는 XAML을 완료하기 전에 C# 3.0을 릴리스했습니다. XAML 팀은 XML 대신 C# 3.0 개체/목록 이니셜라이저 구문을 구문으로 채택했습니다.그리고 이 모든 논쟁은 결코 일어나지 않았습니다.

제 경험에 따르면 C#으로 하는 것이 훨씬 빠르지만 대부분의 경우 XAML로 하는 것이 더 빠릅니다. XAML 코드 한 줄을 수행하는 데 C# 코드 5줄이 필요할 때 어느 것이 더 나은지 선택하기가 매우 쉽습니다.

기본적으로 XAML은 시각적 디자인을 표현하기 위한 것이고, C#은 논리를 표현하기 위한 것입니다.

모든 시각적 설계는 XAML로 수행되어야 하며, 모든 논리는 C#로 구현되어야 합니다.

이를 통해 디자이너가 로직 변경에 대한 걱정 없이 재생할 수 있도록 시각적 디자인을 제공하고, 런타임에 느슨한 XAML을 사용하여 전체 시각적 디자인을 대체할 수 있습니다.

이는 또한 논리 또는 시각적 설계를 "파손"하지 않고 교체할 수 있음을 의미합니다.

둘 사이의 연결은 데이터 바인딩과 명령 바인딩으로 수행해야 합니다.

사용하는 방법은 다음과 같습니다.

별도의 C# 코드로 모델(비즈니스 데이터 객체 모델)을 정의합니다.

XAML에서 보기의 일정한 부분(예: 창, 메뉴 등 그래픽 사용자 인터페이스의 일정한 부분)을 정의합니다(이 경우 VS가 아닌 Blend를 사용하는 것이 좋습니다).
여기서 스타일(색상, 글꼴 등)을 정의하지 마십시오.
대부분의 경우 XAML 코드 뒤에 단추에 대한 이벤트 핸들러를 쓰지 말고 명령 바인딩을 대신 사용합니다.

별도의 파일에 있는 XAML "ResourceDictionary"를 사용하여 모델이 뷰(데이터 개체를 보거나 편집하기 위한 GUI)에 표시되는 방법을 정의합니다.

블렌드를 사용하여 쓴 다음 VS를 사용하여 XAML에 바인딩을 추가합니다(Jetbrain의 VS용 Ressharper 추가 기능은 바인딩 표현식에 도움이 됩니다).

디자인 타임 동안 개체 유형을 알 수 없는 경우 "loose-XAML"을 사용하여 다시 컴파일하지 않고 내부에 파일을 추가/편집할 수 있는 폴더에 XAML을 배치할 수 있습니다.

C#에서 모델과 뷰(컨트롤러/뷰 모델) 사이에 다음과 같은 연결을 만듭니다.
필요에 따라 뷰를 작성합니다(동역학 객체에 대해).
뷰를 모델에 바인딩합니다(뷰의 DataSource를 모델 내 관련 개체로 설정).
합니다.
명령 - 뷰를 .

응용 프로그램.xaml서 StartupUri="MainWindow.xaml"은 Startup="ApplicationStartUp"입니다.
Application StartUp() "응용 프로그램 시작"
합니다.

창

모델 및 메인 윈도우에 컨트롤러 연결
창 표시
및주을 모두에 저장)

ResourceDictionary 아래의 별도 XAML 파일에 스타일(색상, 글꼴)을 추가합니다(이 파일에 블렌드 사용 또는 미리 만들어진 XAML 테마/스킨 파일 구입).

당신의 UI를 XAML 대신 C#로 쓰고 싶은 충동은 당신이 XAML에서 얼마나 편안한지를 보여주는 것일 뿐입니다.

저에게 있어서는 코드백을 가능한 한 적게 쓰는 것이 개인적인 목표입니다.간단히 말해, 뒤에 있는 코드는 단위 테스트가 어렵지만 테스트되지 않는 논리를 포함할 수 있습니다.XAML은 선언적(HTML과 유사)이며 논리를 포함하지 않으므로 단위 테스트를 수행할 필요가 없습니다.저는 보기 코드를 XAML로 유지하고 매우 쉽게 테스트할 수 있는 MVVM(View Model)에 보기 로직을 유지합니다.

XAML에 익숙해지면 절차 코드에서 구성 개요에 대한 이점을 더욱 실감할 수 있습니다.MVVM과 같은 패턴을 사용하면 한 걸음 더 나아가 코드백이 드문 경우에만 유용하다는 것을 알게 됩니다.

가장 명심해야 할 것은 XAML이 발표용이라는 것입니다.모든 프레젠테이션은 XAML에 있어야 합니다. 논리가 있다면 XAML에 넣지 마십시오. C#에 입력하십시오.

XAML 파일을 완전히 다르게 생겼지만 여전히 동일한 데이터를 사용하는 파일로 교체하는 것이 바로 이 부서가 있어야 하는 부분이라고 상상해 보십시오.

XAML의 좋은 점 중 하나는 표현과 논리의 분리입니다.이 분리는 이론적일 뿐만 아니라 실용적이기도 합니다.저의 경우, 대부분의 UI는 현재 디자이너가 처리하고 있습니다.이 디자이너는 혼합을 사용하고 C#을 알지 못하며, C#을 배우는 것에 관심이 없으며 솔직히 그럴 필요가 없습니다.이 디자이너는 진정한 디자이너이자 예술가입니다. 이 도구들을 사용하여 물건들을 정말 멋지게 보이게 하는 방법을 알고 있습니다.기본적으로 저의 계통수는 이것입니다. XAML을 많이 사용할수록, 그가 할 수 있기 때문에 UI에서 해야 할 일이 줄어듭니다.이것은 우리에게 잘 작용했습니다.저는 보통 컨트롤을 모양이 나지 않도록 디자인하고, 프릴이 없는 기본 스타일을 제공하며, DataContext를 사용하여 개체를 바인딩합니다(btw DataTrigger는 코드를 줄이는 좋은 방법입니다).결과적으로 코드를 확인하고 다음날 다시 와서 동기화하면 UI가 완전히 다르게 보이지만 모든 것이 작동합니다!!!

물론, 이 모델은 적어도 1년 반이 걸렸지만, 지금은 작동하는 것처럼 보이고 우리의 UI 룩 Kick A##, 우리의 애플리케이션은 높은 평가를 받고 있고, 나는 UI 자체에 대한 작업을 거의 하지 않고 더 멋진 작업을 하게 됩니다.간단히 말하자면, 뒤에 있는 코드는 좀 더 개발자 중심적이고 WPF를 사용하여 이익을 얻고, 노력하고, 생계를 유지할 수 있는 다른 그룹, 즉 디자이너를 잊어버릴 수 있다고 생각합니다.

물론 여전히 개발자가 XAML/WPF를 노래하고 춤추게 하는 데 필요한 경우가 있으며, 때로는 디자이너에게 올바른 방법을 교육해야 하지만 대규모 프로젝트에서 투자가 여러 번 성과를 거둘 가치가 있다고 생각합니다(간단히 말하자면 그렇지 않을 수도 있음).

XAML, MXML은 당신이 평균적인 복잡성을 가진 간단한 UI를 개발하는 한 이 모든 것이 작동합니다.UI가 복잡하고 풍부해지면 자동 데이터 바인딩은 이점보다 더 많은 문제를 일으킬 것입니다.XAML의 목적은 프로그래밍을 쉽게 하는 것이 아니라 UI와 논리를 분리하여 UI의 툴링을 쉽게 할 수 있도록 하는 것입니다.

데이터 바인딩 없음, 이벤트 핸들러 없음... 다시는 XAML을 볼 수 없고 코드를 쓸 수 없다고 가정합니다.

XAML은 프레젠테이션입니다. 데이터 바인딩은 프레젠테이션이 아닙니다. 프레젠테이션 로직입니다.모든 프레젠테이션 로직을 코드 뒤에 배치합니다(데이터 바인딩 및 핸들러).개발자는 뒤에 있는 코드를, 디자이너는 뒤에 있는 XAML을 소유합니다. 만약 당신이 개발자이고 당신이 XAML을 만지고 있다면, 그 부분을 뒤에 있는 코드로 이동하세요.

우리는 또한 XAML 없이 WPF 앱을 작성할 수 있습니다.

Vinoth Kumar R에게 감사합니다(Flex MXML 데이터 바인딩을 충분히 사용했습니다).

이것은 여러분뿐만 아니라 여러분의 팀에 관한 것이기도 합니다. 그들 중 일부는 디자이너일 수도 있습니다.

XAML과 C#은 이미 설명한 바와 같이 설계에서 논리를 분리할 수 있는 정말 좋은 방법입니다.

일반적인 프로그래머의 경우 프로그래머가 C++, VB, WinForms, ATL 및 MFC 배경에서 왔다고 가정할 때 WPF를 사용하여 프로그래밍 방식을 변경합니다. 이 배경은 UI가 XAML 및 C#과 같이 논리에서 자연스럽게 분리되지 않은 배경입니다.

이런 프로그래밍 방식에 익숙해지려면 시간이 좀 걸리지만, 점점 더 많은 경험을 쌓으면 정말 효과적입니다.

시작하기 전에 MVVM 패턴을 배우고 패턴의 강도를 이해하고 그 이점을 이해하기 위해 자습서를 실행하는 것이 좋습니다.

MVVM 패턴을 기반으로 하는 WPF 및 C# 애플리케이션의 이점:

사용자 경험 및 사용성 UI에서 논리를 분리하면 UI 디자인 및 애니메이션 작업을 전담 디자이너가 수행하는 것이 더 자연스럽습니다.그런 식으로 프로그래머는 설계를 아는 사람이 UI를 설계하는 동안 이면의 논리와 기술 솔루션에 초점을 맞출 수 있습니다.이는 많은 소프트웨어 회사들에게 문제가 되었습니다. 적어도 업계에서는 프로그래머가 실제로 UI를 설계하고 많은 지원, 유지보수 및 비효율적인 애플리케이션을 초래했습니다.

사용성 배경을 가진 사람이 기술 솔루션 대신 사용에 초점을 맞추면 사용자 친화적인 응용 프로그램이 될 가능성이 높습니다.그런 예들에 대한 매우 흥미로운 책이 있습니다. Joel Spolsky의 프로그래머를 위한 사용자 인터페이스 디자인입니다.

XAML 애플리케이션에 MVVM 패턴을 사용하면 더 많은 사용자 친화적인 애플리케이션을 볼 수 있을 것입니다.

유지보수는 소프트웨어 개발에 많은 비용이 듭니다.MVVM 패턴은 처음에는 큰 오버헤드이지만, 기능이 추가되고 복잡하고 고급화된 애플리케이션일수록 더 많은 이점을 얻을 수 있습니다.이러한 응용 프로그램을 유지 관리하는 것이 정말 쉽다는 것을 알게 될 것입니다.개요를 보려면 이 비디오를 살펴보십시오.

역량의 혼합 더 나은 결과를 얻기 위해 팀에서 일하는 전담 디자이너와 전담 프로그래머는 역량을 혼합하는 매우 좋은 방법입니다.프로그래머만 고용하는 대신 조직은 최고의 결과를 제공하기 위해 역량을 결합해야 합니다.

디자인에 관심이 있는 프로그래머를 위한 기회 마지막으로 Windows 환경에서 고급 응용 프로그램을 구현할 수 있습니다.만약 당신이 디자인에 관심이 있는 프로그래머라면, Microsoft Expression Blend는 멋진 디자인으로 멋지고 유용한 응용 프로그램을 배우고 얻을 수 있는 기회를 정말로 열어줍니다.

XAML 및 C#, MVVM과 함께 사용할 경우 위험이 있을 수 있지만, 이를 통해 제공되는 뛰어난 가능성과 유연성도 단점으로 작용할 수 있습니다.프로그래머가 이 새로운 쉬운 UI 환경을 자유롭게 사용할 수 있게 되면, 애플리케이션은 이 새로운 환경에서 제공하는 애니메이션, 색상 및 모든 것의 광범위한 스펙트럼을 갖게 될 수 있습니다.C++ 및 ATL 환경에서 UI 컨트롤을 추가한 방법을 기억합니다.

그래도 장점은 더 많고 UI에 C# 대신 XAML을 사용할 수 있는 영감을 얻었으면 좋겠습니다. 익숙해지면 마음에 들 것이라고 확신합니다.

우수한 튜토리얼 링크:자습서 MVVM XAMLC#

저는 원래 개발 웹사이트에서 왔고 현재 WPF/Silverlight를 배우고 있습니다.XAML 모델은 WinForms보다 훨씬 더 의미가 있습니다.저는 XAML을 HTML로 처리하고 .cs 파일을 코드백처럼 처리합니다.

저는 깨끗한 코드를 좋아합니다. 코드가 적을수록 더 깨끗합니다.코드는 수백만 가지 방법으로 작성될 수 있습니다. XAML은 더 제한적입니다. XAML은 코드를 잘 잘라냅니다.XAML에 넣을 수 있다면 그렇게 하겠습니다.도구는 XAML을 읽고 관련 작업을 수행할 수 있습니다.코드는 더 말할 것도 없습니다.XAML을 처리하는 도구와 프레임워크는 진화하고 개선되어 기존 XAML과 더 많은 작업을 수행할 것입니다. 코드에 대해서는 말할 수 없습니다.XAML이 진화할수록 애플리케이션을 선언적으로 정의할 수 있습니다.

저에게 XAML을 사용하는 것은 LINQ를 사용하는 것과 같습니다.내가 읽기 쉬운 한 줄짜리 성명서를 쓸 수 있고, 내가 원하는 것을 실행할 수 있는 가장 좋은 방법을 프레임워크가 결정하도록 할 수 있다면, 나는 기분이 좋습니다.저는 제가 원하는 방식을 하드 코딩하는 대신 제가 원하는 것을 선언하는 것을 사용하려고 노력합니다.F#는 이 패러다임의 또 다른 좋은 예입니다.

컴퓨터 프로그래밍에서 사용하는 프로그래밍 언어에 관계없이 모든 논리는 코드로 되어 있어야 합니다. XAML은 ControlTemplate에서도 이를 대체하지 않아야 합니다. 비록 그것이 좋지만 그것은 테스트와 디버그 코드를 단위화하는 것이 훨씬 더 쉽습니다.

중요한 점에 대해 언급된 답은 아직 없는 것 같습니다. https://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh465340.aspx

XAML은 절차 코드일 뿐입니다(더 쉬울 뿐입니다).

<Grid x:Name="ContentPanel" Margin="12,0,12,0">
    <Button Height="72" Width="160" Content="Click Me" />
</Grid>

"다음은 이 XAML이 C# 또는 Visual Basic으로 작성된 코드로 부분적으로 대체될 수 있는 방법을 보여줍니다."

// Initialize the button
Button myButton = new Button();
// Set its properties
myButton.Width = 160;
myButton.Height = 72;
myButton.Content = "Click Me";
// Attach it to the visual tree, specifically as a child of
// a Grid object (named 'ContentPanel') that already exists. In other words, position
// the button in the UI.
ContentPanel.Children.Add(myButton);

예를 들어 Windows 양식을 사용한 경우 Windows 양식 설계자가 위 링크의 예제와 유사한 코드를 포함하는 .designer.cs 파일을 생성한다는 것을 기억할 수 있습니다.그런 종류의 선언 코드는 C#보다 XAML로 훨씬 더 잘 표현됩니다.

장난감이 아닌 애플리케이션의 경우 항상 XAML을 선호하여 UI를 정의하고 MVVM 방식으로 논리에 연결해야 합니다.

일부 항목은 코드에서 유지 관리하거나 디버그하기가 더 쉽습니다.

Xaml2009에서 현재 코드로 수행해야 하는 작업을 더 많이 수행할 수 있다는 것은 말할 것도 없습니다.

안타깝게도 BAML은 2010년과 비교하여 2009년 xaml을 완전히 지원하지 않으므로 2010년 xaml을 컴파일할 수 없습니다.그리고 최신 버전의 블렌드가 전체 개발 설계 루프를 수행할 때까지 기다려야 합니다.(3보다 이후)

더글러스

XAML은 구조와 설계에 사용되는 XHTML과 CSS 또는 XML과 XSL의 조합과 유사하다고 볼 수 있습니다.논리의 모든 형식은 C#이어야 합니다.이러한 방식으로 구조와 설계는 논리와 분리됩니다.코드도 이 접근 방식을 사용하여 더 깨끗해야 합니다.또 다른 긍정적인 점은 작업이 디자이너와 프로그래머 사이에서 더 쉽게 분리될 수 있다는 것입니다.

한 가지 더...MSDN의 XAML 정의는 다음과 같습니다.

XAML(Extensible Application Markup Language)은 선언형 응용 프로그램 프로그래밍을 위한 마크업 언어입니다.WPF(Windows Presentation Foundation)는 XAML(Extensible Application Markup Language) 로더를 구현하고 WPF(Windows Presentation Foundation) 유형에 대한 XAML(Extensible Application Markup Language) 언어 지원을 제공하므로 XAML(Extensible Application Markup Language) 마크업에서 대부분의 응용 프로그램 UI를 만들 수 있습니다.또한 SDK에는 XAMLad라는 XAML(Extensible Application Markup Language) 편집 도구가 포함되어 있습니다.이 도구를 사용하여 XAML(Extensible Application Markup Language)을 실시간으로 실험할 수 있습니다.

인용문 링크.

C#에서 WPF를 유창한 스타일로 프로그래밍하면 코드 크기와 복잡성을 줄이는 데 도움이 됩니다.WPF와 함께 유창한 스타일을 사용하는 예는 다음 답변을 참조하십시오.

제가 생각하는 대부분의 선호도입니다.다른 화면을 구성하고 C# 코드 로직을 UI에서 분리하는 것이 더 쉽기 때문에 저는 WPF를 사용합니다.일반적으로 모든 논리는 WPF 또는 Windows Forms의 시작 프로젝트인 UI가 아닌 다른 C# 라이브러리에서 구성됩니다.

언급URL : https://stackoverflow.com/questions/1002604/xaml-or-c-sharp-code-behind