Maui: MVU는 당신이 생각하는 것과 다를 수 있습니다

@aspnetde 에게 감사드립니다. 앞으로 18개월 정도 동안 이 아이디어를 구현하는 작업에

.NET MAUI 가 아직 실제로 빌드 되지 않았기 때문에 .NET MAUI가 MVU인지 아닌지 말하기에는 너무 이르다고 생각합니다. :)

예, 프로토타입이 있습니다. 네, Comet 실험에서 영감을 받았습니다. 그리고 예, 우리는 지금까지 우리가 보여준 것이 MVU에 대한 모든 사람의 정의와 일치하지 않는다는 우려가 있다는 것을 알고 있습니다.

내 희망은 우리가 협력할 수 있다는 것입니다! 우리가 최종적으로 디자인하고 배송하는 것이 다른 라벨을 받을 자격이 있다면, 나는 그것에 하나를 부여해야 한다는 데 동의합니다.

.NET MAUI에서 C# MVU를 어떻게 보게 될까요?

필요하다면 어떤 새로운 언어 기능이 필요할까요?

Fabulous 및/또는 C#과 F# 간에 공통적으로 적용되는 패턴은 무엇이며 무엇이 달라야 합니까? 통합을 고려해야 합니까?

.NET MAUI에서 C# MVU를 어떻게 보게 될까요?

C# MVC 또는 C# MVVM이라는 말을 들어본 적이 있습니까? _Model-View-Update_ aka _The Elm Architecture_는 언어 종속 구현이 아니라 잘 정의된 아키텍처 패턴입니다.

필요하다면 어떤 새로운 언어 기능이 필요할까요?

• 공용체 유형은 메시지 정의를 크게 단순화하는 데 도움이 되지만 인터페이스/추상 클래스 및 메시지당 하위 클래스를 통해 수행할 수 있지만 작성하려면 좀 더 많은 상용구 코드가 필요합니다.
• 메시지를 처리하기 위해 필요하지 않은 경우 패턴 일치가 유용합니다. 메시지의 형태가 단순할 것이기 때문에 C# 스위치 표현식의 현재 상태는 이미 충분하다고 생각합니다.
• 마지막으로 가장 중요한 기능은 기본적으로 불변성이며 구조적 동등성 비교가 가능하다는 것입니다. C# 9(일명 데이터 클래스)의 레코드에 대한 현재 제안을 기억하는 한, 그것들은 정확히 그것을 제공할 것입니다.

따라서 C# 9는 여전히 F#보다 시끄럽지만 현재의 관점에서 보면 좋을 것입니다.

Fabulous 및/또는 C#과 F# 간에 공통적으로 적용되는 패턴은 무엇이며 무엇이 달라야 합니까? 통합을 고려해야 합니까?

위에서 설명한 것처럼 MVU 자체가 아키텍처 스타일 또는 앱 모델이라고 부르는 것과 같이 전체 접근 방식에서 특히 언어별 항목이 없어야 합니다.

@TimLariviere 는 최근 Fabulous를 발전시키기 위한 몇 가지

그건 그렇고: 작년에 XF + C# + MVVM과 XF + F# + MVU를 1:1로 비교했는데 결과는 소스 코드를 포함하여 여기 에서 찾을 수 있습니다.

.NET MAUI가 MVU인지 아닌지 말하기에는 너무 이르다고 생각합니다.

MAUI가 결국 MVU가 될지 여부는 중요하지 않습니다. 커뮤니티에서 이미 많은 혼란을 야기한 발표 블로그의 샘플에 관한 것입니다. 기본적으로 나는 저자가 아직 MVU를 실제로 조사하지 않았다고 가정해야 합니다. "C# MVU"에 대해 이야기한다고 해서 이것이 더 나아지는 것은 아닙니다.

@aspnetde 및 @forki에 동의합니다. 여기서 문제는 커뮤니케이션에 있습니다.

우리 중 누구도 MAUI/XF용 혜성에서 영감을 받은 C# DSL을 삭제하거나 변경해야 한다고 주장하지 않는다고 생각합니다. .

이것은 내가 직접 커뮤니케이션과 문제에 대해 계속해서 질문해 온 것입니다. 아마도 관련된 모든 사람들이 MVVM 및 MVU와 같은 다양한 패턴에 대해 읽어보는 것이 좋을 것 같습니다.

즉, MVVM 위에 MVU를 구현하는 방법도 있지만 어떤 문제를 해결할 것인지는 여전히 의문입니다.

C# MVC 또는 C# MVVM이라는 말을 들어본 적이 있습니까?

예, C# 또는 XAML 뒤에 MVVM 또는 MVU와 같은 아키텍처 패턴이 오는 것이 이상하다는 것을 이해합니다. 내가 이야기하는 더 광범위한 개발자 커뮤니티 중에서 프로젝트 내에서 원하는 수의 조합을 활용할 수 있다는 점을 분명히 해야 합니다. 의도는 "C# MVVM"이 "XAML MVVM"과 구조적으로 다르다고 말하는 것이 아니라 조합이 가능하고 개발자 경험이 전체적으로 약간 다르다는 것입니다.

이 스레드가 .NET MAUI에서 MVU가 어떻게 보이는지 논의할 수 있다고 생각했지만, 여기에서 더 생산적인 논의는 단일 제품 내에서 여러 개발자 경험과 아키텍처 패턴에 대해 이야기하는 방법일 것입니다.

우리가 무엇이라고 부르고 레이블을 지정하며 용어를 사용하는 방법에 대해 논의하기를 원하는 것이 여기에서 대부분의 의견의 방향인 것 같습니다. 나는 많은 의사소통을 하고 있고 내가 실제로 명확성을 추가하고 혼란을 일으키지 않는지 확인하기를 원하기 때문에 이에 대한 귀하의 의견을 진심으로 환영합니다.

커뮤니티에서 이미 많은 혼란을 야기한 발표 블로그의 샘플에 관한 것입니다.

그것이 블로그에 대한 나의 공헌이었고 그것이 당신을 위해 만든 혼란에 대해 사과드립니다. Elm과 @aspnetde 의 블로그에 링크를 추가하여 "이것이 바로 MVU입니다"라고 잘못 계산했으며 기존 MVU 경험과 기대가 있는 분들에게 코드 조각이 얼마나 많은 비중을 차지할지 예상하지 못했습니다. 여기가 어떻게 생겼는지/어떻게 생겼는지에 대해.

