|
Using IWorkspace on a large project. |
Post Reply 
|
| Author |
 Share Topic Printable Version Delicious Digg Facebook Furl Google Boomarks Google Buzz MySpace Newsvine reddit StumbleUpon Translate Twitter Windows Live Yahoo Bookmarks Topic Search  Topic Options
|
JohnBloom 
Groupie 
Joined: 30-Nov-2010 Location: Topeka, KS Posts: 95 |
 Post Options
 Quote Reply
 Topic: Using IWorkspace on a large project.Posted: 16-Mar-2012 at 12:31pm |
|
We are looking through Cocktail and trying to see what it will take to move to it. Here is something we had a question about. Importing all of the IWorkspace viewmodels on a small project and putting them in a menu has low overhead. What do you do when there is a potential for lots of menu items in a large project. We want our startup time to be as quick as possible and it seems like overkill to create the memory for the all the viewmodels just for the metadata like title and sequence. We are looking for maybe a smaller, light way of displaying a menu of items 90% of which will harldy ever be clicked. Do you agree that creating tons of viewmodels might be an issue? What would you recommend we do to avoid creating every IWorkspace viewmodel in our app when our program loads? |
|
|
-John Bloom
|
|
 |
|
|
smi-mark
DevForce MVP 
Joined: 24-Feb-2009 Location: Dallas, Texas Posts: 343 |
Post Options
Quote Reply
Posted: 16-Mar-2012 at 1:18pm |
|
As long as you are using a Start method or some other method of initializing only when clicked, the memory usage should be very minimal. If your constructor is simply setting properties you should be ok.
Otherwise, one option is to use MEF metadata. You can find a good article detailing how to implement metadata here: http://codebetter.com/glennblock/2009/12/05/building-hello-mef-part-ii-metadata-and-why-being-lazy-is-a-good-thing/ |
|
|
|
|
JohnBloom
Groupie
Joined: 30-Nov-2010 Location: Topeka, KS Posts: 95 |
Post Options
Quote Reply
Posted: 16-Mar-2012 at 1:50pm |
|
We are also trying to be very modular. We allow extra xaps to be downloaded based on the contract with the customer or different kinds of custom changes that they request. It seems like we would be setting ourselves up for failure if one of those "extra" modules had a bug in the constructor of the viewmodel so it wouldn't let us run the entire program. It seems like the bug should only be an issue once you click on that item. That way if it was just some little test feature we were sending out to a customer it wouldn't bring down the whole system. With the way the system is now any viewmodel that throws an exception in the constructor will shut down the system. We install our software on a server on our customers site so this is not just SAS with one site to worry about.
|
|
|
-John Bloom
|
|
|
|
|
mgood
IdeaBlade 
Joined: 18-Nov-2010 Location: Emeryville, CA Posts: 583 |
Post Options
Quote Reply
Posted: 16-Mar-2012 at 2:00pm |
|
MEF metadata as suggested is one way. Nothing gets instantiated to read the metadata. Another option is you can have small starter objects that represent each module and lazy instantiate the actual ViewModel behind them. They would get the corrsponding ViewModel injected as a Lazy<T>, which won't instantiate the ViewModel until you access the Value property.
|
|
|
|
|
smi-mark
DevForce MVP
Joined: 24-Feb-2009 Location: Dallas, Texas Posts: 343 |
Post Options
Quote Reply
Posted: 16-Mar-2012 at 3:27pm |
|
I do something similar to what Marcel says. I have a "Workspace Controller" for my applications, the workspace controller controls my icons and is then responsible for initializing the search/edit screens when needed
|
|
|
|
|
Post Reply
|
| Forum Jump | Forum Permissions You cannot post new topics in this forum You cannot reply to topics in this forum You cannot delete your posts in this forum You cannot edit your posts in this forum You cannot create polls in this forum You cannot vote in polls in this forum |