I need to write a composite WPF application with parts being potentially developed by other teams. These parts are actually indepndent applications now, and we want to put them under common "roof".
Two main options I consider for composition is Prism modules vs. MEF parts, and I am not 100% sure which to choose, since both have pros and cons. Note, that this is NOT about the IoC container choice, this is about discovering pluggable components. I am pretty much settled on the opinion that MEF is not to be used as an IoC container.
If I go with MEF for pluggability, the biggest plus is that it is baked in into the .NET framework, so there are no versioning issues. From the other hand, I will have to (partialy) reinvent mechanisms such as Prism region managers and other UI composition features.
If I go with Prism modules, I get much richer integration functionality (regions, event aggregator, etc.), but for that to work everyone must be on the same version of Prism, and preferrably the same version of Unity, to avoid unpleasant surprises. Upgrading to a next version of Prism/Unity will thus become a challenge.
I would like to hear your opinion about the choice.
I had a similar choice several years ago and choose Prism. I'm glad that I did. Unless I was building a trivial app, I wouldn't consider doing it without Prism. You can have different dev groups work in near isolation on their modules and integrate them when complete. The same goes for bugs and requirement changes: much easier to handle.
Yes, you'll want everyone working on the same version, but that's a small price to pay and very common. If you have specific questions, let me know.
Related
I have been migrating from Windows Forms to WPF and am trying to utilize Prism to meet the requirement that the application be plug-in oriented.
My problem is that there is seemingly no support for it. I have also heard that it is extremely leaky in some cases. Being I am developing an enterprise application, this is unacceptable.
If this is the case, and it is a bad idea to start using Prism, is there any alternatives to make a composite application? Solely using MEF is all I can think of.
With Prism you have the option to use Unity and/or MEF as the IoC/DI framework....it's also quite extensible...so you can plugin different IoC containers if you wish.
Some of the problems with leaks can usually come down to not using WPF in a certain way e.g. need to use Weak delegates / Weak event patterns, etc.
You could roll your own plug-in framework using MEF, but you'll probably need to re-invent some of the things Prism already does for you e.g. an EventAggregator, etc.
You could pick an alternative framework, they all have their strengths and weaknesses.
Alternatives to Prism + MEF for modular MVVM apps
There's another Microsoft technology that is geared to supporting plug-ins namely, System.AddIn/Managed Add-in Framework (MAF)....but you have to put in a bit more scaffolding.
http://www.matthidinger.com/archive/2008/10/12/managed-addin-framework-system.addin-with-wpf.aspx
Someone has come up with a framework that uses MEF here:
http://www.codeproject.com/Articles/43625/Building-an-Extensible-Application-with-MEF-WPF-an
If you want to look at an Enterprise size project with their own very plugable/modular architecture then look at SharpDevelop for inspiration.
http://www.icsharpcode.net/OpenSource/SD/
....and it's not beyond the bounds of possibility, if you really want, to combine the best bits from several frameworks.
Seeing as how MVVM is being highly regarded as a good system design pattern, I thought I might just jump aboard and give MVVM a shot.
Just a little background about myself before I begin with questions:
I have done a few years of development with ASP.NET Webforms. I have also done a fair bit of development in ASP.NET MVC, which I am quite comfortable with.
Currently, we have a number of "backbone" applications written using ASP.NET MVC 3 which we customize and sell to our clients whenever we're approached. These applications are all meant for internal use, hence plug-ins wouldn't be much of a problem.
The real problem with development is that for large scale business applications with complex business rules, ASP.NET MVC tends to slow us down (writing jQuery / javascript > server side processing > return result, use jQuery to notify > alter view, something along this line).
Then I began looking for answers that will help us improve our time to delivery and also responsiveness (well, we all know how JavaScript is capable of killing us) and my search brought me to Silverlight (we have the time to change, no worries there).
So here comes the questions:
I have come across many Silverlight MVVM samples online, but all of them show applications as simple as interacting with only one Database table. Is MVVM pattern well suited for large applications?
In MVC, I'm used to Dependency Injection from Ninject to pass an implementation of UnitOfWork to my Controller. In all samples I found online, none of them use any form of DI. Is it really unnecessary? Since the idea of MVVM is to decouple, so why not also decouple ViewModel from Model?
I've gone through a book published by Jeremy Likness called Designing Silverlight Business Applications. He used MEF to do the decoupling, which I think doesn't really fit into our application. We do not really need to do "hot-plugging". What's your take on this?
MVVM is all about Commands, Databindings and No Code-behinds. What if I want to interact with UIs that do not expose to commands? (I'm not too sure about this, I'm guessing ListView OnSelectionChange?)
To add to the previous answer:
We are developing a large corporate-wide Silverlight platform and a set of applications using MVVM. Seems to be working pretty well.
We are using DI extensively. Our system is built on top of Prism. Prism contains a large amount of sample applications of various complexity illustrating the use of DI in MVVM.
We use Unity as our IoC container. Prism contains guidance for both MEF and Unity. Unity seems to be a more traditional IoC approach.
In the vast majority of cases using Bindings and Commands covered our needs. For the others we use Expression Triggers and Actions. You can also create custom Triggers/Actions if necessary.
I have no answers for all your answers (never used MEF) but I can tell you my experience:
1- I've been in the development of a quite-large silverlight application and MVVM fits perfect to have a maintainable application. The bigger problems we had because of application size were because of Silverlight, not MVVM 8-)
2- I haven't used it too much but it's useful in many cases. There are several toolkits to use DI with Silverlight like MVVM Light Toolkit:
http://compiledexperience.com/blog/posts/blendable-mvvm-dependency-injection-and-unit-testing
4- For interaction between UIs you can use the Mediator pattern. The same MVVM Light Toolkit has a Messenger to subscribe, send and receive messages and maitain every layer decoupled.
Hope this helps you ;-)
I am attempting to document a WPF Prism application made up of multiple modules. This scenario begs for module documentation, but I'm not sure if there is a formalized way of doing this in UML, either as separate packages or something more generalized.
Usually, your documentation / design modeling methodology are determined by your company's Software Development Plan or Process. If your company doesn't have one, you may be well served to first define your design documentation process, independent of what fits best for Prism - particularly if you have applications that have been developed that are not reliant on Prism. In my experience, Prism, in and of itself, doesn't lend itself necessarily better or worse to any design modeling approach.
That aside, and with respect to UML specifically, Prism modules can usually be logically divided into packages or use cases quite easily. You've actually already done that when you divided your application into modules in the first place: each module is a loosely coupled, reasonably independent portion of your application.
For example, UI concern modules can often be grouped both according to use case and as separate packages. Take the StockTraderRI for example: the News, Position, and Watch modules lend themselves quite easily to separate use cases (View News, View Position, Add Stock to Watch, etc.) Obviously, these can also be represented easily as separate packages, complete with static class diagrams.
With business or data layer modules, such as Infrastructure or service oriented modules, the representation may be almost exclusively as package / class diagrams, with some use case realization diagrams (sequence, etc.) being used to illustrate communication coming from the UI to the services. Again, with the StockTraderRI application, the Market module and Infrastructure DLL seem to lend themselves to a more static approach.
Again, your approach to documentation and modeling of your application shouldn't be dictated by Prism, as any good modeling language will be able to accommodate Prism.
I am developing a silverlight application for the past 6 months using prism framework. When I look at the code base now it has grown huge with lots of modules, event aggregators, inter module communication code etc. On hindsight I am contemplating whether I made the right choice. Is there any other simpler framework I should have gone for ?
Prism is at its best when targeting a large application. Why? Because the core concepts Prism provides, such as Modularity, UI Composition, support for MVVM, etc. are used the most in this kind of applications.
The idea, as you said, is that you are likely to end up with a bunch of modules. The benefit of that is that your application is decoupled, and modules can be tested in absolute isolation so they are easy to maintain.
By using Prism, or any other library/framework that modularizes your application, (correctly) in large applications, you don't need to go through your entire application looking for bugs when you make a change to one of the parts. This is not true in monolithic applications, where making a minor change might bring down the entire app.
Another plus for Prism in this scenarios is that it allows multiple teams to work on different modules simultaneously, without affecting each other's work. This is specially useful when working with distributed teams.
The thing that would convince you of making the right choice, would be comparing the application you created with the same one but with high coupling of its components.
I hope this helps
I'm trying to build a line of business application using Silverlight. I felt like I was doing good then someone asked some questions. Immediately, I became really confused. I see discussions around Prism, Unity, and the Managed Extensibility Framework. However, they all look like they are trying to solve the same problem. Am I nuts? How do these three items compare / contrast with one another?
Thank you!
I recommend listening to the Herding Code podcasts with Glenn Block. (Part 1 and Part 2). He goes into this exactly subject, in much more detail than we can answer here.
That being said -
MEF and Unity are the two things that have quite a bit of overlap. Prism, in its default form, uses Unity for its dependency injection. You can use Prism with MEF, if you like, instead.
Prism is designed more for building composite applications. MEF, on the other hand, is about extensibility. There is definitely some overlap in goals here, but the basic driving factor is different.
In Prism's case, it's all about organizing known code.
MEF, on the other hand, is about discovering new code, and injecting it appropriately.
The newest guidance I've seen, which I fully agree with, was just posted on Glenn Block's blog: "If you are starting fresh you can use MEF for modularity, and general aspects of your composite app. Where appropriate you can pull in Prism bits."
http://blogs.msdn.com/gblock/archive/2009/12/02/mef-and-prism-to-be-or-not-to-be.aspx
There was this post today that discusses two scenarios where MEF and Prism work together to provide solutions. Each scenario leverages features that are not found in each, with 80/20 rules for those features that they do share.
Although there is overlap, the essential differences from a 30,000 view are
Unity is a IOC container. Use it to make your app more loosely coupled
Prism is gear toward making your UI more loosely coupled. As Reed mentioned, it uses Unity to help do this.
MEF is meant to make your code extensible. This helpful when having to interoperate with code that will be written by someone else. An example is if your application will support plugins.