기본적으로 나는 저자가 아직 MVU를 실제로 조사하지 않았다고 가정해야 합니다.

우리는 주제에 대해 광범위한 대화와 토론을 했습니다. 가정하지 마십시오. 저도 그렇게 하지 않으려고 노력할 것입니다.

문제는 그것이 어떤 문제를 해결할 것인지 남아 있습니다.

@dersia 해결해야 할 일반적인 문제는 개발자에게 선택권을 주는 것입니다. MVVM 위에 있는 MVU가 무엇을 해결하는지 묻는다면 나는 전혀 알 수 없습니다. 이것은 요구되거나 우리가 하려고 하는 것이 아닙니다.

#28 및 #66에서 제안된 리팩토링은 부분적으로 렌더러 구현에서 데이터 바인딩 및 MVVM 관련 사항을 분리하는 것이므로 MVU를 선택하면 MVVM에서 사용되는 추가 기능을 사용하지 않을 것입니다.

코드 조각이 얼마나 많은 무게를 견딜지 예상하지 못했습니다.

근데 저 고기 맞죠? 그리고 라벨과 일치하지 않아 죄송합니다.

@davidortinau

우리가 무엇이라고 부르고 레이블을 지정하며 용어를 사용하는 방법에 대해 논의하기를 원하는 것이 여기에서 대부분의 의견의 방향인 것 같습니다. 나는 많은 의사소통을 하고 있고 내가 실제로 명확성을 추가하고 혼란을 일으키지 않는지 확인하기를 원하기 때문에 이에 대한 귀하의 의견을 진심으로 환영합니다.

제 쪽에서 추가할 내용이 남아 있는지 잘 모르겠습니다. 제 입장을 명확하게 표현한 것 같아요 :-). MVU를 구현하려는 경우 열린 문을 밀고 나갈 것입니다. 발표 게시물과 Comet 저장소의 스니펫을 보고 추측할 수 있는 내용이라면 자유롭게 그렇게 하십시오. 그러나 MVU라고 부르는 것은 _제발_ 중지하십시오.

감사 해요.

Don이 이 스레드에서 언급되었듯이 :-) - CC: @dsyme

왜 이것이 MVU라고 불리는지 이해가 되지 않습니다. 그것은 훌륭한 패러다임일 수 있고 여기에서 훌륭하게 작동합니다. 패러다임에 적합하고 혼동하지 않는 적절한 용어를 생각해내지 않겠습니까?

@aspnetde 옆에 무엇이 남았습니까? 많은 것 같아요 :).
나는 당신의 논문의 일부를 읽었습니다. 나는 그것을 좋아했다고 말해야합니다. 또한 Don Sym에서 F#에 대한 책을 읽었습니다. 저는 함수형 프로그래밍을 좋아합니다. 내 경험에 따르면 간결하지만 이해하기 어렵습니다. 가독성은 개발 수명 주기에서 매우 중요한 부분입니다. 실제로 코드를 읽는 데 많은 시간을 할애합니다. 그리고 재귀는 쓰기 전용입니다. 한 번 작성할 수는 있지만 거의 아무도 읽을 수 없습니다(regexp와 유사).
과거에 회사에서 프로토타이핑/연구 시간 동안 Angular와 함께 Redux를 시도했습니다. 하프 엘미쉬 접근 방식입니까? 소중한 경험이었습니다. 상태를 변경하지 않도록 주의해야 하며 결과적으로 정확히 상태가 갑자기 변경될 수 있는 전체 스택을 기억할 필요가 없다는 것을 배웠습니다.
나는 불변성의 이점을 이해하지만 현실 세계는 변할 수 있다는 것을 보여주기 위해 갑자기 테디베어의 머리를 찢은 Erik Meijer의 프레젠테이션을 보았습니다.

그래서 제가 지적하고 싶은 것은: 우리의 자연스러운 사고는 이러한 패러다임에 반대되는 것이 아닙니까? 당신의 경험은 무엇입니까?

저는 XAML/C#/MVVM에 대한 경험이 많기 때문에 Don Syme이 XAML을 불필요하다고 생각하는 이유가 궁금합니다.
내 경험에 따르면 관심사(UI, 프레젠테이션, 비즈니스 등 논리)를 분리하는 데 도움이 됩니다. 이러한 DSL(C# 마크업)과 MVU가 장기적으로 코드 품질을 개선하는 데 도움이 되는지 잘 모르겠습니다. 경험이 없거나 관심이 없는 개발자는 책임을 혼합할 것입니다. MVU 패턴을 올바르게 이해하려면 더 많은 경험이 필요하지만 이 두 패러다임을 모두 시도했고 전체 커뮤니티에 매우 가치가 있습니다.
최대한 많이 공유해주세요. @aspnetde 감사합니다!

(모두) 이해해 주셔서 대단히 감사합니다.

@davidortinau 아마도 여기에 오해가 맡깁니다 . 나는 단지 우리가 물건의 이름을 올바르게 지어야 한다고 말하려고 했을 뿐입니다. 소프트웨어 개발 분야의 모든 사람들은 이름을 짓는 것이 가장 어려운 일 중 하나라는 것을 알고 있지만, 이미 이름이 잘 정의된 것이 있다면 그렇지 않은 것에 대해 그 이름을 재사용하지 말아야 합니다.

Miss Communication 잘못된
이 경우 잘못된 표현을 사용하는 것이 수정되어야 한다고 생각합니다. 그렇게 하려면 이 프로젝트에서
) MVU가 여기서 말하는 내용의 잘못된 이름임을 이해합니다.
b) 여기에서 설정하려는 것을 설명하는 올바른 용어를 찾기 위해
그런 다음 c) 모든 사람을 업데이트하고 새 이름을 사용하기 시작합니다.

나는 우리가 여전히 돌아가서 고칠 수 있는 지점에 있다고 생각합니다. 올바르게 합시다. 일어날 수 있는 최악의 상황은 XF/마우이 커뮤니티가 MVU를 다른 세계와 다른 것으로 이해한다는 것입니다.

