Friday, August 10, 2012 2:47 PM
I have a Silverlight application C# that have too much pages (user controls). So I started to use MEF !! To divide my xap file.
And I have a doubt about reference. In some of my projects I have a static class. Always when I logged in the application I put some information in this class and I need to use these informations in my others solution.
How is the best way to use a reference ?! If I use a simple way (add a reference of my project1 to my project2) my performance will be worst ? Have other way to use ?
I need your opinion !!
Links that I used to pass my Silverlight application to MEF.
If you see the last link the author say:
Now that we’ve created our separate XAP, we can now go start building our new extension. OK, all we do is go and create our widget, but wait, how do we get access to the Widget contract? Currently all the widget definition information resides in the app. We could just go and a reference back to the application right? Technically you could as the app won’t be referencing us directly, but please DON’T do it. Every time you do a puppy dies
What we need to is to split our contracts out into a separate assembly so that those definitions can be shared across XAPs. We don’t have to embed the shared library over and over fortunately.
Saturday, August 11, 2012 9:10 PM
The last advice is good : a contract must be created in a separated project, and this contract will be referenced by both the main app and each widget.
Using MEF, some class in your main app will support the interface and will serve the services to other classes.
Thursday, September 13, 2012 9:13 AM
Do you have a example that explain how can I do this ?! or a simple tip that can help me ?!
Thursday, October 04, 2012 4:37 PM
this project that will have my static class is a C# Class Library or a Silverlight Class Library ?! please :)
Thursday, October 11, 2012 4:08 PM
I do not have a simple sample to show you unfortunately. I searched a bit the Web but I did not find something simple enough to be shown here and explained in a few lines..
But we I can try to answer some precise questions. What is seeming difficult for you at this stage ?
Thursday, October 11, 2012 6:28 PM
In my solution I will normally have a project which initialises the application and loads the shell. This project (generally called MyApp.Shell) is the starting point for the application, it has App.xaml and all the initialisation code. I have a second project (called MyApp.Common, a Silverlight library) which is referenced by the Shell project (and has Copy Local = true). The Common project has all the common stuff(!) - constants, configuration, extension methods. Some of the classes are just instantiated by clients and in other cases I have defined interfaces so that implementations can be swapped (generally depending on design time or runtime).
Other xap files are loaded depending on actions by the user and their authorisation. Each of the dynamically loaded projects (xaps) has a reference to the MyApp.Common project (copy local = false, this is important). The dynamically loaded projects can just use classes/interfaces from MyApp.Common as they require because MyApp.Common is and loaded with MyApp.Shell.
Does that make sense and/or help?
Friday, October 12, 2012 5:24 AM
Your approach sounds correct. I will just add one more step : slice the common project in two different ones.
The "Common.Code" that will contain all classes used by the shell of offering basic services (logs,...), and Common.Interfaces that will just define the Interfaces used to build the "option xap" that are loaded on demand.
Thus, the loaded xap just have to reference the Common.Interfaces project that has no code.
If optional xap must use some Common.Code, then use MEF to glue service providers and consumers.
Doing this things will be clearer and easier to use/reuse/expand.