MVVM Best Practices
Vložit
- čas přidán 27. 08. 2024
- In this episode, recorded at TechEd in Houston, Robert is joined by Brian Lagunas of Infragistics, who shares with us best practices for building applications using MVVM. Brian starts off by reviewing what MVVM is and what it isn't. He then demonstrates several things you should not do and why you should not do them. In addition to the demos, Brian gives his advice on how he approaches some common scenarios. For more see channel9.msdn.c...
Brian, I appreciate all of your content, super helpful. One question, I've read conflicting feedback about is in regards to POCO classes containing INotifyPropertyChanged. Is there any reason not to implement this interface in my data objects? I notice you had property notification on your Person class.
I should clarify. Today, I'm going to save my "Library" which contains lists of different objects using serialization. But at some point, I would like the ability to save my objects to a database using Entity. That's more where things get fuzzy for me. All the examples I've seen, "DTO?" objects only have simple setters and getter properties.
Sorry for the late reply, I don't get notifications unless I am tagged because I don't own this channel. Great question, but the answer comes down to the heavily used dev answer to anything.... "it depends". Your decision to have your POCOs implement INPC comes down to your architecture. I will simply say that I have always had my business objects implement INPC. I also never use my business objects as EF objects or vice-versa.
If Facade is not MVVM, how do we correctly update the model from the view model in MVVM?
Let's say my customer wants to change my data models... for example add or remove more properties in a data model... If I'm not suppose to change a class once it's finished... what should I do... The customer asks to add and remove multiple fields over the months as even he isn't sure about what the fields should be... How do I deal with this ?
Question for Brian: In 21:37 You said that CustomCommand is bad and we don’t want to use it. Instead you recommended RelayCommand or DelegateCommand - part of MVVM toolkits: Light and Prism. In 40:10 you said, you don’t need these toolkits. I don’t get it. Have you rewrite you own concrete ICommand implementation? Or copy-pasted from prism?
+Don'tBeEvil I recommended you use an implementation of ICommand like a RelayCommand or DelegateCommand that some libraries ship with. You don't have to use those libraries. You can use your own implementation instead. If you want to use those libraries, go for it. I personally use Prism's DelegateCommand that is available from the Prism.Core NuGet package.
Brian Lagunas Thanks for repley! From the whole framework I just copied ICommand implementation (but only the needed part), named it "ActionCommand" and "ObservableObject". And that's it. So I thought, I'm doing it wrong. But that's what you meant, right?
+Don'tBeEvil There is no "doing it wrong". You do what works for you and your application's needs.
+Brian Lagunas I just finished a CZcams tutorial that first created a WPF application and they create 2 more projects that are Class Libraries ViewClass and ViewModel. I have watched a few more tutorials, including this and you don't do it that way, you have it really all in one application. I believe that the first one I watched may have been for n-Teir if you have several different front-ends to do. What is the correct way and can I use prism with the class libraries method?
Greate job! Thanks
I know that video is old but isn't exposing a model called Person into the view via property basicly breaking the entire separation principle that MVVM is about?
No, it's not.
@@BrianLagunas I have seen many discussions about this on stack and to be honest I was never 100% sure due to conflicting opinions. I know this exposure is not always possible, but it usually it makes code simpler and easier to understand.
@@Vulver what exactly are you gaining by wrapping every model property into more individual properties in another object?
@Brian Lagunas I've never said I do. I said it is not always possible, you can work with existing models and you do not want touch them.
Yet I used to do that, not all properties, but the one I need but after some time I relized it is just code duplication.
I was never 100% sure if exposing model is ok, this is how I found this video. Many MVVM examples are oversimplified which causing some dilemmas when writing more complex code. Some other are just wrong.
@@Vulver exposing the model as a property is 100% okay. In most apps, the models represent the domain of the app. Models are rarely shared, and I question if they even should be, across multiple different apps. In cases where you don’t control the object, then yes you must wrap the object in a facade or even an adapter to make it fit your app needs. However, the majority of the time that is not needed.
Captions! Both speakers talk at 1.25-1.5 rate of speed.
great
what ever you still need coding
C# sucks
+James Rockford any reason why?
John Demetriou
It's wasn't a bad language at fiest, but now it's way too bloaty with useless and redundant features. also it is slow at runtime.
+James Rockford it's an alternative to Java and compared to Java it's a much more robust, fast and useful language. and portability is coming. And given that with C# OS portability is being done carefully and step by step, things will be a lot better. I mean already in windows C# beats it's competitor any given day, and this is soon coming to all other OSes
John Demetriou Sure, yes it is much better than Java which is horrible
Don't see why, I think C# is a great language