즉, 나는 MVU의 열렬한 팬이며 MVVM도 사랑합니다. 그리고 Comet에서와 같이 유창한 MVVM 접근 방식(아직 더 나은 이름은 없습니다)과 지금까지 제시된 것이 훌륭하고 도움이 된다고 생각합니다. 많은 개발자가 지원하고 이름을 수정해야 한다고 생각합니다.

편집: 미스 커뮤니케이션이 대회에서 탈락했습니다.

나는 불변성의 이점을 이해하지만, 현실 세계는 변할 수 있다는 것을 보여주기 위해 갑자기 테디베어의 머리를 찢는 Erik Meijer의 프레젠테이션을 보았습니다.

@tomasfabian 이것은 잘못되었습니다.

세상을 일련의 사건으로 보기 시작해야 합니다. 그것이 실제로 그렇습니다(여기서 이벤트 소싱 논의를 시작하고 싶지 않습니다).
테디베어에게 일어난 일은 그 상태에 새로운 이벤트가 추가되었다는 것뿐입니다. 이 경우의 이벤트는 "머리가 찢어진" 것입니다. 그리고 이벤트가 발생하면 되돌릴 수 없다는 사실을 알 수 있듯이 발생한 일을 실행 취소하거나 삭제할 수 없습니다. 머리를 테디로 되돌리려면 "몸에 머리를 꿰매기"라는 새로운 이벤트가 필요합니다. 😉

FP 및 MVU의 이점에 대해 논의하는 것은 여기에서 주제에서 벗어난 IMHO입니다. 이 문제는 잘못된 의사 소통과 정확한 이름 지정 가능성에 관한 것이라고 생각했습니다.

@isaacabraham 아마도 당신이 옳았을 것입니다. 나는 그것에 대해 사과합니다. 이건 내 잘못이야. 네이밍이 중요하다는 건 알지만 한편으로는 'MVU가 생각한 것과 다를 수도 있다'는 제목이 문제다. 그래서 이름 짓는 것보다 조금 더 광범위한 주제가 되기를 바랍니다.
고마워요, 토마스

@tomasfabian MVU, FP 또는 그 밖의 모든 것의 장단점에 대해 이야기하게 되어 매우 기쁩니다. 실제든 가상이든 😊 이것이 적절한 포럼이라고 생각하지 마십시오.

@davidortinau
언어 기능 및 아키텍처 변경 사항이 도움이 될 수 있는 한 다음과 같은 제안을 드리고자 합니다.

* new 키워드 및 기타 구문 노이즈.
Dart나 Kotlin과 달리 C#에는 필수 new 키워드가 영원히 붙어 있을 수 있습니다. 선택 사항으로 만드는 것은 파일별 옵트인 지시문으로도 주요 변경 사항이자 인기 없는 제안이기 때문입니다. 따라서 그 대신에 최소한 핵심 집합에 대해 생성자를 래핑하고 초기화 전용 속성(있는 경우)을 초기화하는 정적 메서드를 포함하는 공식(유지 관리되는) 정적 클래스(또는 MAUI 뷰 네임스페이스당 정적 클래스)가 있을 수 있습니다. MAUI 보기 개체. 그런 다음 뷰 코드 .cs 파일의 맨 위에 using static 지시문을 넣은 다음 new 구문 노이즈 없이 메서드를 호출할 수 있습니다. 이렇게 하면 C# 보기 기능의 어수선함과 노이즈가 약간 줄어듭니다. 물론 이러한 정적 메서드 생성자 래퍼는 커뮤니티에서 자동 생성할 수 있지만(Xamarin.Forms가 CSharpForMarkup과 함께 사용하도록 비슷한 작업을 수행했습니다.) MAUI 프로젝트.

또한 MVU/Comet/CSharpForMarkup 보기 함수에서 일반적으로 사용되는 것처럼 큰 표현식 트리에서 구문 혼란이나 노이즈를 줄이는 데 도움이 되는 C# 언어 제안은 큰 도움이 될 것입니다. C#9는 MVU의 M 및 U 부분을 개선하기 위해 이와 관련하여 먼 길을 갔지만 V 부분은 여전히 ​​구문상 골칫거리입니다.

* 확장 속성 *
"extension-everything" 제안이 현재 보류 중이라는 것을 알고 있지만 MVVM-with-C#-markup(예: Xamarin.Forms가 있는 CSharpForMarkup)에 도움이 될 수 있는 한 가지는 확장 속성입니다. CSharpForMarkup을 사용하면 모든 도우미는 확장 메서드를 사용하여 구현해야 했지만 경우에 따라 확장 속성(개체 이니셜라이저에서 사용 가능)이 훨씬 더 좋아 보입니다.

// Instead of this:
public View Body() =>
    new Widget() {
        BuiltInProperty = "initial value",
    }.SetExtensionProperty("initial value");

// the extension property could be included in the object initializer:
public View Body() ->
    new Widget() {
        BuiltInProperty = "initial value",
        ExtensionProperty = "initial value",
    };

이는 마크업용 C#이 있는 MVVM에서와 같이 변경 가능한 뷰 개체 트리에만 실제로 적용됩니다. MVU 또는 기타 기능적 UI 아키텍처의 경우 뷰 개체가 변경 불가능하므로 적용할 수 없습니다. 그런 경우에는 유창한 확장 방법이 더 적합합니다.

* 상태 관리에 대해 덜 독단적(또는 원하는 경우 낮은 수준)을 유지합니다. *
Xamarin.Forms 위에 MVU를 구현하는 데 있어 가장 큰 장벽 중 하나는 두 가지 필수 구성 요소가 없다는 것입니다. 플랫폼별 표현 등...). 그리고 두 번째 조각은 부분 diff 등을 수행하여 diff를 효율적으로 수행하는 방법을 포함하여 뷰 함수의 반환 값과 다른 반환 값 간의 차이점을 찾아 헤비급 플랫폼별 뷰를 효율적으로 업데이트하는 diffing 엔진입니다...

MAUI가 이제 이 두 가지 필수 요소를 제공하는 것 같군요. 훌륭합니다! 그러나 MVU 커뮤니티의 일부가 MVU 또는 유사한 "기능적" UI 아키텍처보다 MVVM에 더 가깝다고 말하는 독단적인 상태 관리 방식과 적어도 표면적으로는 매우 밀접하게 관련되어 있는 것으로 보입니다. 내가 선호하는 것은 위에서 언급한 두 가지 필수 요소(가벼운 보기 개체 그래프 및 효율적인 diffing 엔진)를 유지하고 MVU 또는 Comet이 위에 효율적으로 계층화될 수 있는 더 낮은 수준의 구성 요소 시스템과 결합하는 것입니다. 선택. 어쩌면 그것이 이미 목표이고 내가 보지 못하는 것일까요? 그렇다면 최소한 몇 가지 기본 예를 통해 이에 대한 더 많은 논의를 보고 싶습니다.

