|
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
|
|
|
|
|
That's a fair point and something that is absolutely not covered by WPF Unleashed.
If you find a similarly well-written book about MVVM, I'd be interested.
|
|
|
|
|
I learnt WPF from that book. It's a very good starting point and I often find myself going back to it when I need a reminder.
Not too dry and lots of examples and pictures which are a must when you are trying to explain the visual aspects of WPF.
|
|
|
|
|
Thanks. Yes, I'm already getting into it. One of the things I really like - in addition to what you mentioned - is that he gives the equivalent code in C# to the XAML. That really helps me learn and 'see' what's happening. I know it's a huge subject and I'm now just going to jump straight in.
It’s not because things are difficult that we do not dare, it’s because we do not dare that things are difficult. ~Seneca
|
|
|
|
|
Honestly, and this is kind of my opinion about most programming books... they are usually structured in the same way:
Chapter 1: Feature X
Short Summary of Feature X
A few small examples that cover 13% of Feature X
Chapter 2: Feature Y
Short Summary of Feature Y
A few small examples that cover 9% of Feature Y
etc.
They never really show how features X & Y are inter-related or how they are important in the big picture.
I've never written a book myself, but I think if I were to write a WPF MVVM book, it would be something like "In this book we are going to write Application.exe from start to finish... we will cover all the design and architecture issues and show you how all the pieces come together with detailed explanations. In the end, you'll end up with a light weight MVVM framework that you can use on other applications".
That seems common sense to me... rather then giving you a bunch of random snippets about random features.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
