왜 사용자 / 필기 코드가 최소이고 XAML에서 모든 작업을 수행합니까?

MVVM 커뮤니티는 90 년대 OO 프로그래머와 같이 지나치게 열중하고 있다고 느낍니다. MVVM은 코드가없는 동의어입니다. 내에서 폐쇄 StackOverflow의 질문 :

여러 번 나는 코드 숨김 대신 XAML에서 동등한 작업을 시도하는 누군가에 대한 게시물을 보았습니다. 그들의 유일한 이유는 코드를 '깨끗'하게 유지하기를 원하기 때문입니다. 내가 틀렸다면 정정하되, 그렇지 않은 경우 :

XAML도 BAML로 컴파일 된 다음 런타임에 코드로 구문 분석해야합니다. XAML은 컴파일 타임에 잘못된 철자가 아닌 컴파일러에서 선택하지 않으므로 런타임 버그가 더 많을 수 있습니다. 이러한 버그는 디버그하기도 더 어렵습니다. InitializeComponent ()와 같은 코드가 이미 있습니다. 숨겨져 있지만 실행되고 파일에있는 .gics 파일에는 많은 코드가 포함되어 있습니다. 순전히 심리적인가요? 나는 웹 배경에서 왔고 코드가 아닌 마크 업을 좋아하는 개발자라고 생각합니다.

편집 : XAML 대신 코드 뒤에 제안하지 않습니다-둘 다 사용하십시오-XAML에서도 바인딩을 선호합니다-WPF 응용 프로그램에서 esp 뒤에 코드를 작성하지 않도록 모든 노력을 기울이지 않습니다-그것은 융합되어야합니다 둘 다 최대한 활용하십시오.

업데이트 : Microsoft의 아이디어조차 아닙니다 .MSDN의 모든 예제는 두 가지 모두에서 어떻게 할 수 있는지 보여줍니다.

XAML에 모든 것을 넣을 것을 제안하는 사람은 들어 본 적이 없습니다.

실제로, 그것은 끔찍한 아이디어 일 것입니다. IMO.

역사적으로 문제는 코드에 로직이없는 Winforms 앱에서 비롯된 것이 었습니다 . 로직 이기 때문 입니다. 그것이 바로 VM의 중요성에서 비롯된 것입니다. 뷰를 모델에 묶는 부품을 분리 할 수 ​​있습니다.

따라서보기는 가장 잘하는 것, 즉 UI 만 처리합니다.

이제 UI에 코드가 필요한 상황이 발생하면 반드시 코드를 작성하여 코드 뒤에 넣으십시오. 그러나 시나리오의 95 %에 대해 마크 업 파일에 UI를 남겨 두는 것이 가장 좋을 것입니다. 코드가 약간 필요한 경우 아마도 작성하려는 논리 일 것입니다. 뷰 모델에 더 적합합니다. 이에 대한 예외는 행동과 같은 것들이지만, 그들은 완전히 별개의 동물이며 특별한 장소가 필요합니다 (즉, 코드 뒤에 있지 않음).

질문에 직접 대답하고 모든 코드에서 코드 숨김 (비주얼 컨트롤 클래스에있는 코드)을 참조한다고 "코드"라고 가정하면 사용자 인터페이스가 완전히 구현 될 수 있기 때문입니다. 단 하나의 기술 만 사용하여 Blend에서 조작합니다. UX 디자이너는 개발자가 아니고 코드 작업을 원하지 않으며 코딩 전문가가 아닌 레이아웃 및 XAML 전문가라고 가정합니다. 코드 숨김없이 모든 것을 구현하면 이러한 종류의 디자이너에게 완전히 언어로 작동하는 데 필요한 도구를 제공 할 수 있습니다.

명령형 프로그래밍과 선언적 디자인을 명확하게 분리합니다.

Silverlight 및 WPF에 "동작"이 존재하는 이유는 코드 비하인드에 일부 코드를 넣지 않고 자체적으로 재사용 할 수있는 작은 모듈입니다. 그렇게하면 Blend가 말 그대로 컨트롤에 끌어서 놓을 수 있다는 이점이 있습니다. 이제 XAML 컨트롤에 일회성 이동 부품을 사용하는 대신 이동 부품을 디자이너 도구를 사용하여 조작 할 수있는 멋진 컨테이너로 추상화했습니다.