@aspnetde 왜 게시물을 삭제했습니까?

@tomasfabian

내 경험에 따르면 [MVVM]은 관심사(UI, 프레젠테이션, 비즈니스 등)를 분리하는 데 도움이 됩니다.

네, 그렇습니다. 저는 MvvmCross로 빌드된 대규모 Xamarin.iOS 및 Xamarin.Android 애플리케이션으로 좋은 경험을 했습니다. 오늘날 나는 프레임워크보다 라이브러리를 훨씬 더 선호하지만, 그 모든 프로젝트(일부는 6자리 LOC가 포함됨)가 기술적으로나 비즈니스 관점에서 성공했다고 생각합니다.

MVVM은 특히 애플리케이션을 확장할 때 좋은 역할을 한다고 생각합니다. 특히 모놀리스를 출하해야 하는 모바일에서는 앱이 일정 크기를 넘으면 독립적인 모듈로 리팩토링하는 데 도움이 되었습니다.

이러한 패러다임([MVU])에 대한 우리의 자연스러운 사고가 아닐까요? 당신의 경험은 무엇입니까?

나는 그렇게 생각하지 않는다. 스토리지용 Redux에 대한 경험을 활용하고 전체 애플리케이션이 이점을 활용할 수 있다고 상상해 보십시오. 언뜻보기에는 더 복잡해 보이지만 내 경험에 따르면 이해하고 작업하는 것이 훨씬 간단합니다. @forki가 종종 지적하는 것처럼 단방향 데이터 흐름이 항상 무슨 일이 일어나는지 명확하게 해주기 때문에 거의 지루합니다.

이러한 DSL(C# 마크업)과 MVU가 장기적으로 코드 품질을 개선하는 데 도움이 되는지 잘 모르겠습니다.

MVU와 MVVM은 서로 다른 장점이 있지만 둘 다 서로 다른 단점도 있습니다.

MVVM 프로젝트가 성공적이었음에도 불구하고 우리 팀과 나는 디버깅에 대해 머리를 잃었습니다. 특히 한 프로젝트에서 우리는 이미 지적한 바와 같이 새로운 팀원의 경험 부족과 오해로 인해 복잡성을 겪기 시작했습니다. 엄격하게 적용될 때 MVU에서는 그럴 가능성이 적습니다. 왜냐하면 MVU가 작동 방식의 경계를 너무 좁게 정의하기 때문에 그 경계를 깨고 다른 방식보다 잘못된 방식으로 구축하는 것이 거의 더 어렵기 때문입니다.

MVU의 경우 두 가지 주요 문제가 있습니다. 첫 번째: 스케일링. 많은 사람들이 단일 프로그램을 지지하고 있습니다. 저는 여기에 회의적입니다(여러 프로그램/모듈이 더 나은 방법이라고 생각합니다). 두 번째: 바로 지금 Fabulous와 같은 것이 Xamarin.Forms 위에 있습니다. 따라서 iOS/Android 위에 있는 추상화 계층 위에 있는 추상화 계층 위에 있는 추상화 계층입니다. 엄청난 복잡성입니다. 따라서 아무도 신경 쓰지 않는 버그를 해결할 뿐만 아니라 다른 추상화 계층(Xamarin.Forms)이 변경될 때 하나의 추상화 계층(Fabulous)을 업데이트하는 것도 다소 지루하고 불쾌한 작업입니다.

그것이 내가 MAUI에 대한 큰 기회를 볼 수 있는 곳입니다. 저는 솔직히 Fabulous 메인테이너들이 여기에서 Microsoft와 힘을 합치는 것을 보고 싶습니다. 그리고 나는 조직의 다른 부분들이 과거에 그랬던 것처럼 Microsoft가 그것을 망치지 않기를 정말로 바랍니다.

도마

요전에 공식 발표를 읽었을 때 MVU로 표시된 내용에 놀랐습니다.

readonly State<int> count = 0;

[Body]
View body() => new StackLayout
{
    new Label("Welcome to .NET MAUI!"),
    new Button(
        () => $"You clicked {count} times.",
        () => count.Value ++)
    )
};

내가 아는 한 이것은 MVU가 아닙니다 . 나는 이미 여기 에 왜 그렇게 생각 하는지에 대한 몇 가지 생각 을 적었습니다 .

내가 알기로는 Xamarin.Forms 위에 MVU를 구현하고 나중에 Fabulous 가 된 것을 구축하는 데 2018년 몇 달을 보낸 Don Syme 는 좀 더 외교적 이지만 결론은 동일합니다.

그래서, 내 요점은 무엇입니까?

• C#이든 F#이든 상관없이 실제 아키텍처 패턴을 구현했으면 합니다. Fabulous 뒤에 있는 사람들에게 다가가는 것이 여기에서 시작될 수 있습니다.
• 그것에 관심이 없지만 현재 Comet 라이브러리 로 사용할 수 있는 것을 구축하는 것에 대한 명확한 비전이 있다면 해당 "앱 모델"에 더 적절한 이름을 사용하는 것을 고려하십시오. 새로운 것을 발명하십시오. 이름을 MSMVU로 지정합니다. 무엇이든. 그러나 오렌지를 위해 사과를 팔지 마십시오.

건배!

왜 이름을 MSMVU로 지정할까요? 혜성은 MVU였으며 앞으로도 그럴 것입니다. 그리고 마우이는 MVU입니다.

.NET MAUI가 MVU인지 아닌지 말하기에는 너무 이르다고 생각합니다.

MAUI가 결국 MVU가 될지 여부는 중요하지 않습니다. 커뮤니티에서 이미 많은 혼란을 야기한 발표 블로그의 샘플에 관한 것입니다. 기본적으로 나는 저자가 아직 MVU를 실제로 조사하지 않았다고 가정해야 합니다. "C# MVU"에 대해 이야기한다고 해서 이것이 더 나아지는 것은 아닙니다.

