MVVM은 무의미합니까?

MVVM은 무의미합니까? [닫은]

---

정통 MVVM 구현은 무의미합니까? 새 응용 프로그램을 만들고 있으며 Windows Forms 및 WPF를 고려했습니다. WPF는 미래에 대비하고 많은 유연성을 제공하기 때문에 선택했습니다. 코드가 적고 XAML을 사용하여 UI를 크게 변경할 수 있습니다.

WPF에 대한 선택은 분명하기 때문에 MVVM을 응용 프로그램 아키텍처로 사용하여 혼합 가능성, 분리 문제 및 단위 테스트 가능성을 제공하므로 끝까지 진행할 수 있다고 생각했습니다. 이론적으로는 UI 프로그래밍의 성배처럼 아름답게 보입니다. 이 짧은 모험; 그러나 실제로 두통이되었습니다. 실제로 예상했던대로, 저는 한 문제를 다른 문제와 교환했습니다. 나는 올바른 결과를 얻고 더 나은 프로그래머가 될 수 있도록 올바른 방식으로 일을하고 싶다는 점에서 강박적인 프로그래머 인 경향이 있습니다. MVVM 패턴은 생산성에 대한 내 테스트를 막았고 방금 큰 엉뚱한 해킹으로 변했습니다!

명확한 사례는 모달 대화 상자에 대한 지원을 추가하는 것입니다. 올바른 방법은 대화 상자를 표시하고이를 뷰 모델에 연결하는 것입니다. 이것을 작동시키는 것은 어렵습니다. MVVM 패턴의 이점을 얻으려면 애플리케이션 계층 전체에 걸쳐 여러 위치에 코드를 배포해야합니다. 또한 템플릿 및 람바 식과 같은 난해한 프로그래밍 구조를 사용해야합니다. 머리를 긁적 거리며 화면을 응시하게 만드는 것. 이로 인해 유지 관리 및 디버깅은 내가 최근에 발견 한대로 일어나기를 기다리는 악몽이됩니다. 두 번째 호출시 예외가 발생할 때까지 about box가 제대로 작동하여 닫히면 대화 상자를 다시 표시 할 수 없다고 말했습니다. 대화 창에 닫기 기능을위한 이벤트 핸들러를 추가해야했습니다. 다른 하나는 IDialogView 구현에 있고 마지막으로 다른 하나는 IDialogViewModel에 있습니다. 나는 MVVM이 그런 사치스러운 해커로부터 우리를 구할 것이라고 생각했습니다!

이 문제에 대한 경쟁 솔루션을 가진 여러 사람들이 있으며 모두 해킹이며 깨끗하고 쉽게 재사용 가능하며 우아한 솔루션을 제공하지 않습니다. 대부분의 MVVM 툴킷은 대화 상자를 무시하고 처리 할 때 사용자 지정 인터페이스 나 뷰 모델이 필요하지 않은 경고 상자 일뿐입니다.

나는 MVVM 뷰 패턴, 적어도 그것의 정통 구현을 포기할 계획입니다. 어떻게 생각해? 문제가 있다면 그만한 가치가 있었습니까? 나는 단지 무능한 프로그래머입니까, 아니면 MVVM이 과장된 것이 아닌가?

---

내 대답이 조금 길어지면 미안하지만 나를 비난하지 마십시오! 귀하의 질문도 길다.

요약하면 MVVM은 무의미하지 않습니다.

명확한 사례는 모달 대화 상자에 대한 지원을 추가하는 것입니다. 올바른 방법은 대화 상자를 표시하고이를 뷰 모델에 연결하는 것입니다. 이것을 작동시키는 것은 어렵습니다.

네, 정말 그렇습니다.
그러나 MVVM은 UI의 모양과 논리를 구분하는 방법을 제공합니다. 아무도 당신이 모든 곳에서 그것을 사용하도록 강요하지 않으며 아무도 당신이 모든 것에 대해 별도의 ViewModel을 만들도록 당신의 이마에 총을 들고 있지 않습니다.

이 특정 예제에 대한 솔루션은 다음과 같습니다
. UI가 특정 입력을 처리하는 방법은 ViewModel의 업무가 아닙니다. View의 .xaml.cs 파일에 코드를 추가하여 대화 상자를 인스턴스화하고 DataContext와 동일한 ViewModel 인스턴스 (또는 필요한 경우 다른 항목)를 설정합니다.

MVVM 패턴의 이점을 얻으려면 애플리케이션 계층 전체에 걸쳐 여러 위치에 코드를 배포해야합니다. 또한 템플릿 및 람바 식과 같은 난해한 프로그래밍 구조를 사용해야합니다.

