WPF best practices



  • So, I'm making an app using WPF. I try to adhere to the MVVM model, but I find it increasingly difficult with every line. Some common things seem outright impossible to do. And none of the tutorials I've seen addresses any of these design problems I have - which I find weird considering it's very basic stuff.

    1. Since ViewModel isn't supposed to know about window, and all actions should be mapped to ViewModel commands... How do you implement "Close" button?

    2. I have a button that should spawn a dialog window. The dialog's purpose is to ask the user about some data needed in main window. Who creates the dialog, how do I pass a parent window to it (because I need a parent window for proper dialog placement), and how do I return the data back? It's all trivial until you remember ViewModel doesn't know about the window it belongs to.

    3. Where's the boundary between Model and ViewModel? How strict the boundary should be? What should the interface between ViewModel and Model look like? Does every app need Model objects separate from ViewModel objects? Asking because I've made a couple small apps in WPF and contained most of my logic in ViewModels, and the rest in static methods.



  • @gąska said in WPF best practices:

    1. Since ViewModel isn't supposed to know about window, and all actions should be mapped to ViewModel commands... How do you implement "Close" button?

    With DelegateCommands?



  • @rhywden said in WPF best practices:

    @gąska said in WPF best practices:

    1. Since ViewModel isn't supposed to know about window, and all actions should be mapped to ViewModel commands... How do you implement "Close" button?

    With DelegateCommands?

    Only if you've purchased their WPF controls.



  • @parody said in WPF best practices:

    Only if you've purchased their WPF controls.

    0_1514742627619_78563b3b-b79e-4adb-a6bb-aa1dbab32efd-image.png

    Surprisingly, it seems no one wants to talk about your WPF best practices or my CRUD form design patterns during New Years Eve.

    Seriously, what's wrong with people? It's not like there is anything better to do.


  • Impossible Mission Players - A

    @cartman82 said in WPF best practices:

    not like there is anything better to do.

    Sleep?



  • @rhywden said in WPF best practices:

    @gąska said in WPF best practices:

    1. Since ViewModel isn't supposed to know about window, and all actions should be mapped to ViewModel commands... How do you implement "Close" button?

    With DelegateCommands?

    You mean, I should create a command that accepts arbitrary Window as parameter, and calls Close() on this arbitrary window? It doesn't sound right. Is it how it's done in professional apps? Also, there's another action that does the important work and also closes the window. Should it receive window as parameger too? This would mean that VM has access to window basically all the time.

    @parody said in WPF best practices:

    @rhywden said in WPF best practices:

    @gąska said in WPF best practices:

    1. Since ViewModel isn't supposed to know about window, and all actions should be mapped to ViewModel commands... How do you implement "Close" button?

    With DelegateCommands?

    https://documentation.devexpress.com/WPF/17353/MVVM-Framework/Commands/Delegate-Commands

    Only if you've purchased their WPF controls.

    Don't worry, Prism has the exact same thing absolutely for free.



  • @parody said in WPF best practices:

    Only if you've purchased their WPF controls.

    Wah? That was an example. DelegateCommands (or rather, ICommand) are pretty much a stock of MVVM in C#.



  • @gąska said in WPF best practices:

    @rhywden said in WPF best practices:

    @gąska said in WPF best practices:

    1. Since ViewModel isn't supposed to know about window, and all actions should be mapped to ViewModel commands... How do you implement "Close" button?

    With DelegateCommands?

    You mean, I should create a command that accepts arbitrary Window as parameter, and calls Close() on this arbitrary window? It doesn't sound right. Is it how it's done in professional apps? Also, there's another action that does the important work and also closes the window. Should it receive window as parameger too? This would mean that VM has access to window basically all the time.

    I'm not sure why you think that your ViewModel isn't supposed to know about the UI. I'm using Prism and my ViewModel has access to all objects in its corresponding View through its DataContext.



  • @rhywden said in WPF best practices:

    @parody said in WPF best practices:

    Only if you've purchased their WPF controls.

    Wah? That was an example. DelegateCommands (or rather, ICommand) are pretty much a stock of MVVM in C#.

    Then why not link to MSDN somewhere rather than something proprietary? Your response looked to me like a bad search-and-paste. 🤷

    Unofrtunately, my experience is with WinForms (including a little with the DevExpress WinForms controls) so I don't have good advice for the actual questions.


  • Discourse touched me in a no-no place

    @gąska said in WPF best practices:

    It doesn't sound right. Is it how it's done in professional apps?

    Only the more competently-written ones.



  • There are ways to handle all of them [I agree many are not obvious].

    One (not only) technique is for the VM to have an event. When the V registers for the event and takes the action. Thus the VM knows nothing about the V, but the V knows what the VM "wants"



  • @parody DelegateCommand isn't part of standard WPF library. It's a piece of code that gets copy-pasted everywhere (sometimes named RelayCommand).



  • @dkf said in WPF best practices:

    @gąska said in WPF best practices:

    It doesn't sound right. Is it how it's done in professional apps?

    Only the more competently-written ones.

    I'm afraid to ask how it's done in less competently-written ones.



  • @thecpuwizard said in WPF best practices:

    There are ways to handle all of them [I agree many are not obvious].

    One (not only) technique is for the VM to have an event. When the V registers for the event and takes the action. Thus the VM knows nothing about the V, but the V knows what the VM "wants"

    The other idea would be to register the Window instance in the IOC container and get the reference from there anytime you need it. Subscribing to an event only really works if the object is "live".



  • @rhywden said in WPF best practices:

    The other idea would be to register the Window instance in the IOC container and get the reference from there anytime you need it.

    If the View Model accesses the View (Window Instance) - even via an IOC container, then the pattern is broken [you are not doing MVVM].

    The View, always knows about the View Model that it is attached to. It even gets notifications on Change. So it is 100% reliable (and easy) to have the View attach to an event in the View Model.

    If necessary, the View Model can determine if "something" is listening, but is completely oblivious (and this is good) as to who/what it is.



  • @thecpuwizard said in WPF best practices:

    @rhywden said in WPF best practices:

    The other idea would be to register the Window instance in the IOC container and get the reference from there anytime you need it.

    If the View Model accesses the View (Window Instance) - even via an IOC container, then the pattern is broken [you are not doing MVVM].

    The View, always knows about the View Model that it is attached to. It even gets notifications on Change. So it is 100% reliable (and easy) to have the View attach to an event in the View Model.

    If necessary, the View Model can determine if "something" is listening, but is completely oblivious (and this is good) as to who/what it is.

    Then you access the ViewModel attached to the Window. Geeze. undefined Because letting the View listen to events from another ViewModel would also be against the pattern...

    ... but you may want to tell your objections to the authors of the Prism framework, by the way.



  • @thecpuwizard The further I think about this, the less I like "View listens to broadcast events".

    Isn't the point of MVVM to separate concerns? I.e. the View is only responsible for displaying the state and the ViewModel is the sole custodian of said state (i.e. business logic). Letting the View listen to events means that it's suddenly also responsible for the state again.



  • @rhywden said in WPF best practices:

    @thecpuwizard The further I think about this, the less I like "View listens to broadcast events".

    Isn't the point of MVVM to separate concerns? I.e. the View is only responsible for displaying the state and the ViewModel is the sole custodian of said state (i.e. business logic). Letting the View listen to events means that it's suddenly also responsible for the state again.

    I hear that concern pretty often, but I look at it as the View is ALWAYS listening to the View Model... What do you think Dependency Properties, or INotifiyChange or .... are?


  • Discourse touched me in a no-no place

    @gąska said in WPF best practices:

    @dkf said in WPF best practices:

    @gąska said in WPF best practices:

    It doesn't sound right. Is it how it's done in professional apps?

    Only the more competently-written ones.

    I'm afraid to ask how it's done in less competently-written ones.

    0_1514757521643_8b85c9ed-7721-44aa-a931-66031d37e6be-image.png

    A common antipattern is to make one gigantic handler that deals with all possible events coming in (with no delegation to components or anything sensible like that). I think it tends to come about because that's how the absolutely base level of GUIs works, but that's not really how anyone sane actually does things (they layer some sort of dispatch delegation mechanism on top to make the systems that you normally see so that you get automatic separation by component and type of event).



  • @dkf said in WPF best practices:

    A VERY common antipattern

    Fixed!!!!

    Seriously, it is out of control (pun intended) in so many UI's. People think (sometimes) about factoring their code, but rarely their UI.

    Properly designing a UI seems so rare....


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.