그것은 어떤 혼란도 일으키지 않습니다. 일부 사람들은 C#이 MVU를 수행하는 것을 보고 처리할 수 없습니다.

그만한 가치가 있기 때문에 SwiftUI(Comet이 대부분의 영감을 얻음)는 명시적인 지침이 없음에도 불구하고 패턴을 MVVM이라고 부르는 경향이 있습니다.
하지만 MVU에 대한 언급을 찾지 못했습니다.

@TimLariviere https://github.com/Clancey/Comet#key -concepts
기본적으로 Comet은 그것을 MVU라고 불렀고 이미 MVU의 이전 정의에 있는 메시지 루프의 요점을 놓치고 있습니다.

그만한 가치가 있기 때문에 SwiftUI(Comet이 대부분의 영감을 얻음)는 명시적인 지침이 없음에도 불구하고 패턴을 MVVM이라고 부르는 경향이 있습니다.

이 게시물의 시작 부분에 있는 예제를 보면 틀리지 않습니다. https://nalexn.github.io/clean-architecture-swiftui/

하지만 MVU에 대한 언급을 찾지 못했습니다.

동일한 게시물에서도 이에 대해 간략하게 설명합니다(SwiftUI + Redux = TEA의 조합으로). 이후 "Clean Architecture"로 이상하게 전환되고 있지만 😄

여기에서 언급되었으므로 몇 가지만 말씀드리겠습니다.

• MAUI는 훌륭하고 아키텍처로서의 MVU에 대해 배우는 것은 사람들이 MAUI를 이해하는 데 유용할 수 있다고 생각합니다.

• 단어에 얽매이기 쉽고, 이 단계에서 우리 모두 숨을 쉬고 걱정하지 않으려고 노력해야 합니다. 사용되는 단어를 조정할 시간이 충분하고 정확한 용어에 대한 메시지가 전달되었다고 생각합니다. 들었다. 개인적으로 Elm은 "MVU"의 꾸밈이 없고 한정되지 않은 사용이 명시적 메시지, 명시적 업데이트, 기능적 모델, 기능적 뷰 재계산 및 차등 업데이트를 의미한다는 것을 확립했다고 생각합니다. 그러나 MVU 에는 많은

• 나는 사람들이 이 분야에 대해 매우 강한 신념과 의견을 가지고 있는 경향이 있고 매우 개인적으로 받아들일 수 있다는 것을 알게 되었습니다. 나는 그것이 어떤 것인지 알고 프로그래밍 언어 디자인과 마찬가지로 공간의 모든 지점에는 장단점이 있다고 생각합니다. 가능한 최고의 기술을 만들기 위해 모든 사람이 함께 시도하고, 사용하고, 배우고, 공유하고, 협력할 것을 권장합니다.

@dsyme
Comet/MAUI 아키텍처에 대한 적절한 용어는 단방향 데이터 흐름(또는 UDF)의 변형이지만 MVU 자체가 UDF의 매우 특정한 변형이기 때문에 MVU가 아니라고 생각합니다. MAUI/Comet은 확실히 UDF 프레임워크로 적합하지만(SwiftUI와 마찬가지로) MVU 프레임워크로는 적합하지 않습니다. UDF에는 MVU, Flux, Redux, React 등 여러 변형이 있지만 MVU가 전혀 아닐 때 Comet MVU를 호출하는 것은 잘못된 의사소통입니다.

MVU와 달리 Model은 변경 가능하며 View 함수의 코드에 의해 변경됩니다. 그런 다음 돌연변이가 관찰되고 뷰는 다시 렌더링하여 이러한 돌연변이에 반응합니다. 뷰가 변경되지 않았기 때문에 여전히 단방향이지만 업데이트 기능, 메시지 및 메시지 디스패칭이 없으므로 MVU가 아닙니다. MVVM의 단방향 변형에 가깝습니다.

@JeroMiya 감사합니다. 해당 용어에 대한 참조가 있습니까?

@dsyme 이에 대한 구체적인 언급은 없지만 React 초기, 특히 React 자체와 Redux 및 Flux와 같이 등장한 초기 패턴 몇 가지와 관련하여 처음 사용된 용어를 듣기 시작했습니다. 많은 UDF 변형(대부분 React 공간에 있음)을 설명하는 기사를 기억하지만 지금은 찾을 수 없습니다.

즉, 형식 아키텍처가 아닙니다. 보기가 이벤트에 대한 응답으로 변경되는 상태 저장 개체 트리인 것과는 대조적으로 모델의 기능인 보기의 기본 개념에 더 가깝습니다. UDF 개념은 모델이 어떻게 업데이트되는지 또는 변경 가능하거나 변경할 수 없는지 여부를 반드시 지정하지 않습니다. MVU는 UDF 개념을 뷰 자체뿐만 아니라 모델 업데이트 프로세스까지 확장합니다. 따라서 MVU에서는 모델도 변경할 수 없으며 UI 상태 변경은 새 보기를 트리거하는 새 모델을 생성하는 명령으로 표시됩니다.

물론 새로운 개념은 아닙니다. React 이전에도 Asp.Net MVC, Rails, 심지어 PHP와 같은 대부분의 서버 측 웹 프레임워크가 기술적으로 단방향으로 간주됩니다. React가 등장하기 전에는 주류 SPA 프레임워크와 클라이언트 측 UI 프레임워크에서 일반적이지 않았습니다.

@dsyme 이에 대한 구체적인 언급은 없지만 React 초기, 특히 React 자체와 Redux 및 Flux와 같이 등장한 초기 패턴 몇 가지와 관련하여 처음 사용된 용어를 듣기 시작했습니다. 많은 UDF 변형(대부분 React 공간에 있음)을 설명하는 기사를 기억하지만 지금은 찾을 수 없습니다.

즉, 형식 아키텍처가 아닙니다. 보기가 이벤트에 대한 응답으로 변경되는 상태 저장 개체 트리인 것과는 대조적으로 모델의 기능인 보기의 기본 개념에 더 가깝습니다. UDF 개념은 모델이 어떻게 업데이트되는지 또는 변경 가능하거나 변경할 수 없는지 여부를 반드시 지정하지 않습니다. MVU는 UDF 개념을 뷰 자체뿐만 아니라 모델 업데이트 프로세스까지 확장합니다. 따라서 MVU에서는 모델도 변경할 수 없으며 UI 상태 변경은 새 보기를 트리거하는 새 모델을 생성하는 명령으로 표시됩니다.

