I need to write an application which can load plugins. I read the PRISM 4 documentation and i like the "Region" concept of the framework. But all modules are loaded in the first AppDomain - but i need to build an application where 3rd party plugins can crash without crashing the whole app (so i think multiple app domains are the best solution?)
Has anybody some experience with that topic? Should i build it on top of MVVM light myself? Is PRISM 4 the tool I'm looking for?
Thanks and best regards
To the best of my knowledge, none of the popular MVVM frameworks (Prism, Caliburn, Calcium etc.) support cross-appdomain module lifecycle and, just as importantly, cross-appdomain messaging out of the box. This said, it's not impossible to customise any of them to:
allow for modules to be loaded in different appdomains, perhaps based
on some configuration option;
create a remoting proxy for their messaging components (eg. event aggregator in Prism) so that a message is serialised into a different appdomain.
For one, Prism4 allows for multiple extensibility points on its bootstrapper, module catalog and service locator components, so loading DLLs and initalising their entry points on different appdomain is not too hard. Creating a remoting proxy of the event aggregator is a bit more complex.
I have personally resorted to creating a different message broker that works cross-process as well as within the same appdomain, however I had to write it from scratch.
Related
I am building an application using WPF, MVVM, and PRISM. the application is an intensive CRUD app, and the db is accessed using entity framework. i want to build the application using modules but i can't figure out where to put the data access code (more accurately i can't figure out where to put the repository interface) . if they go into an infrastructure project. then all modules will depend on that and it doesn't seem like the right place. on the other hand if the interfaces go into their respective modules then there will be lots of inter-dependencies between the modules which is bad.
Question: best way of designing a database-aware modular PRISM MVVM application and perhaps the best solution to my case ?
I think you may take a look at MEF. It allows you to have the level of abstraction and modularity you will need for this while everything working together in a seamless way.
I would recommend you to read official Prism guide.
I use this separation:
MyApp - shell project
MyApp.Infrastructure - all shared interfaces - including your IRepository
MyApp.DAL - contains all DAL classes, and also Repository implementation
MyApp.Modules.SimpleModule
MyApp.Modules.AnotherModel
etc.
Main thing about modules - they should not depend on each other, but they could depend on shared modules (e.g. MyApp.Infrastructure).
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.
There seems to have a buzz around the Lightswitch application framework.
Reading some posts/forums/articles and listening to a video provdided some answers, but raised some others.
Extensibility?
Is there several hooks to override or extend features?
Modularity? Can MEF/Prism be integrated? Is there a concept of dynamic modules that can be loaded at runtime?
Localizable? Any special features about localization in different languages?
Versionnable? Any concept of version so simultaneous version can co-exist?
Abstraction? The connection to data source can be abstracted and replaced?
Testability? Are the different components unit testable in an automated way? Easy or difficult to achieve?
Cross-cutting / NFR ? Any hooks so we can plug NFR code? (logging, caching, audit, secuity )
Is this a solid framework to build some PAAS application over?
Let me give you my 2 cents based on an eval I just did:
Extensibility
You can of course add custom controls and apparently there will be a published extensability API.
Modularity
No. Lightswitch is not a code generator, it abstracts out implementation of the UI.
Localizable
Did not see anything, but I imagine this will occur in stages.
Versionnable?
You could TFS the Lightswitch project, but if you mean versioning from an execution standpoint ... it's as simple as deploying a new version of the app to the server. The client will check for updates on run and install as necessary from what I understand.
Abstraction
Yes, if you abstract it at the WCF RIA Services layer which is very easy to do.
Testability
Business rules can be implemented at the RIA Services layer so testing there should be a snap, but if you rely heavily on rules driven through the UI you will have to use another UI-based testing tool.
Cross-cutting / NFR
If you focus on getting the RIA Services tier of the app to be the central location for business rules and let the UI just focus on user experience you won't run into much overlap. I think Lightswitch is a good client for many solutions, but the core power of it is using it as a client for RIA Services which itself is not dependent on Lightswitch by any stretch.
I hope I at least provided some useful insight.
Extensibility? When the built-in LS controls don't allow you to do what you need, you can use just about any Silverlight control (including 3rd party controls), or create your own custom Silverlight controls. There is a little more work to do than using LS controls, because the LS controls have some extra "smarts" built into them, so you can just drop them on a screen, bind, & use them. There are also extensibility points built into the framework that allows you to create your own "extensions" (shells, controls, themes etc).
Modularity? LS already uses MEF under the covers, so it's quite possible that it may be able to be leveraged further in the future. LS does generate code, but for itself, not for external consumption. There is an excellent article, however, by Microsoft's Eric Erhardt
http://blogs.msdn.com/b/lightswitch/archive/2011/04/08/how-do-i-display-a-chart-built-on-aggregated-data-eric-erhardt.aspx
that shows how to reuse the data model that LS constructs (in Eric's case, he uses it to create a RIA service that aggregates data for presentation in a chart control).
Localizable? I don't believe there are currently any built-in localisation features.
Versionable? For a web-based app, if the data schema didn't change, I don't see why you couldn't publish separate versions, but desktop (OOB) apps are click-once apps & are therefore governed by that technology.
Abstraction? If you were to create a RIA service for your data source, you could abstract away the implementation details.
Testability? Unfortunately, V1 was not written with "testability" in mind. If you extract out your business logic into Silverlight class libraries (for use on the client, or full .NET class libraries for use on the server), you can unit test that logic, but the code that you write in an LS application itself is not really unit-testable at this point in time.
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.
What's the fastest communication model for a Silverlight component communicating with a WPF component? That is, at the very least I'd like to consume an event from a Silverlight component in a WPF component.
I understand you can use WCF to build a bridge
I understand you can use Javascript to bridge from WPF -> Silverlight (and I have that working)
I understand you can use COM to go the other way (Silveright -> WPF)
However I'm looking for a tighter communication model (not using COM) - perhaps like EventAggregator (Silverlight component pubs, WPF component subs)...but I've only seen eventAggregation in WPF or Silverlight but not both at the same time.
Any ideas for creating such an eventAgg / eventBus, without using WCF, without using COM?
Open to any approaches / ideas; might be something I haven't considered.
Thanks.
Interesting challenge - could you provide a little more detail on why you need to do this?
My first question is: Are you envisioning these two apps running on the same machine, at the same time? Both are important.
If the answer is yes (same machine, both running) then you should be able to implement a solution using WCF, with the service self-hosted in the WPF app, the Silverlight client referencing it, and a cross-domain policy setup appropriately.
If the answer is yes, but not at the same time, then you'll need a third party, like a Message Bus, perhaps implemented as a Windows Service. NServiceBus comes to mind.
In any case, WCF really is the best solution for messaging in Silverlight. If you were going Silverlight app-to Silverlight app there is a mechanism for that that doesn't require WCF.
A message bus would give you the Event Aggregator functionality you're thinking of - a player who is always there to accept subscriptions and publications.
Another option (if running at the same time) is to elevate your Silverlight app to full-trust and use Sockets. See this link for more info (he provides an example that may be helpful).