|
When I adopted .Net back in 2008, I wrote a CP article around a game I wrote called Anagrams. Given my recent re-introduction to WPF, I figured it would be interesting to rewrite that application using WPF, along with MVVM. I am nearing completion of the app, and was curious to see how much MVVM could simplify the code on the front end (mostly because I realized that I wasn't modifying the window code much), and was amazed to see that there are less than 150 lines of code in the main windows class (the original version required 272 lines in the main form file). I still haven't written the timer code or adding the configuration stuff, but none of that should add appreciably to the main window cs file.
I guess you could call MVVM an effective method for simplifying the code, at least on the user interface side.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997
|
|
|
|
|
I definitely think you are right. However I think its much more efficient way of designing the layout of an application than WinForms, not to mention the ease the design team were they now could do while you are constructing the code behind. That must have been a real nightmare in WinForms...
|
|
|
|
|
When you say "in the main windows class" are you talking the 'code behind' cs file of your view?
If so, be prepared to be flamed for having any code there at all!
|
|
|
|
|
Yes, that's what I meant, and the code in that file merely kicks things off for a game. Everything else is handled in the view model, even the timer thread.
And I was correct about the timer code - there was no code added at all in the window.cs file.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997
|
|
|
|
|
John Simmons / outlaw programmer wrote: the code in that file merely kicks things off for a game.
Old habits linger on. 
|
|
|
|
|
All it does is create the DataContext.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997
|
|
|
|
|
John Simmons / outlaw programmer wrote: All it does is create the DataContext.
Like I said, old habits linger on.
|
|
|
|
|
I really don't understand what your point is. When a user interface has controls that require interaction from the user, exactly HOW does one NOT put code in the cs file?
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997
|
|
|
|
|
Putting logic in the view violates the principle of separation of concerns and makes it impossible to write automated tests for that logic.
Of course you can still manually test that logic by interacting with the view, but I prefer to automate my testing before I write the code to accomplish the desired goal.
How to do it specifically should not be addressed in the lounge. Perhapse you should ask the question of how to accomplish this in another forum.
modified 8-Oct-12 10:35am.
|
|
|
|
|
Hi Khun Jimmy,JimmyRopes wrote: Putting logic in the view violates the principle of separation of concerns and makes it impossible to write automated tests for that logic.
I am curious about the above statement: the principle of "separation of concerns" has been around a long time in computer science, and has a meaning quite independent of MVC, MVVM "design philosophy."Of course you can still manually test that logic ... snip ... How to do it specifically should not be addressed in the lounge. Perhapse you should ask the question of how to accomplish this in another forum. How about you writing an article for CP that explains/demonstrates what you mean, and gives examples, demonstrating the value of what you advocate, and how it enables testing automation, etc. ?
best, Bill
~
Confused by Windows 8 ? This may help: [ ^] !
|
|
|
|
|
Sa wat dii krap kuhn Bill;
BillWoodruff wrote: I am curious about the above statement: the principle of "separation of concerns" has been around a long time in computer science, and has a meaning quite independent of MVC, MVVM "design philosophy."
Yes it has and has been incorporated, more recently, into MVC and MVVM. What I was trying to say was that if you code application logic into the view you will not be able to automate the testing of that logic.
I try to have test cases for all logic in the application so I can actively test to see that the code I write is implementing the specified application. Additionally, if I make changes to the application I can run the automated test suite to see if the change in fact worked and if it caused any unintended consequences (unadvertised features if you will).
I do admit that I need to mock the user input to accomplish this but it is better than manually testing through the UI as manual testing is sometimes NP Complete unless you follow a scripted test sequence religiously. More often than not a developer will just test to see that the logic just added works and not so much that all previous logic still functions properly.
BillWoodruff wrote: How about you writing an article for CP that explains/demonstrates what you mean, and gives examples, demonstrating the value of what you advocate, and how it enables testing automation, etc. ?
I don't see that happening in the next year because I am under contractual agreement to not disclose information related to the work I do for the client, and am too busy to make up a project outside of work to use in an article.
My target date for giving it all up and moving back home is next year, ga ra ga daa khohm 2556. Maybe when I settle in at home I will have more time to write an article.
|
|
|
|
|
Look forward to your CP article on comparing your WinForms and WPF implementation !
I wonder: of that 272 lines of code in the WinForm version main form file: how much of that ... let's call it the "logic of the app;" roughly equating that with the "model" in MVVM (which might be a serious error of unwarranted assumption) ... could have been placed in a separate class (perhaps static ?).
best, Bill
~
Confused by Windows 8 ? This may help: [ ^] !
|
|
|
|
|
BillWoodruff wrote: I wonder: of that 272 lines of code in the WinForm version main form file: how much of that ... let's call it the "logic of the app;" roughly equating that with the "model" in MVVM (which might be a serious error of unwarranted assumption) ... could have been placed in a separate class (perhaps static ?).
That also doesn't count the code I had to write to create the custom ListBox and custom ProgressBar (I think I downloaded this) controls. I didn't have to do either of those things with the WPF side, although for the progressbar, I had to edit the template.
Another applicable fact is that I was real new to .Net programming when I did the WinForms version. All in all, I spent a lot less time coding the app this time around.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997
|
|
|
|
|
John,
Well, of course you would probably write code in WinForms now, after years of experience, in a different, and probably better structured, way. So, is comparing WinForm code from years ago with WPF code written now really comparing "apples to oranges" ?
I am not an MVVM, or MVC, "apostle," and consider it perfectly appropriate to have the code that deals with interactions with controls "right there," in most cases.
And, I consider those who nit-pick about how Windows Forms doesn't equate to MVC to be generally people (often infatuated with WPF and XAML) who don't realize it does: the "view" is analogous to what is in the Designer.cs file, the Form.cs and UserControl.cs files are analogous to both the "controller" and "model" concept in MVC, etc.
Where it "pays" to implement MVC, in the more formal sense (which can be simulated in Windows Forms easily), in my humble opinion, is where you have more than one "view." And, many applications do not have more than one view.
The ideas of "one data, many views," and separation of data from view, has been around forever (I was talking that talk in 1986, and I got "infected" with it from SmallTalk which had been around since the 1960's).
The fact that WPF lets you (requires you to) shuffle code around so it's relocated, and more "compartmentalized," and makes you use the equivalent of an almost hieroglyphically opaque short-hand (XAML), to describe the ui, and to perform binding, is, to me, its fatal deficit.
Have you ever seen highly commented XAML ? "Maintainable XAML:" there's an oxymoron. That XAML survives in Win 8, RT, etc., gives me the willys 
imho, less code is not a good metric to judge code quality (which includes maintainability, degree to which code is self-documenting, or is documented, etc.). APL (and LISP, and ye olde Forth) lets you write a few lines of code that have unbelievable complexity in what they do when executed: those few lines of code will also require any user of the code who wishes to understand it (or, god forbid, to modify it) to spend as much time figuring out how it works, as the original developer spent figuring out how to implement it (unless its accompanied by reams of documentation).
By the way, imho, what was, and remains, the Designer.cs files in WindowsForms, should have been XML to begin with (in fact, I assume what we see in the Designer.cs files is a rendering of an underlying internal structure that could easily have been rendered as XML).
Now, you know all my biases
best, Bill
~
Confused by Windows 8 ? This may help: [ ^] !
|
|
|
|
|
First, you explain stuff vaguely. Only from comments I guessed original application was in WinForms. Well, but it makes situation worse: you compare apples to oranges! How at all you can match WinForms (which keeps everything in *.cs) with WPF where a lot of actions programmed inside WPF library and exposed thru declarative XAML?? Relax, we don't need your persuades "how MVVM is cool". If you persuade yourself, you double waste a time.
|
|
|
|
|
I think you're comparing technologies, not paradigms. In essence, one could use MVVM with WinForms too. OTOH, if your only metric is code size, IMO it would be fair to compare the mosts compact solutions with both technologies, and IMO if you write everything inside the UI files WinForms could deliver a more compact or at least equally compact solution. If code size isn't the only metric, what are the others? I don't mean to say that WinForms is better or than WPF is better, I'm just saying that your enthusiasm for WPF, at least from what you're telling us, may be unfounded.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