물론 새로운 개념은 아닙니다. React 이전에도 Asp.Net MVC, Rails, 심지어 PHP와 같은 대부분의 서버 측 웹 프레임워크가 기술적으로 단방향으로 간주됩니다. React가 등장하기 전에는 주류 SPA 프레임워크와 클라이언트 측 UI 프레임워크에서 일반적이지 않았습니다.

@JeroMiya 감사합니다. 이것이 제가 MVU를 이해하는 방식입니다.
MVU를 최상의 형태로 사용하고 예시하는 가장 오래되고 여전히 주로 사용하는 응용 프로그램 중 하나가 MS Excel이라고 말하고 싶습니다.

@dsyme 귀하의 의견을 읽고 있습니다. MAUI를 논의된 아키텍처(MVVM이 있는 CSharpForMarkup)의 용어로 언급하고 있다는 느낌이 듭니다.
이것이 MAUI가 이해하는 바가 아님을 명확히 해주세요.
내가 이해한 바에 따르면 MAUI는 미래의 어느 시점에서 XF를 대체할 다음 MS 응용 프로그램 프레임워크일 뿐입니다.

이 문제와 댓글이 진행되는 방식이 정말 마음에 듭니다. 참여해 주셔서 감사합니다. 아마도 우리는 MAUI에 대한 가능한 풍미로 모든 다른 아키텍처를 적절하게 설정하고 명명할 수 있습니다.

@dersia 감사합니다! CSharpForMarkup에 대한 제 경험에 대한 참고 사항입니다. MVVM보다 약간 낮은 수준입니다. C# 마크업을 보다 간소화되고 보기 좋게 만들기 위한 확장 메서드 및 유틸리티 집합이 더 많습니다. ViewModel 바인딩을 더 쉽게 만드는 도우미가 있기 때문에 MVVM 패턴을 확실히 구현할 수 있지만 결국 ViewModel 대신 Redux에서 모든 뷰 로직을 구현하는 것으로 끝납니다. 보기 속성을 상태 선택기에 바인딩하는 몇 가지 확장 메서드를 추가하기만 하면 됩니다. Func<StateType, ChildStateType> Redux 상태 저장소의 Select 및 DistinctUntilChanged 연산자에 전달합니다. Observable<StateType> . 단방향 데이터 흐름은 아니지만 지금 Fabulous와 같은 UI 개체 트리 비교 및 ​​보기 기능을 수행하는 성숙한 방법이 없었습니다.

얼마 전 REST 경찰은 우리 모두가 REST라고 부르지 말아야 할 것을 목구멍으로 밀어 넣으려고 했습니다. 오늘날에도 모두가 그것을 REST라고 부르며 우리 모두는 여전히 살아 있고 건강합니다. 😉

@bitbonk REST 커뮤니티는 점점 더 많은 것들이 혼합되면서 점점 더 쓸모 없게 되었기 때문에 이 용어를 포기했습니다. 그들은 이제 "하이퍼미디어(hypermedia)"를 사용하여 REpresentational State Transfer를 참조합니다. 오늘날 REST는 "SOAP 아님" 또는 "JSON over HTTP"만을 의미하며 둘 다 핵심 아이디어를 전달하는 데 성공하지 못합니다. 여기 댓글 작성자는 MVU가 같은 운명을 맞이하지 않기를 바라고 있습니다.

@davidortinau @tomasfabian , 아직 MAUI에서 MVU의 예를 보지 못했습니다. 나는 오늘 밤에 예제를 만들려고 노력할 것이다. 여기 에서 WinForms에 대해 비슷한 작업을 수행

@JeroMiya 감사합니다. 해당 용어에 대한 참조가 있습니까?

@dsyme , 나는 그것이 React Flux에서 시작되었다고 생각하지만 그들은 게임 아키텍처, 즉 Doom 3를 가리켰 습니다. 제 생각에는 이것이 처음 발표되었을 때

• https://reactjs.org/blog/2014/05/06/flux.html
• https://www.infoq.com/news/2014/05/facebook-mvc-flux/
• https://facebook.github.io/flux/
• https://github.com/topics/unidirectional-data-flow

다음은 C# 예제에 대한 저의 시도입니다. 실제 예제로 이것을 시도할 MAUI가 없습니다. 미리보기가 없잖아요? 어쨌든 이것은 아이디어의 대략적인 번역입니다.

using Model = int;

interface IMsg {}
sealed class Increment : IMsg {}

Func<Model> init() => 0;

Func<IMsg, Model, Model> update = (IMsg msg, Model model) =>
{
    return msg switch
    {
        Increment _ => model + 1,
        _ => throw new NotImplementedException()
    };
};

Func<Model, Action<IMsg>, View> view =
    (Model model, Action<IMsg> dispatch) => new StackLayout
    {
        new Label("Welcome to .NET MAUI!"),
        new Button(
            () => $"You clicked {model} times.",
            () => dispatch(new Increment())
        )
    };

// Program should be defined as part of MAUI and is used to start the flow.
// This should listen for messages, run the `update`, re-compute the `View`, then re-render.
var program = new Program<Model, IMsg>(init, update, view);

보기 부분을 제외하고 비슷한 것을 한 번 간단히

저는 MVU를 처음 접했고 여러분 중 많은 분들에 비해 사용 경험이 거의 없을 것입니다. 그러나 MVU 개념은 확실히 내 관심을 끌었고 나는 그것을 즐기고 있습니다. C# 개발자들이 MVU 패턴 개발에 도움이 되는 프레임워크를 받게 되어 매우 기쁩니다.

MAUI MVU가 일반적인 MVU가 아니며 SwiftUI의 영향이 크다는 데 전적으로 동의합니다. 이 책의 주요 저자인 Clancey Himeslef는 거의 모든 세션에서 이 점을 매우 분명하게 밝혔습니다. Redux가 MVU의 영향을 많이 받으며 SwiftUI, Flutter 및 기타 많은 프레임워크도 마찬가지입니다. 그들 중 누구도 순수한 MVU가 아닙니다.