글쎄, 당신은 여러 곳에서 그것을 사용할 필요가 없습니다. 이것이 내가 그것을 해결하는 방법입니다.

• 보기에 XAML을 추가하고 .xaml.cs에는 아무것도 추가하지 않습니다.
• ViewModel 내부에 모든 앱 로직 (UI 요소로 직접 작동하는 항목 제외) 작성
• UI에서 수행해야하지만 비즈니스 로직과 관련이없는 모든 코드는 .xaml.cs 파일로 이동합니다.

MVVM의 목적은 주로 응용 프로그램의 논리와 구체적인 UI를 분리하여 UI를 쉽게 수정 (또는 완전한 교체) 할 수 있도록하는 것이라고 생각합니다.
다음 원칙을 사용합니다. View는 ViewModel에서 원하는 것을 알고 가정 할 수 있지만 ViewModel은 View에 대해 아무것도 알 수 없습니다.
WPF는이를 정확하게 달성하는 데 사용할 수있는 멋진 바인딩 모델을 제공합니다.

(BTW, 템플릿 및 람다 식은 올바르게 사용하면 난해하지 않습니다.하지만 원하지 않으면 사용하지 마십시오.)

머리를 긁적 거리며 화면을 응시하게 만드는 것.

네, 느낌을 알아요. MVVM을 처음 보았을 때 제가 느꼈던 바로 그 느낌입니다. 그러나 일단 익숙해지면 더 이상 기분이 나쁘지 않을 것입니다.

나는 약 상자가 잘 작동했습니다 ...

약 상자 뒤에 ViewModel을 배치하는 이유는 무엇입니까? 그게 중요하지 않습니다.

대부분의 MVVM 툴킷은 대화 상자를 무시하고 처리 할 때 사용자 지정 인터페이스 나 뷰 모델이 필요하지 않은 경고 상자 일뿐입니다.

예, UI 요소가 같은 창 또는 다른 창에 있거나 현재 화성을 공전하고 있다는 사실은 ViewModels의 관심사가 아니기 때문입니다.
우려 사항 분리

편집하다:

제목이 Build your own MVVM framework 인 매우 멋진 비디오가 있습니다 . 볼 가치가 있습니다.

---

이것을 작동시키는 것은 어렵습니다. MVVM 패턴의 이점을 얻으려면 애플리케이션 계층 전체에 걸쳐 여러 위치에 코드를 배포해야합니다. 또한 템플릿 및 람바 식과 같은 난해한 프로그래밍 구조를 사용해야합니다.

For a commonplace modal dialog box? You are certainly doing something wrong there - MVVM implementation doesn't have to be that complex.

Considering you are new to both MVVM and WPF, it is likely you are using suboptimal solutions everywhere and unnecessarily complicate things - at least I did so when I first went WPF. Make sure that the problem is really MVVM and not your implementation before giving up.

MVVM, MVC, Document-View, etc. is an old family of patterns.. There are drawbacks, but no fatal flaws of the kind you describe.

---

I am in the middle of a quite complex MVVM development using PRISM so I already had to cope with this kind of concerns.

My personal conclusions:

MVVM vs MVC /PopUps & co

• MVVM is really a great pattern and in most cases it completely replaces MVC thanks to the powerful data binding in WPF
• Calling your service layer directly from the presenter is a legitimate implementation in most cases
• Even quite complex List /Detail scenarios may be implemented by pure MVVM thanks to the {Binding Path=/} syntax
• Nonetheless, when complex coordination between multiple views needs to be implemented, a controller in mandatory
• Events may be used; the old pattern which implies storing IView (or AbstractObserver) instances in the controller is obsolete
• The controller can be injected in each Presenter by IOC container
• Prism’s IEventAggregator service is another possible solution if the only use of the controller is event dispatching (in this case it can completely replace the controller)
• If views are to be dynamically created, this is a very well suited job for the controller (in prism the controller will get injected (IOC) a IRegionManager )
• Modal dialog boxes are mostly obsolete in modern composite applications, except for really blocking operations like mandatory confirmations; in these cases modal activation can be abstracted as a service called inside the controller, and implemented by a specialized class, which also allows for advanced presentation-level unit testing. The controller will, for example, call IConfirmationService.RequestConfirmation(“are you sure”) which will trigger a modal dialog display at runtime and can be easily mocked during unit testing

---

I deal with the dialogs issue by cheating. My MainWindow implements an IWindowServices interface that exposes all of the application-specific dialogs. My other ViewModels can then import the services interface (I use MEF, but you could easily just pass the interface through constructors manually) and use it to accomplish what is necessary. For instance, here is what the interface looks like for a little utility application of mine:

