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.
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. :((
-
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.
Are you reading the code in Notepad? Simply right-click the path of the binding and select "Go To Declaration". Also, the value in the `DataContext` property is a dead giveaway, too.
-
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.
Binding in UWP and WinUI not only gives you binding on functions, but allows you to specify a callback for two-way binding.
-
Are you reading the code in Notepad? Simply right-click the path of the binding and select "Go To Declaration". Also, the value in the `DataContext` property is a dead giveaway, too.
I am reading code in VS but my mouse's right click does not always work. Or maybe it is me that the right click interrupts my thoughts.
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.
This is the case in general with event code -- spooky action at a distance. Easy to write, easy to understand if you don't think too hard, but a PITA if it breaks and you have to debug it. That's the very definition of spaghetti code that I've come to over the years, so yeah, binding code is spaghetti.
5G -- more lies faster.
-
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.
In a sense, the "middle age programmer" is practicing MVVM / MVP, but doesn't get credit for that. He understands what a "data context" is and codes to that (using x:Bind for type checking where available).
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
-
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.
How old are you? 100??