How to databind to references instead of actual objects?

Question

0.00/5 (No votes)

See more:

So I'm returning to desktop apps after a decade away in non-programming IT roles, and teaching myself C# and WPF. (Don't judge! I see the _reported_ downward trend :-)

So here's my problem: I have a hierarchical parent C# object that I'd like to use as my over-arching data source. Let's say it has an ObservableCollection of Person objects. And each Person object in the collection has an ObservableCollection of Tags (simple objects that have a name, description, color). This is so that an application user can "tag" a person with such things as "Manager" or "Employee" tags (and other custom tags they create).

When an individual Tag object is created, I assign a new Guid (converted to string) to an ID property on the Tag. Instead of storing an actual Tag object in the Tags collection of each Person (to avoid unnecessary data bloat), I was going to store the ID property value (guid string) in the Person.Tags collection.

Problem is, now when it comes to data binding, is there an easy path to display a Person and their tags (and allow editing of tags)?

One possible solution that I've thought of is once the parent object is recreated from disk (deserialized), create a temporary ObservableCollection of Tags (actual Tag objects instead of guid strings) for each Person and bind to that. Other thoughts appreciated.

BTW, I'm really surprised that WPF has made it this far. When you take the intersection of out-of-the-can objects that are actually compatible with real-world use, it's a tiny, tiny set. For example, objects that can be used for databinding and serialized without heavy code writing and workarounds.

What I have tried:

Not worrying about data bloat and just go for it.

Posted 24-Apr-20 14:15pm

greatoceansoftware

Updated 4-Jun-20 9:36am

Add a Solution

2 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Gerry Schmitz · Answer 1 · 2020-04-25T11:21:00

Solution 1

WPF and UWP (not dead) are almost equivalent. If you're talking "objects", WPF and UWP use .NET framework "classes" to instantiate objects; these classes numbering in the thousands. Maybe you're thinking "controls" of which there are enough "primitives" and tool kits to build anything you can imagine.

In your case, you should be looking at lists of "user controls", which can resemble "list of forms with lists" and so on. You're only limited by your imagination when it comes to implementing UI's. If you're an MVVM fan when it comes to implementing responsive UI's, then you have my sympathy.

Posted 25-Apr-20 11:21am

Gerry Schmitz

Comments

greatoceansoftware 25-Apr-20 18:11pm

Thanks, Gerry. I thought about user controls, and that may be where I wind up. I built many of them in my VB/.NET/WinForms days. But the appeal of accomplishing the same UI effect with a well-placed DataContext and some Styles with DataTemplates seems worth a try.

What I think I have discovered, is that databinding really depends on a truly hierarchical data tree. That is, databinding can't effectively "join" two canonical data sources (independent collections of C# objects, i.e. "tables") on a "foreign key" (i.e. the ID <guid> in the problem statement above).

If that's the case for this particular application, then it really circles back to the user control and manual update coding that I've done in the past. Shame.

greatoceansoftware · Answer 2 · 2020-06-04T09:37:00

The final solution was to just use ValueConverters to translate the ID into the other Tag properties values and use/display them. A pain, as each property required its own value converter. But since there are only a handful of properties, and their universally applicable throughout the application, a worthwhile effort.