//Wrapper interface for dialog functionality to allow for mocking during tests
public interface IWindowServices
{
    bool ExecuteNewProject(NewProjectViewModel model);

    bool ExecuteImportSymbols(ImportSymbolsViewModel model);

    bool ExecuteOpenDialog(OpenFileDialog dialog);

    bool ExecuteSaveDialog(SaveFileDialog dialog);

    bool ExecuteWarningConfirmation(string text, string caption);

    void ExitApplication();
}

This puts all of the Dialog executions in one place and it can be easily stubbed out for unit testing. I follow the pattern that the client of the dialog has to create the appropriate ViewModel, which they can then configure as needed. The Execute call blocks and afterward the client can look at the contents of the ViewModel to see the Dialog results.

A more 'pure' MVVM design may be important for a large application, where you need cleaner insulation and more complex composition, but for small to medium sized apps, I think a practical approach, with appropriate services to expose required hooks, is quite sufficient.

---

Design patterns are there to help you, not hinder. A small part of being a good developer is knowing when to "break the rules". If MVVM is cumbersome for a task and you have determined the future value isn't worth the effort, then don't use the pattern. For example, as other posters have commented, why would you go through all the overhead to implement a simple about box?

Design patterns were never intended to be dogmatically followed.

---

As the pattern itself MVVM is great. But WPF's control library shipped with NET 4.0 data binding support is very limited, it is a lot better than WinForm, but still it's not enough for bindable MVVM, I would say it's power is about 30% of what is needed for bindable MVVM.
Bindable MVVM : it's UI where ViewModel is wired with View only using data binding.
MVVM pattern is about the object representation of the ViewState, it doesn't describe how you maintain the sync between View and ViewModel, in WPF it's data binding but it can be anything. And actually you can use MVVM pattern in any UI toolkit which support's events\callbacks, you can use it in pure WinAPI in WinForms (I did, and it's not much more work with events\callbacks), and you can even use it in Text Console, like rewrite DoS's Norton Commander using MVVM pattern.

In short: MVVM is not pointless, it's great. NET 4.0 WPF's control library is trash.

Here is the simple proof of concept ViewModel which you can't data bind in pure MVVM manner using WPF.

public class PersonsViewModel
{
    public IList<Person> PersonList;
    public IList<ColumnDescription> TableColumns;
    public IList<Person> SelectedPersons;
    public Person ActivePerson;
    public ColumnDescription SortedColumn;
}

You can't data bind WPF's DataGrid column headers, you can't data bind selected rows, etc etc, you will either do it in code simple way, or write a 200 lines of XAML hack code for these 5 lines of simplest ViewModel. You can only imagine how things get worser with complex ViewModels.
So the answer is simmple unless you are writing Hello World application, using bindable MVVM in WPF is pointless. You will spent most of your time thinking on hack to bind you ViewModel. Data binding is nice but be ready to fallback to event's 70% of time.

---

No, it’s not pointless, but it is difficult to wrap your head around even though the pattern itself is ridiculously simple. There are tons of misinformation out there and various groups who battle over the proper way. I think with WPF and Silverlight you should use MVVM or you’ll be over coding and attempting to solve problems in a new model the “old” win forms methodology which just leads you into trouble. This is more the case in Silverlight since everything is required to be asynchronous (hacks around this are possible, but you should just pick another platform).

I’d suggest reading this article Simplifying the WPF TreeView by Using the ViewModel Pattern carefully to see how MVVM can be implemented well and allow you to change your win forms mentality to the new way of thinking in MVVM. In short when you want to get something done apply the logic to the ViewModel first not the View. You want to select an item? Change an icon? Don’t iterate over UI elements, just update the models properties and let data-binding do the nitty gritty.

---

I have seen the same issue with a lot MVVM implementations when it comes to (modal) dialogs. When I look at the participants of the MVVM Pattern then I have the feeling that something is missing to build a coherent application.

• View contains the specific GUI controls and defines the appearance of the user interface.
• ViewModel represents the state and behavior of the presentation.
• Model can be a business object from the domain layer or a service which provides the necessary data.

But missing is:

• Who creates the ViewModels?
• Who is responsible for the application workflow?
• Who mediates between ViewModels when they need to communicate with each other?

My approach is to introduce a (Use-Case) Controller which is responsible for the missing points. How this works can be seen at the WPF Application Framework (WAF) sample applications.

참고URL : https://stackoverflow.com/questions/2798447/is-mvvm-pointless