그러나 우리 모두는 이러한 모든 프레임워크에 가장 가까운 아키텍처 패턴이 MVU라는 데 동의합니다. 사람들이 그것을 참조하는 이유입니다. 그리고 우리가 지금부터 1년 반 후에 출시될 프레임워크의 블로그 제목에 대해 이야기하고 있다는 것을 기억하십시오.

그리고 사람들이 이 블로그 제목에 대해 화를 내고 있다고 말하면. 나는 우리가 그들에 대해 정말로 걱정할 필요가 없다고 생각합니다. 커뮤니티는 여전히 계속되어야 합니다. 이 프레임워크를 개선하기 위해 에너지를 사용합시다. 작은 세부 사항에 대해 너무 걱정하지 마십시오.

그러나 우리 모두는 이러한 모든 프레임워크에 가장 가까운 아키텍처 패턴이 MVU라는 데 동의합니다. 사람들이 그것을 참조하는 이유입니다.

개, 말, 고양이 및 침팬지는 모두 서로 매우 가깝습니다. 이제부터는 모두 고양이라고 부르겠습니다.

:) 글쎄, 당신은 할 필요가 없습니다. 하지만 한 가지 말씀드리겠습니다. 고양이, 호랑이, 표범 등은 고양이라고 합니다. 그리고 당신이 그것을 가져 와서 기쁩니다. 여기가 바로 그 경우입니다.

@aspnetde : Thomas, 말한 모든 것. 귀하의 원래 MVU 블로그는 개념을 매우 명확하고 정확하게 설명하는 최고의 기사 중 하나라고 말하고 싶습니다. 나는 그것으로부터 상당한 것을 배웠다. 감사합니다

@ libin85 정확히 문제가 있습니다. 당신은 실제로 한 범주에 속하는 것들을 열거하기 시작했고 그렇지 않은 것들은 무시했습니다. MAUI 샘플을 MVU 범주에 넣으면 기본적으로 침팬지를 고양이 범주에 넣습니다.

변경할 수 없는 보기와 같은 MVU 구현과 유사합니다. 그러나 메시지 루프가 없고 명시적인 업데이트 기능이 없다는 것과 같은 분명한 차이점이 있습니다. 모델은 View에서 직접 변경됩니다. 이것은 사람들이 MVU를 생각해냈을 때 명시적으로 원하지 않았던 것입니다. 일부 언어에서는 그렇게 하는 것이 불가능할 수도 있습니다. 이것이 MVU가 등장한 이유입니다. 그리고 그것이 대중화 된 이유. 이제 MVU 정의에서 해당 속성을 제거하는 경우 주의해야 합니다.

@forki : 나는 당신이 말한 것에 반대하지 않습니다. 사실 우리가 블로그 게시물의 제목이 아니라 커뮤니티로서 논의해야 하는 것은 마지막 댓글에서 제기한 요점입니다. 그게 제 요점입니다. 이는 논의할 긍정적인 것이며 프레임워크는 이를 통해 얻을 수 있습니다.

나는 그 이름이 더 중요한 측면에서 주의를 산만하게 해서는 안 되는 약간의 세부 사항이라는 데 동의합니다. 그러나 내가 그것을 꺼낸 이유는 개인적으로 MAUI를 상식이 결국 공통적으로 합의된 해결책으로 이끄는 공동체의 노력으로 보지 않기 때문입니다. 비공개 결정이 내려지는 Microsoft 제품입니다. 나는 내 문제를 제기하기 위해 고객으로서 여기 있습니다.

그러나 우리 모두는 이러한 모든 프레임워크에 가장 가까운 아키텍처 패턴이 MVU라는 데 동의합니다.

@ libin85 나는 이것이 가장 가까운 아키텍처 패턴이라는 데 동의하지 않습니다. MVU는 일반적으로 MVP 또는 Model View Presenter처럼 보이는 것에 대한 일련의 제약 조건입니다. MVVM은 프리젠터가 데이터 바인딩이 있는 ViewModel이라는 점에서 다른 방향을 취하는 유사합니다. MVP 자체는 MVC의 제한된 형태입니다. 이것들이 모두 MVC, 심지어 MVP의 후손이라고 해도 과언이 아닌 것 같지만, MVU가 SwiftUI, Flux 등에 적용된다는 것은 MVU를 무의미한 용어로 만드는 것입니다.

나는 그 이름이 더 중요한 측면에서 주의를 산만하게 해서는 안 되는 약간의 세부 사항이라는 데 동의합니다.

아니요, 이름이 중요합니다. 그것들은 의미를 확립하고 유지하는 것이 어렵습니다. 위에서 논의한 REST도 참조하십시오. REST는 너무 남용되어 마케팅 전문 용어 외에는 더 이상 의미가 없습니다. 특히 MAUI의 "MVU"가 제공하는 내용에 대한 기존 용어가 있는 경우 MVU에 그런 일이 발생하지 않도록 하고 싶습니다.

그만한 가치가 있기 때문에 MAUI "MVU"는 MVVM 옵션에 대한 좋은 대안이라고 생각합니다. REST와 마찬가지로 유용하고 좋은 것을 만들기 위해 정의적인 작업을 수행할 필요가 없습니다. 잘 정의되고 확립된 패턴에서 분명히 벗어나는 대안으로 이름을 혼동하지 마십시오. 결국 MVU는 _또한_ MVVM 및 Comet 옵션에 대한 좋은 대안이 될 것입니다.

그만한 가치가 있기 때문에 MAUI "MVU"는 MVVM 옵션에 대한 좋은 대안이라고 생각합니다. REST와 마찬가지로 유용하고 좋은 것을 만들기 위해 정의적인 작업을 수행할 필요가 없습니다. 다만 정의에서 분명히 벗어나는 대안으로 이름을 혼동하지 마십시오.

전체 확인.

왜 이름을 MSMVU로 지정할까요? 혜성은 MVU였으며 앞으로도 그럴 것입니다. 그리고 마우이는 MVU입니다.

@saint4eva 그들은 "판매"되지만 정의상 MVU는 아닙니다.

나는 그 이름이 더 중요한 측면에서 주의를 산만하게 해서는 안 되는 약간의 세부 사항이라는 데 동의합니다.

아니요, 이름이 중요합니다. 그것들은 의미를 확립하고 유지하는 것이 어렵습니다. 위에서 논의한 REST도 참조하십시오. REST는 너무 남용되어 마케팅 전문 용어 외에는 더 이상 의미가 없습니다. 특히 MAUI의 "MVU"가 제공하는 내용에 대한 기존 용어가 있는 경우 MVU에 그런 일이 발생하지 않도록 하고 싶습니다.

