Comments on: Improving Cairngorm’s ModelLocator Part 2 - Hiding the singleton

by: richard

Thu, 17 Apr 2008 14:23:32 +0000

There was line in the Model code above that said

return _data[name] || name;

This should say

return _data[name] || null;

I’ve changed it above but if you grabbed the code before now, you need to make this change or it won’t work with non-string data types.

by: richard

Tue, 15 Apr 2008 16:50:26 +0000

Hi Jason

Memory may be a problem. This technique is something I only thought of yesterday, so it’s very possible that under testing it will have issues.

I’d really prefer to get the monostate working from yesterday’s post, but can’t find the right solution. It probably requires delving deeper into the binding code and creating the bindings by hand.

by: Jason

Tue, 15 Apr 2008 16:15:42 +0000

Do you worry about memory consumption much with this method? If you have a very large model locater (say 2000 properties), and every class that wants to access the model locater needs to make a new instance I can see memory consumption rising. I see that you are just pointing to the same instance of the model for each new instance of ModelLocator, but there is still a memory cost in creating all of the bindings for each new instance of ModelLocator.

If I have a standard medium-sized Cairngorm app that has 50 views, and 100 events, commands, and delegates and every command needs to set a flag in the model and every delegate needs to set response data in the model, and every view needs a reference to the model obviously — that is 250 instances of ModelLocator - now you could clean up those instances and do due diligence with your memory management, but it seems like a candidate for a memory leak, or at least barrier to scaling.