필자의 경험에 따르면 XAML 트리거에서 복잡한 논리를 사용하여 코드 숨김 상태를 유지하려고 시도하는 경우가 종종 있습니다. -모델.

xaml에서 가능한 모든 작업을 수행 할 때 얻을 수있는 가장 큰 장점 중 하나는 모든 동작을 한 곳에 유지한다는 것입니다. 개발자가 xaml과 코드 사이를 이동해야 할 때마다 이해하기가 더 어려워집니다.

저는 WPF 팀에서 코드 숨김을 우선시하지 않았습니다. 일부 이벤트 핸들러가 컨트롤을 조작하고 있기 때문에 디버깅이 훨씬 어려웠던 경우가 몇 번 이상 있었으며 동작이 두 파일로 흩어져 있기 때문에 즉시 명확하지 않았습니다.

즉, 때로는 디자인 원칙을 타협하는 것이 더 낫다고 생각할 권리가 있다고 생각합니다. xaml에서는 일부 작업을 수행하기가 매우 어렵습니다. 코드 숨김을 사용하여 훨씬 적은 시간에 수행 할 수있는 xaml에서 작동하는 동작을 얻으려고 몇 시간 또는 며칠을 보냈습니다. 코드 비하인드를 최후의 수단으로 취급하려고 왔지만 절대로 사용해서는 안된다고 누군가에게 말하지 않았습니다. 훌륭한 엔지니어가 이해해야 할 또 하나의 트레이드 오프입니다.

편집 : 의견에서 내 게시물이 xaml에 대해 논쟁하는 것으로 해석되는 것처럼 들립니다. 나의 의도는 반대를 주장하는 것이었다. Pure xaml은 모든 동작을 한 곳에 유지하기 때문에 항상 선호됩니다. xaml과 코드 숨김을 혼합하여 복잡하게 만들 수 있으므로 코드 숨김을 최소화하는 것이 이상적입니다. Xaml은 여러 가지 이유로 순수한 코드 숨김보다 선호됩니다. WPF 및 Silverlight는 xaml로 작성되도록 설계되었습니다.

나는 XAML에 대한 피상적 인 지식 만 가지고 있지만 컴파일러가 오타를 감지하지 못한다는 사실에 당황합니다.

기본적인 차이점은 XAML은 선언적 이지만 C #은 필수적입니다.

간단히 말해서:

Pane p = new Pane(200, 100);
Button foo = new Button("foo");
Button bar = new Button("bar");
p.addChild(foo);
p.addChild(bar);

vs.

<Pane width="200" height="100">
    <Button label="foo"/>
    <Button label="bar"/>
<Pane>

상위 코드는 실제로 부작용으로 계층을 생성하는 반면, 하위 코드는 단순히 계층 구조를 선언합니다. 예를 들어 addChild방법의 이름이 변경 될 수 있지만 자식-부모 관계는 의미 론적 모델의 핵심이며 선언적 스 니펫에서와 같이 표시됩니다. 게으른 인스턴스화와 같은 아래에서 완전히 투명하게 많은 최적화를 허용하는 구현과는 거리가 멀습니다.
선언적 프로그래밍에는 많은 장점이 있습니다. 보다 간결하고 표현력이 뛰어나며 모델과 매우 가깝습니다. 나는 그것이 바람직한 한 갈 것입니다.

그러나 이것이 모든 것을 XAML에 펀치하려고 시도한다는 의미는 아닙니다. C #에는 선언적 스타일을 허용하는 많은 고급 구성이 있습니다.

결국, 코드가 짧고 읽기 쉽기를 원합니다. 따라서 C #에서 XAML보다 적은 코드로 동일한 결과를 얻을 수 있다면 C #을 사용하는 것이 논리적입니다. 그러나 XAML 코드는 사용 된 구성 요소의 변경에 덜 취약하여 .NET 프레임 워크를 추상화합니다 (예 : 바인딩 구현 방법에 대한 세부 정보).