그만한 가치가 있기 때문에 MAUI "MVU"는 MVVM 옵션에 대한 좋은 대안이라고 생각합니다. REST와 마찬가지로 유용하고 좋은 것을 만들기 위해 정의적인 작업을 수행할 필요가 없습니다. 잘 정의되고 확립된 패턴에서 분명히 벗어나는 대안으로 이름을 혼동하지 마십시오. 결국 MVU는 _또한_ MVVM 및 Comet 옵션에 대한 좋은 대안이 될 것입니다.

나는 당신이 말한 대부분에 동의하지만 "마우이 MVU"는 여전히 나쁘고 혼란 스럽다고 생각합니다. 아마도 "마우이 MVP" 또는 MVC로 갈 것입니다. 둘 다 작동하며 MVU보다 블로그 게시물에 표시된 내용에 더 가깝습니다.

추가 편집:
제안된 버전이 어디에 있는지조차 모르겠습니다. 내 말은 MVVM의 논리는 ViewModel에 있고 MVU는 업데이트 기능 내에 있고 MVP는 Presenter에 있고 MVC는 Controller에 있다는 뜻입니다.

모든 것이 사는 뷰가 있을까요? 아니면 보기, 논리 및 모델을 제공하는 도메인 모델에 의해 명명된 일부 클래스에 모두 존재합니까? 모델은 별도의 클래스(유형) 또는 레코드여야 합니까?

나는 이것이 나를 위한 주요 고충점이라고 생각합니다. 그것이 "제시"되는 방법에 대한 단서가 없기 때문에 업데이트, 모델 및 보기 기능이 있다는 것을 알 수 없습니다.

기본적으로 MAUI는 지금까지 논의된 패턴보다 약간 낮은 수준인 것 같습니다. 실제로는 다른 패턴의 모델(또는 상태) 및 보기 부분입니다. 다른 패턴을 구현하기 위해 구축할 수 있는 것(상태 관리가 다소 독단적이긴 하지만).

예를 들어 State<T> 의 T 가 ViewModel과 유사한 클래스이고 별도의 데이터 모델 클래스 세트를 추가하면 MVVM과 같은 결과를 얻게 됩니다. 단방향보기.

반면에 Redux와 유사한 상태 관리 시스템을 추가하고 Redux 상태 모델을 T in State<T> 하면 결국 MVU에 매우 가까운 결과를 얻게 됩니다. , Elm/Fabulous와 같은 기존 MVU만큼 완전히 통합되지는 않았지만. Fabulous가 Xamarin.Forms에서 수행하는 것처럼 MVU 프레임워크 뒤에 MAUI 보기를 숨길 수 있습니까?

MAUI를 통해 MVC 또는 MVP 패턴을 구현하는 방법을 잘 모르겠습니다. 대략적인 첫 번째 단계로 보기 기능에 "작업"을 노출하는 별도의 클래스를 만들었다면 아마 생각하고 있습니다. 예를 들어 MAUI 확인 대화 상자가 있고 "컨트롤러" 클래스에 "ClickOK" 메서드와 "ClickCancel" 메서드가 있다고 가정합니다. MAUI 보기는 보기에서 새 모델을 생성하거나 기존 모델을 변경하는 컨트롤러로 클릭 이벤트를 전달합니다.

@JeroMiya 동의합니다. 확실히 Redux 패턴을 사용하면 MVU에 더 가까워지고 아키텍처를 훨씬 덜 비판적으로 유지할 수 있습니다. 저는 React-Redux, React-Hooks, ReactiveX 및 최근 Blazor Apps :heart: Fluxor :heart: 의 행복한 사용자입니다. @mrpmorris 가 이 대화에 기여할 수 있습니다.

다음은 C# 예제에 대한 저의 시도입니다. 실제 예제로 이것을 시도할 MAUI가 없습니다. 미리보기가 없잖아요? 어쨌든 이것은 아이디어의 대략적인 번역입니다.

using Model = int;

interface IMsg {}
sealed class Increment : IMsg {}

Func<Model> init() => 0;

Func<IMsg, Model, Model> update = (IMsg msg, Model model) =>
{
    return msg switch
    {
        Increment _ => model + 1,
        _ => throw new NotImplementedException()
    };
};

Func<Model, Action<IMsg>, View> view =
    (Model model, Action<IMsg> dispatch) => new StackLayout
    {
        new Label("Welcome to .NET MAUI!"),
        new Button(
            () => $"You clicked {model} times.",
            () => dispatch(new Increment())
        )
    };

// Program should be defined as part of MAUI and is used to start the flow.
// This should listen for messages, run the `update`, re-compute the `View`, then re-render.
var program = new Program<Model, IMsg>(init, update, view);

Microsoft 샘플에서보다 업데이트에 더 많은 성능 비용이 발생합니까? 이 모델에서는 MS 샘플에서와 달리 모든 UI 요소를 포함하는 새 보기가 인스턴스화되며 기존 보기 요소는 제자리에 두고 레이블 값만 업데이트됩니다(재 -사이징 비용이 있을 수 있음).

이 차이점은 이름 지정에 대한 이 토론을 이끄는 핵심 차이점 중 하나인 것 같습니다. 따라서 전통적으로 정의된 MVU 아키텍처에 UI를 효율적으로 업데이트하기 위한 다른 기술이 있는지, 그리고 그렇다면 이러한 기술이 다음 수준에서 구현되는지 궁금합니다. 렌더링 엔진?

@markmccaigue 성능 관련: 종종 MVU 시스템에는 가상 보기(또는 html의 경우 가상 DOM)와 다양한 엔진이 함께 제공됩니다. 따라서 DOM을 가상 DOM과 비교한 후 프레임워크는 DOM에 패치를 적용하기만 하면 됩니다. 이것은 특히 불변 데이터 구조로 작업하는 경우 일반적으로 매우 효율적입니다.

안녕하세요!!

나는 지금이 문제를 닫을 것입니다 .. 나는 이것을 토론하고 싶지만 github는 그것을 작동시키고 싶지 않습니다 :-/

이 대화를 계속하고 싶은 사람이 있으면 토론 항목을 만든 다음 이 문제를 참조하세요.