DM-V-VM part 6: Revisiting the data model

re: DM-V-VM part 6: Revisiting the data model

AleXFlint — Wed, 30 Aug 2006 02:35:10 GMT

Hi Dan!

very great series! I'm really impressed, thats really tricky!

I'm going to try implementing this pattren for 3DObjects(MV3D). I know 3DObjects are not FrameWorkElements or UIElements, but I think not all but some of concepts of this pattern could be very usefull to implement binding between a 3DObject and a DataModel (to get the position in 3D space for example could be a possible Data from DataModel). Thanks a lot for great work! Waiting for next/last couples of posts...

PS: your session at deep dive was very cool! Thanks.

re: DM-V-VM part 6: Revisiting the data model

Bryant Likes — Wed, 13 Sep 2006 21:49:33 GMT

How about posting those last couple of posts to wrap this up? :)

re: DM-V-VM part 6: Revisiting the data model

AleXFlint — Thu, 14 Sep 2006 19:31:18 GMT

Oh, Yes, I'm waiting for that too. I hope it comes soon :). Let's wrap it up.....

re: DM-V-VM part 6: Revisiting the data model

dancre — Thu, 14 Sep 2006 19:38:51 GMT

Sorry, I'll get to it this weekend at the latest!

DM-M-VM part 7: Encapsulating commands

Dan Crevier's Blog — Fri, 15 Sep 2006 18:56:32 GMT

In part 5, I talked about commands and how they are used for behavior. Now, I want to talk about a better...

re: DM-V-VM part 6: Revisiting the data model

Paul — Tue, 19 Sep 2006 08:51:18 GMT

Hi Dan,

Thanks a lot! I'm looking forward for other posts.

One question came to my mind while reading DM-M-VM series:
Why don't you use async bindings for fetching data in background?

Thanks,
paul

re: DM-V-VM part 6: Revisiting the data model

dancre — Wed, 20 Sep 2006 02:34:16 GMT

There are a few things that steer me away from asynchronous data binding. The first is that the property getters will now be callable by multiple threads, and that makes the threading model for the object much more complicated. Second, I think it would be surprising that some properties could hang indefinitely, but others wouldn't. As a consumer of the class, how would you know what's safe to call? And, finally, you get more control if you do it yourself. With asynchronous binding, WPF creates the thread for you, but with this mechanism you have more control over scheduling updates and such.

re: DM-V-VM part 6: Revisiting the data model

Scott Bussinger — Wed, 20 Sep 2006 10:00:43 GMT

Great series! Thanks for the efforts!

In reviewing all of the parts of this series tonight, the statement "we ended up adding a reference counting to our models" got me curious. You obviously weren't happy about having to do it, so what exactly motivated you to implement reference counting in Max?

re: DM-V-VM part 6: Revisiting the data model

Paul — Wed, 20 Sep 2006 15:57:22 GMT

Thanks for reply, Dan!

I see your point.
Actually, I guessed a reason behind your solution, just, you know, it seemed curious: you hadn't mentioned async bindings at all in your articles.

Now it's clear,
Thanks

paul

re: DM-V-VM part 6: Revisiting the data model

dancre — Wed, 20 Sep 2006 18:09:36 GMT

The activation model I presented here works fine if there is only one "owner" that ever activates the model. But, as soon as multiple things want to activate the same model, you need the reference counting. As a simple example, what if you wanted to show the same model in two places in the UI?

WPF Patterns

Bryant Likes's Blog — Wed, 27 Sep 2006 23:31:13 GMT

If you're doing WPF development, you really need to check out Dan Crevier 's series on DataModel-View-ViewModel.

DM-V-VM part 7: Encapsulating commands

Dan Crevier's Blog — Thu, 12 Oct 2006 04:59:25 GMT

In part 5 , I talked about commands and how they are used for behavior. Now, I want to talk about a better

DataModel-View-ViewModel pattern series

Dan Crevier's Blog — Thu, 12 Oct 2006 05:00:56 GMT

I thought I should add a post with the full list of posts in the D-V-VM pattern. They are: DataModel-View-ViewModel

re: DM-V-VM part 6: Revisiting the data model

corbin — Thu, 26 Oct 2006 21:56:19 GMT

This is just a little thing but when you call Activate() you immediately call your DataModel's VerifyCalledOnUIThread(); then you set the property using this.IsActive = true which then immediately calls VerifyCalledOnUIThread(); is this an oversight or am I not getting something...seems like these VerifyCalledOnUIThread methods should only ever be called when you are changing properties. Unless you method directly manipulates the member data itself.

re: DM-V-VM part 6: Revisiting the data model

dancre — Thu, 26 Oct 2006 22:55:02 GMT

I agree it's overkill since the IsActive's setter also checks, but I think it's nice to have it explicitly there.