I have two silverlight assemblies.
In assembly 1 I have implemented an interface ISnProvider.
In assembly 2 I have a concrete class which implements the ISnProvider.
I plan on having more assemblies which will contain different implementations of ISnProvider.
Assembly 1 has no reference to assembly 2.
When my silverlight app starts up, I want to resolve the ISnProvider interface using an IOC container. Ideally I won't have to recompile my app to use different providers. I don't want to hardcode 'assembly2.dll' in my assembly 1.
Which IOC container will allow me to dynamically load these assemblies using silverlight?
Thank you!
santiago
You might want to take a look at the Managed Extensibility Framework (MEF) from Microsoft. That will certainly support your scenario (example here) although it does unfortunately mean you need to use attributes (e.g. [Import] / [Export]) at various places in your code.
Autofac is available in a Silverlight version and I would certainly recommend it for general IOC usage with Silverlight but I've never tried to get it to dynamically load an assembly without a direct reference and I'm not sure if it will support that in Silverlight (I'd love to hear if anyone has accomplished this with Autofac)
You could also use a semi-manual approach - here's an example of loading an assembly dynamically in Silverlight without an IOC container, which may or may not be useful for you.
Related
I know this sounds lame, but MSDN seems to have a bunch of empty information on it. Like this link ServiceLocator. I just rolled onto a project with Unity and Prism. I have found it in some code where a WPF UserControl is passed in like this
var alert = ServiceLocator.Current.GetInstance<AlertControl>();
Is this like Unity's resolve?
http://commonservicelocator.codeplex.com/
From the project description:
The Common Service Locator library contains a shared interface for service location which application and framework developers can reference. The library provides an abstraction over IoC containers and service locators. Using the library allows an application to indirectly access the capabilities without relying on hard references. The hope is that using this library, third-party applications and frameworks can begin to leverage IoC/Service Location without tying themselves down to a specific implementation.
This abstraction is implemented by several IoC frameworks out there, and Unity is one of them. nevertheless, Unity is not the owner of that project.
This way StructureMap, for example, provides implementation of those clases, so other frameworks (such as Prism from patterns & practices) can easily work with other IoC frameworks and not be bound to Unity itself.
My Application has the following structure:
myproject (primary Silverlight project)
myproject.Web (website for the app)
myproject.Controls (Class library so I could do some inheritance with controls)
myproject.Classes (Classes representing the data the controls bind to)
It seemed like a good idea having these split into projects with their own sub-namespaces, but I'm running into a lot of coupling issues and that is leading to circular dependency namespace problems.
From what little iOS development I have done, it feels kind of like I am trying to roll my own MVC solution here. What is the recommended way of going about having controls (essentially forms) backed by data in a Silverlight app?
The projects look fine provided the namespaces and assembly names match. You can do the following:
myproject.Classes Can reference none
myproject.Controls Can reference myproject.Classes
myproject Can reference myproject.Controls AND myproject.Classes
myproject.Web Can reference myproject.Classes, but shouldn't need to
I suggest doing that split within the primary Silverlight application itself (a single project with multiple folders). Unless you know right now that you will have to reuse the code within the classes and controls namespaces within different Silverlight applications, I would avoid it. Silverlight is UI, anything you will want to reuse should be in the ASP.NET part of the project (logic, db access, business rules, etc).
If you take this approach, your UI won't become an albatross around your neck.
Keep your Silverlight applications thin, fast and pretty - I promise you won't regret it.
EDIT: The downvote made me realize I was unclear (clearer, more concise version below):
Don't split your solutions into projects based on namespaces - it leads to needless complication. Use namespaces within projects to organize code. Keep project counts to a minimum, and only split when there is a compelling need.
Good Luck!
Is it possible to share viewmodels across platforms - WPF/Silverlight? I started down the path of putting my VMs in a separate assembly and soon came to ICommand - which then led me to ask this question? Is this possible, and if so is it good to do so? We have a possibility in the future of having a client application for WPF and Silverlight, so I would like to not have to duplicate VMs for both.
You can potentially do this using the Portable Library Tools CTP. This allows you to target the full framework as well as Silverlight in a single library project.
Otherwise, it is possible, sort of. You still need two separate projects (for practical purposes), but can typically use a single source file. Have each project using the same source files keeps the reuse in place - but does require manual synchronization of the files. You can also add platform-specific functionality easily in this case via partial classes or defines, which does help to keep some of the workarounds for missing Silverlight functionality easy to maintain.
[Almost] whatever is possible in Silverlight, is possible in WPF, too. So if you have a VM working in Silverlight, it will [mostly] work with WPF.
From the other point of view, WPF offers richer possibilities, so you might want to use them in your WPF part of code. You can use the usual #ifdef Silverlight-like tricks.
Also, this question might be useful.
I downloaded Prism v4 and ran the installer. I went into the directory and ran the two following batch files:
Desktop only - Open Modularity With Mef QuickStart.bat
Desktop only - Open Modularity With Unity QuickStart.bat
When I compile these applications, I don't see any real difference. I've searched for MEF vs Unity and I've found some pros/cons, but nothing that specifically states whether one is "better" (and I know that is subjective) with use in Prism. I guess perhaps if I list my requirements someone can point me to the correct technologies to use (even if it's not Prism 4).
The application is to be written in WPF (NOT Silverlight).
The main application will be extremely thin.
The main application will use a Web Service to build the menu of the "apps/modules" a person has access to.
The "apps/modules" will be completely contained in other managed libraries.
The main application gets views and viewmodels by reflecting into these DLLs.
The main application should feed in services for logging, etc. into these "apps/modules".
For example:
A basic user might have the options of:
ViewOnly Address record
All items Address related are within Address.dll.
An advanced user might have the options of:
New Address record
Open Address record (update/delete)
Manage users
All items Address related are within Address.dll.
All items Manage related are within Admin.dll.
The app should not actually reference either of these DLLs, I plan to reflect into them so that if there are 100 different modules and a user only has access to 2 of them, only 2 of them are downloaded and used. Whereas a user that has access to 10 of them gets those 10.
I've already solved the downloading DLL via WebService. :)
None is "better": they are different things.
IMO your choice should be driven only by your requirements. Based on the requirements you posted here I would suggest you to use MEF, because you have modules contained in DLLs and the main app is unaware of modules to load. Those tasks are the reason that why MEF exists.
Anyway you could use them both: MEF for modularity and Unity to take advantages of dependency injection (testability, reusability, ...)
If all the modules are not recompiled at the same time as the app, then MEF gives you lots of ways to cope with changing interfaces in the main app. Otherwise MEF may be more complex then you need.
I've been using Unity over a year with PRISM but I've noticed some serious memory leaking issues. Hence I decided to give PRISM 4 and MEF a go. What I've done is firstly converting my app to use PRISM 4 with Unity. Then I converted a branch to use MEF.
It may sound funny but MEF seems to handle memory consumption and release somehow better than Unity.
Would be nice to hear whether others have made the same experience?
Regard to your question whether MEF and UNITY can work nicely with each other, i can tell you that they are working really well with each other. I have developed a proof of concept application which used PRISM, Unity and MEF.
I have a a WPF prism desktop app with a few modules. In the past I've put all my localized resources in common resource files in the infrastructure assembly and referenced it in all modules.
But lately I have been wondering if that is indeed the right approach from a maintainence perspective. In essence it also sort of breaks modularity. Would having module specific resource files in the the modules themselves be a better approach in the long run?
All thoughts appreciated.
As far as one of Prism's main targets is modularity it just seems obvious to put your resources only in the appropriate assembly. Sharing resources via one centralized assembly is the opposite of modularity.
Doing it the centralized way will get you another type of DLL hell at the time you want to add more (optional) modules. You will have to update the common assembly without the knowledge of the modules that use the assembly. And determining which module is present just again violates the modularity itself. The other way is to always update the common assembly to the latest version.
Whatever you do, following the centralized approach forces you to build all your modules backward-compatible.
This is my point of view at the moment. But as far as I'm working with Prism for only a few weeks now I'm not quite sure if my statement is the way how it should be done.
I never have references between the individual modules when using Prism (unless one module is indeed an enhancement of another). I tend to put shared resources, interfaces etc. in a 'common'-assembly that is referenced by all modules and the assembly containing the shell. Things that implement an interface is then retrieved via the IoC-container and the implementation is placed in the module where it 'belongs'.
As you write - having them in the infrastructure module breaks one of the ideas behind Prism.