Binding is the new Spaghetti
-
Long ago before there were flow control and subroutine structures all we had only GoTo's. As a result it was really hard to follow the flow of the program. We had spaghetti code. I am currently working with a middle age programmer that has only worked with C# and WPF. Very little Windows forms. He has 15 years of WPF and is a better at it than I. But everything is binding. He hardly ever updates a control directly. Everything is binding. Working with his code you never know were things are going. It is like the new spaghetti.
So many years of programming I have forgotten more languages than I know.
-
Long ago before there were flow control and subroutine structures all we had only GoTo's. As a result it was really hard to follow the flow of the program. We had spaghetti code. I am currently working with a middle age programmer that has only worked with C# and WPF. Very little Windows forms. He has 15 years of WPF and is a better at it than I. But everything is binding. He hardly ever updates a control directly. Everything is binding. Working with his code you never know were things are going. It is like the new spaghetti.
So many years of programming I have forgotten more languages than I know.
-
Long ago before there were flow control and subroutine structures all we had only GoTo's. As a result it was really hard to follow the flow of the program. We had spaghetti code. I am currently working with a middle age programmer that has only worked with C# and WPF. Very little Windows forms. He has 15 years of WPF and is a better at it than I. But everything is binding. He hardly ever updates a control directly. Everything is binding. Working with his code you never know were things are going. It is like the new spaghetti.
So many years of programming I have forgotten more languages than I know.
I'm a "non-binder". Possibly a control-freak part of my nature but, when it comes down to it, everything thing is in-your-face. The closest I get to obscurity is using SQL Stored Procedures rather than hard-coding the TSQL.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
-
Long ago before there were flow control and subroutine structures all we had only GoTo's. As a result it was really hard to follow the flow of the program. We had spaghetti code. I am currently working with a middle age programmer that has only worked with C# and WPF. Very little Windows forms. He has 15 years of WPF and is a better at it than I. But everything is binding. He hardly ever updates a control directly. Everything is binding. Working with his code you never know were things are going. It is like the new spaghetti.
So many years of programming I have forgotten more languages than I know.
That's what makes WPF so powerful...binding. I'm currently working on a WPF project, and yes it takes time to wrap your head around it but once you do it's awesome.
The less you need, the more you have. JaxCoder.com
-
Long ago before there were flow control and subroutine structures all we had only GoTo's. As a result it was really hard to follow the flow of the program. We had spaghetti code. I am currently working with a middle age programmer that has only worked with C# and WPF. Very little Windows forms. He has 15 years of WPF and is a better at it than I. But everything is binding. He hardly ever updates a control directly. Everything is binding. Working with his code you never know were things are going. It is like the new spaghetti.
So many years of programming I have forgotten more languages than I know.
I already have my hands full with Qt slots/signals. Whoever #defines away a new language upon C++ is evil.
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
-
Long ago before there were flow control and subroutine structures all we had only GoTo's. As a result it was really hard to follow the flow of the program. We had spaghetti code. I am currently working with a middle age programmer that has only worked with C# and WPF. Very little Windows forms. He has 15 years of WPF and is a better at it than I. But everything is binding. He hardly ever updates a control directly. Everything is binding. Working with his code you never know were things are going. It is like the new spaghetti.
So many years of programming I have forgotten more languages than I know.
The nice thing about binding as a concept (not sure how it works with WPF specifically) is that it's declarative, or at least potentially declarative. That is, what it's connected to becomes part of its *schema* not its *logic* as such.. So instead of saying the progress bar has a value, you'd say the progress bar is bound to this background worker. it actually makes things make *more sense* in terms of designing flow, but it probably takes some getting used to. All of this with the disclaimer that I haven't really used WPF or its binding before. I just know the concept. ETA: I'm sure you could make spaghetti with it in complex enough project, but spaghetti is its own problem, IMO - you can end up with spaghetti designs in just about any coding medium.
Real programmers use butterflies
-
Long ago before there were flow control and subroutine structures all we had only GoTo's. As a result it was really hard to follow the flow of the program. We had spaghetti code. I am currently working with a middle age programmer that has only worked with C# and WPF. Very little Windows forms. He has 15 years of WPF and is a better at it than I. But everything is binding. He hardly ever updates a control directly. Everything is binding. Working with his code you never know were things are going. It is like the new spaghetti.
So many years of programming I have forgotten more languages than I know.
It's pretty powerful once you get used to it. And it's used pretty much everywhere now - Angular, Vue, etc. I prefer to have the code (logic) and view (semi)decoupled by using bindings. It's allowed me to re-use viewmodels with different views, where I would have had to duplicate logic.
-
Long ago before there were flow control and subroutine structures all we had only GoTo's. As a result it was really hard to follow the flow of the program. We had spaghetti code. I am currently working with a middle age programmer that has only worked with C# and WPF. Very little Windows forms. He has 15 years of WPF and is a better at it than I. But everything is binding. He hardly ever updates a control directly. Everything is binding. Working with his code you never know were things are going. It is like the new spaghetti.
So many years of programming I have forgotten more languages than I know.
The same thing happens in JavaScript when people use control.on("event").... instead of just putting the onclick into the html. It makes it a pain tracking down where the events are.
-
Long ago before there were flow control and subroutine structures all we had only GoTo's. As a result it was really hard to follow the flow of the program. We had spaghetti code. I am currently working with a middle age programmer that has only worked with C# and WPF. Very little Windows forms. He has 15 years of WPF and is a better at it than I. But everything is binding. He hardly ever updates a control directly. Everything is binding. Working with his code you never know were things are going. It is like the new spaghetti.
So many years of programming I have forgotten more languages than I know.
I'm starting learning C#/XAML in an existing project with lot of bindings. It's weird, but it works, update the list and the UI updates automagically.
I'd rather be phishing!
-
Long ago before there were flow control and subroutine structures all we had only GoTo's. As a result it was really hard to follow the flow of the program. We had spaghetti code. I am currently working with a middle age programmer that has only worked with C# and WPF. Very little Windows forms. He has 15 years of WPF and is a better at it than I. But everything is binding. He hardly ever updates a control directly. Everything is binding. Working with his code you never know were things are going. It is like the new spaghetti.
So many years of programming I have forgotten more languages than I know.
michaelbarb wrote:
But everything is binding
Exactly as designed, if you are going to get the most out of WPF you are going to have to get your head around binding. Tracking down an issue can be difficult but once you understand it then it does become simpler.
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
-
michaelbarb wrote:
But everything is binding
Exactly as designed, if you are going to get the most out of WPF you are going to have to get your head around binding. Tracking down an issue can be difficult but once you understand it then it does become simpler.
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
I believe everything in moderation. When binding first came out there were studies done that showed the performance cost of binding. Impact it less today but I am sure it is still there. For binding I use the "2 Up Binding Rule". If a parameter is used more then 2 places then I do binding in all of them. If you change a parameter that is used only once on the UI and the object is easily accessible then I just write to the control. Not only is it efficient but when you read the code you know immediately where it goes. For the "Up" part of the rule, if a child needs to access a UI object on the parent, binding is the best way to go. Some believe it is the only way since all the alternatives so messy. I always try and use the best tool for the job. I do not try and use a tool everywhere possible.
So many years of programming I have forgotten more languages than I know.
-
Long ago before there were flow control and subroutine structures all we had only GoTo's. As a result it was really hard to follow the flow of the program. We had spaghetti code. I am currently working with a middle age programmer that has only worked with C# and WPF. Very little Windows forms. He has 15 years of WPF and is a better at it than I. But everything is binding. He hardly ever updates a control directly. Everything is binding. Working with his code you never know were things are going. It is like the new spaghetti.
So many years of programming I have forgotten more languages than I know.
You should learn from this guy, binding is not evil and is not spaghetti. Binding is your friend once you get used to how it works
-
Long ago before there were flow control and subroutine structures all we had only GoTo's. As a result it was really hard to follow the flow of the program. We had spaghetti code. I am currently working with a middle age programmer that has only worked with C# and WPF. Very little Windows forms. He has 15 years of WPF and is a better at it than I. But everything is binding. He hardly ever updates a control directly. Everything is binding. Working with his code you never know were things are going. It is like the new spaghetti.
So many years of programming I have forgotten more languages than I know.
-
Long ago before there were flow control and subroutine structures all we had only GoTo's. As a result it was really hard to follow the flow of the program. We had spaghetti code. I am currently working with a middle age programmer that has only worked with C# and WPF. Very little Windows forms. He has 15 years of WPF and is a better at it than I. But everything is binding. He hardly ever updates a control directly. Everything is binding. Working with his code you never know were things are going. It is like the new spaghetti.
So many years of programming I have forgotten more languages than I know.
i don't know what WPF is (never mind) and what binding from that perspective means, but i have a familiar feeling for what you are talking about. does the code for every task jump around a lot from function to function and even worse, from source file to source file?
-
Long ago before there were flow control and subroutine structures all we had only GoTo's. As a result it was really hard to follow the flow of the program. We had spaghetti code. I am currently working with a middle age programmer that has only worked with C# and WPF. Very little Windows forms. He has 15 years of WPF and is a better at it than I. But everything is binding. He hardly ever updates a control directly. Everything is binding. Working with his code you never know were things are going. It is like the new spaghetti.
So many years of programming I have forgotten more languages than I know.
It isn't just binding, it is true with everything. For some reason you're not allowed to just call a function and get a result. The function has to be through an interface which is backed up by a library or three and then there are templates for the view, for the model, for the database - and entity framework because doing a SQL call is evil for some reason and then the validation library, a number formatting widget and a dozen other random files, most of which are in Nuget package that are obsolete or no longer supported.... 7 years to go... my dream job is bagging groceries.
-
I'm a "non-binder". Possibly a control-freak part of my nature but, when it comes down to it, everything thing is in-your-face. The closest I get to obscurity is using SQL Stored Procedures rather than hard-coding the TSQL.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
Me too, I do everything in code so I know exactly what's going on. And what's not. We have a couple apps here done by other (lazy) programmers and everything is done with binding. I have no idea how some of it works or why you'd elect to do that.
-
Long ago before there were flow control and subroutine structures all we had only GoTo's. As a result it was really hard to follow the flow of the program. We had spaghetti code. I am currently working with a middle age programmer that has only worked with C# and WPF. Very little Windows forms. He has 15 years of WPF and is a better at it than I. But everything is binding. He hardly ever updates a control directly. Everything is binding. Working with his code you never know were things are going. It is like the new spaghetti.
So many years of programming I have forgotten more languages than I know.
binding is the worst. all the hoops to jump through to display data. all the data transforms and special cases have to be put into a special view model that can be bound making a lot of glut. I worked with WPF for about 2 years, I wanted to pull my hair out, got a different job and never touched the stuff again.
-
Long ago before there were flow control and subroutine structures all we had only GoTo's. As a result it was really hard to follow the flow of the program. We had spaghetti code. I am currently working with a middle age programmer that has only worked with C# and WPF. Very little Windows forms. He has 15 years of WPF and is a better at it than I. But everything is binding. He hardly ever updates a control directly. Everything is binding. Working with his code you never know were things are going. It is like the new spaghetti.
So many years of programming I have forgotten more languages than I know.
Binding is one of those things whose only purpose is to produce an "ooh" at product roll-out demos. Microsoft demo wonk: I'll show you how easy it is to get data from the database to the form. Click/drag/tap Crowd of mindless drones: Oooohhhh.
-
Binding is one of those things whose only purpose is to produce an "ooh" at product roll-out demos. Microsoft demo wonk: I'll show you how easy it is to get data from the database to the form. Click/drag/tap Crowd of mindless drones: Oooohhhh.
Of course they did a lot of grunt work before hand to get the application ready. The not so Ooooohhhhh part. Now I have this interstate bridge I can sell you for a discount.
So many years of programming I have forgotten more languages than I know.
-
It's pretty powerful once you get used to it. And it's used pretty much everywhere now - Angular, Vue, etc. I prefer to have the code (logic) and view (semi)decoupled by using bindings. It's allowed me to re-use viewmodels with different views, where I would have had to duplicate logic.
Agreed. For any front-end scenario where multiple clients are involved and at least one server that can propagate information to all clients, you either A) pick a binding framework or B) lose time reinventing the wheel in a non-standardized way that will become obsolete before it's ever finished. I just hope WASM/Blazor can speed up the creation of a C#-based binding framework for the web. I tired of debugging JavaScript. :((
