|
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.
|
|
|
|
|
Annie - do you have a background in ASP.NET? If you do, try to think in terms of how that works, rather than the way WinForms works. It really helps you to understand XAML if you approach it from the markup side.
|
|
|
|
|
No. I've never done any ASP.NET. But, thanks for the advice about learning the markup. I was getting a bit confused as Nathan provides a lot of the C# code and wasn't sure which way to go.
I'm just going to dive in as I have a small project I need to start today which will involve quite a lot of data binding. I'll come here if I need help! Thanks for the support.
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 kewl  . Buy the book Wednesday, start the project Friday. I definitely like your style
When I was a coder, we worked on algorithms. Today, we memorize APIs for countless libraries — those libraries have the algorithms - Eric Allman
|
|
|
|
|
Read my tag-line
It’s not because things are difficult that we do not dare, it’s because we do not dare that things are difficult. ~Seneca
|
|
|
|
|
He who dares, wins! You sound like a winner. Go for it, I say. Oh, and good luck with the project.
When I was a coder, we worked on algorithms. Today, we memorize APIs for countless libraries — those libraries have the algorithms - Eric Allman
|
|
|
|
|
Her tag should actually read "she who dares bakes"
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
