|
I do not see any difference between WPF and VMMV. I know technically there is but from a practical matter I open Visual Studio, select the language, and WPF project. That is WPF; that is the default VMMV. To me they are the same. That has been a moving target.
Case in point, DataGrid was not in VS2008 but is in VS2010. There were several versions of DataGrid before that and in an SDK. I find comments that even different revs of SDK had slight changes in DataGrid. Now we have VS2010 and it is even different yet. A moving target. All examples of DataGrid not done in VS2010 are useless. There are lots more examples.
I really agree with you comment about isolated examples not being very useful. It seems every time I try to combined things it blows up in WPF. It did not do that in Windows Application in either C++ or VB. I started with VS version 4 VB. Did C++ for many years. When .Net came along I when back to VB. It was just as structured as C++ by then. I got tired of all the extra punctuation and lines and brackets. The examples worked well then. They seemed easy compared to WPF.
|
|
|
|
|
Not at all. Winforms is pretty much managed MFC. You do things in the same exact way. You subscribe to events, intertwine business and UI logic, make things public as workarounds, global variables, etc. You *can* write WPF like that just fine. That is not MVVM. MVVM introduces architectural design patterns. It seperates UI from business logic pretty much completely. Also, you are doing everything via data-binding. If you are doing full blown proper MVVM, you are also delving into lots of the more advanced concepts like Dependency Injection, Services, Service Locator, etc. With Visual Studio 2010 and .NET 4.0, you can't do MVVM "out of the box" because the infrastructure support is not there. You need to add a 3rd party MVVM library or write your own.
-- modified 29-Sep-11 15:56pm.
|
|
|
|
|
I read some articles writen by Microsoft people and I think they would dissagree with you. But, they think VS is the answer to all things.
|
|
|
|
|
How so? What exactly are you disagreeing with? WPF is not MVVM. MVVM is not WPF. Nor is MVVM supported out of the box with no additional libraries or code. Microsoft doesn't claim to support MVVM with Visual Studio 2010. They just recommend you write WPF & Silverlight code in that style. Where is RelayCommand<T>? Where is your ServiceLocator or DI container? Where is Messenger? Those are not part of .NET at this time. Why do you think there are 10+ MVVM frameworks out there? Cinch by Sasha Barber is a popular one, MVVMLight, etc. Heck... even Microsoft itself has a library called Prism, although thats not purely an MVVM library, thats more on the MEF side of things.
You will find REALLY quickly, that if you are doing MVVM, you need a lot of support code.
For a simple example:
How do you close a dialog from the ViewModel? Normally, you just set DialogResult = true right? Too bad DialogResult is not accessible from the ViewModel  . Oh wait, guess what? Its not a bindable property either! So you can't bind it to something in your ViewModel. Guess you need some additional (3rd party) code to do that . If you google that, you'll find that what everybody is doing is using attached properties in a framework.
Another example where VS2010 does not support MVVM out of the box:
How does ViewModel1 communicate with ViewModel2? They aren't supposed to know about each other. Hmm... guess you need some sort of Messenger implementation for that. Too bad .NET 4.0 doesn't have one .
Yet another item:
How do you forward control events to the ViewModel? Thats not supported out of the box either... Darn... guess I need some additional generic code to do that .
|
|
|
|
|
I reread the article:
http://msdn.microsoft.com/en-us/magazine/dd419663.aspx
I understand your "technical" view but my statements about a "practical mater" still stand.
Maybe my opinion comes from the type of programs I write. I do the glue. I start with two or more pieces of equipment and/or software that need to work together and do something the customer wants. They were not intended to work that way. I glue them together. I often name my programs DuckTape. Often it is just as much a UI as it is communications but always I am quickly in and out of a project.
I wonder how many people use a VMMV?? I doubt it is a majority.
|
|
|
|
|
Lol... pretty much everybody who writes WPF uses MVVM. Why do you keep calling it VMMV? WPF and MVVM go hand in hand. As I said, its not required, but its highly recommended by Microsoft.
If you are just hacking together quick apps, then yeah, MVVM is overkill. WPF is kind of overkill too. You could probably whip out a quick "DuckTape" app quicker with Winforms.
-- modified 29-Sep-11 18:30pm.
|
|
|
|
|
Winforms are quicker but I got board wanted to try something new. Also, you always need to keep learning.
VMMV. MVVM. Dyslexia I guess,
|
|
|
|
|
I see you've pointed to Josh Smiths excellent article on MVVM. FYI - Josh does not work for Microsoft. MVVM and WPF go hand in hand - in a large part, WPF was designed to be able to support MVVM. The problem is that people have it in for MVVM because they think that
a) you HAVE to use it for WPF; you don't, but it certainly makes it easier if you do
b) MVVM is complicated; it's no more complicated than other patterns
c) MVVM is all you'll need; it's not - MVVM is supported by a whole slew of other things such as IoC, DI, Service Location, Mediator/Messenger - all of which are well documented in their own right. More importantly, if you use another pattern such as MVC, you still end up having to use a lot of these techniques.
If you're knocking up a quick one off application for yourself, then MVVM is overkill. If you are intending to produce a professional application that has the model and UI interaction logic in a form that can be tested using good programming practice, then MVVM is perfect for you.
|
|
|
|
|
What I write works, customers are happy with it, they pay me a lot of money for it. What is not professional about that?
|
|
|
|
|
So you don't unit test your code?
|
|
|
|
|
There are lots of people and companies that slap stuff together and make it work. He already admitted thats what he does. There is certainly a market for it. Lots of people in mgmt or not technical positions believe that it is better to slap something together in a week that "works" vs. writing a well engineered solution that would take a month or two. I am seeing this more and more in the companies I work for  .
You certainly don't get rewarded or appreciated when you take 2x as long as the other guy, but your code is much better underneath. The other guy that cranked out a hack will be the hero. Sad, but true.
|
|
|
|
|
How would I know if it worked if I did not test it????
There is a an axiom about debugging code. "The only program in which you will no longer find bugs is that which is obsolete and no longer used."
|
|
|
|
|
So how are you automating your interaction logic tests to ensure it works? Are you unit testing your code behind with a standard test tool?
|
|
|
|
|
There are lots of ways to test things. Automated testers and dedicated testing tools are not always necessary. Methods depend on the complexity of the project. Ultimately it comes down to the user and that is the final test. Even if the code preforms perfectly and does everything ask for, if the user cannot understand how to make it work it has failed. Being facetious, I find my grade school children and friends work best for this testing.
|
|
|
|
|
Hmmmm. Okayyyyyy. I guess we have different standards by which we determine things as being "professional". If it works for you, then fine - feel free to ignore MVVM because your way of working is completely the opposite to the way that MVVM has been designed to support.
|
|
|
|
|
What if somebody has to go in and make changes? If your code is not maintainable, that is not a good thing.
|
|
|
|
|
Why do you think quality and maintainability have to do with speed? Some of the best pieces of code I have seen are short, concise, simple, and easy to understand. Also, without a lot of extras there is less room for bugs.
There are 2 ways to deal with bugs. The first is to add a lot of code to handle them. The second is to look for the fundamental cause and figure out how to shorten the existing code. When you add more code it is more room for bugs. I find those that take a lot of time have much longer programs and usually more hidden bugs. The second method takes more thought. It can be hard to suppress knee jerk reactions. Surprisingly the second method in total takes less time.
|
|
|
|
|
michaelbarb wrote: All examples of DataGrid not done in VS2010 are useless.
That's not true. We have functionality that used the DataGrid in 2008 which behaves in exactly the same way in VS2010 without changing any code. How did we do this? We used MVVM.
|
|
|
|
|
Here is the example I was refering to.
WPF DataGrid Practical Examples[^]
I cannot get it to run in .NET 4.0 and VisualStudio 2010. Do not use the toolkit version of DataGrid. It is easy to get rid of references to the toolkit and make it go to the VS2010 version of DataGrid. I am not totally sure if the problem is with DataGrid. There are some other things going on with the SQL database. Still, the example will not load and run.
|
|
|
|
|
Just received this book today and good to see an endorsement from Pete (O'H), as well as Sacha Barber, on the inside cover. Is this the best book on WPF?
I'm determined not to go back to Windows Forms and find it interesting that everyone describes the learning 'cliff' as opposed to the learning curve. I'm always up for a challenge!
It’s not because things are difficult that we do not dare, it’s because we do not dare that things are difficult. ~Seneca
|
|
|
|
|
It's an excellent book. Adam takes the cliffyness away from getting to know WPF.
|
|
|
|
|
I wouldn't go back to MFC or Winforms after WPF. There is certainly a learning cliff and no book is going to take that away. Its just a whole different way of thinking. Winforms is pretty much just a managed version of MFC, so there isn't a curve at all once you know C#. WPF introduces a ton of new concepts and when you do WPF "the right way" and throw MVVM into the mix, its more an abyss then a cliff.
|
|
|
|
|
SledgeHammer01 wrote: more an abyss then a cliff
Hah, very encouraging. 
It’s not because things are difficult that we do not dare, it’s because we do not dare that things are difficult. ~Seneca
|
|
|
|
|
Well, I learned WPF the non-MVVM way and then learned MVVM later on. Now that I know both, I'd recommend learning both at the same time because non-MVVM WPF can be quite the mess.
|
|
|
|
|
Thanks.
It’s not because things are difficult that we do not dare, it’s because we do not dare that things are difficult. ~Seneca
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
