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.
Related
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.
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 going to develop a winform project of considerable size. I am planning to use Entity Framework as ORM tool. Now I am searching for an architecture(MVC/MVP/MVVM etc..) to implement all these. Firstly there are few choices for n-layered architecture for windows forms and most those I get are written prior to EF came into market. I got a framework called Rocket Framework from codeplex(http://rocketframework.codeplex.com)
I have looked around it but am skeptical that it will accommodate a wide range of requirements. If anyone has already discovered the wheel already, please guide me through.
Also if the existing architectures prior EF4 can accommodate it than also I can give it a try.
Ideas please!
Well your choices is influenced by the technology you're using. Some technologies make a certain pattern natural to do and thus if you (and every developer) don't explicitely design and care about this you'll end up with what feels most natural. On WinForms the most natural pattern is MVP. You have your view that you can layout in the designer and your code-behind file becomes the presenter, essentially combining view and presenter in one class (it's a 1:1 relationship anyway). For web applications on the other hand MVC is a natural pattern since your web server already acts as a controller. Finally MVVM is supported very well in WPF, although you could fall towards MVP there as well if you start using the code behind file a lot. But relying on DataBinding instead can make you forget to use the code behind file. A good article I read about this is here. Of course you can realize MVVM with WinForms, read this link for a good example.
From the point of testability MVVM is perceived as the best pattern since your view model (and therefor the behavior of your view) can be tested without an actual GUI. MVP however is easy to understand and realize, doesn't require complex bindings and gives you most control over what is happening (e.g. event suppression).
WinForms applications are mostly developed with MVP pattern. The original MVC is not used very much - only its Model-2 variant (for example ASP.NET MVC) for web applications. MVVM is used primarily with WPF and Silverlight.
Neither of these patterns affects how you use Entity framework - they are not data access related patterns.
After a lot of R&D and extensive study I finally settled here:
https://github.com/geersch/ModelViewPresenter
It is an MVP architecture written by Christophe Geers. It supports all I needed- Architecture for winform, web portability support, Entity Framework. Really nice and easy to use.
Additional reading:
http://www.cerquit.com/blogs/post/MVP-Part-I-e28093-Building-it-from-Scratch.aspx
I've come across something called Prism a lot recently. Microsoft, who run the project, describe it as
Guidelines for composite applications in WPF and Silverlight.
Even after reading the more detailed descriptions out there, I have next to no clue what it's actually about, I'm afraid.
I'm hoping here that someone could give me a clear succinct explanation of what Prism actually is and why I should learn it. I have been a WPF developer for a couple of years now, used MVVM my fair share, and have lately encountered people using Prism, but personally feel a bit out of the loop here.
In particular, I'm wondering about the following points:
Is Prism literally just (or mainly) a booklet, as given on the MSDN site? Does it include any libraries, if so for what exactly?
Is Prism an MVVM framework? Should I be using it as the "official Microsoft MVVM framework" over others out there or my own?
Does it provide dependency injection? Does it relate to MEF at all in this way?
Anything else I should know about what Prism does, as a WPF/Silverlight developer.
Prism is the Microsoft Patterns and Practices Team official guidance for building "composite applications" in WPF and Silverlight.
It's intended to provide guidance on the best practices for building large scale applications which are flexible in terms of development and maintainability.
This includes guidance on dependency injection (via Unity or MEF), layout (including using MVVM), composite event handling, etc.
Is Prism literally just (or mainly) a booklet, as given on the MSDN site? Does it include any libraries, if so for what exactly?
It is a book, but also includes the libraries for support (on the GitHub site).
Is Prism an MVVM framework? Should I be using it as the "official Microsoft MVVM framework" over others out there or my own?
Yes and no. It includes guidance for using MVVM, but is far more than an MVVM framework. It's really not, in and of itself, an "MVVM framework" - though it does include MVVM guidance.
Does it provide dependency injection? Does it relate to MEF at all in this way?
Yes. It originally included Unity, but the latest release includes using MEF for DI.
Anything else I should know about what Prism does, as a WPF/Silverlight developer.
It's worth taking a look at how they do things. They have a very elaborate "region" concept, as well as good event aggregation support. It also includes good practices for developing against WPF, Silverlight, and Windows Phone simulataneously.
It's a framework for building WPF and Silverlight apps.
http://compositewpf.codeplex.com/
It used to be called "Prism" before Microsoft renamed it to "CompositeWPF."
Answers:
1) Prism is an MVVM framework to use as a foundation for your applications
2) I suggest so depending on your specific requirements. You should post another question with specific details so you can get some specific answers.
3) Prism uses dependency injection (Unity) but does not "provide" it
4) Imo, Prism provides a lot of functionality but is heavy on the learning curve. For small projects with you as the sole developer, you may not need the abstraction and tools that it provides.
A more contemporary answer of what Prism is, is answered on the Github home page.
Prism is a framework for building loosely coupled, maintainable, and
testable XAML applications in WPF, Xamarin Forms, Uno Platform and
WinUI.
To elaborate, Prism is a collection of libraries to aid in implementing enterprise applications following Microsoft recommended best practice design and architectural patterns.
Prism consists of the following Nuget packages:
Prism.Core
Prism.Wpf
Prism.Forms
Prism.Uno
Prism supports different DI (Dependency Inversion) / IoC (Inversion of Control) techniques and libraries. It ships with the Unity library for dependency injection, with additional IoC helper functions and classes.
Some of the areas the libraries address:
Decoupled Event messaging and handling
Command
View Model Navigation
INotifyPropertyChanged implementation
Dependency Injection
Prism is part of the .NET Foundation.
You may be interested in looking at the Windows Community Toolkit, which follows many of the same principles and patterns adopted by Prism.
I am new for both concepts.
1) I want to know that MVC and WPF is same concepts but WPF for desktop while other is for WEB ?
2) Will be easy to learn other one If i learn one of them ?
I think you probably meant "ASP.NET MVC" technology when you were talking about "MVC" (based on the tags of your question). Anyway, here are a few points that may clarify what is going on:
ASP.NET MVC is a technology for developing web applications based on the model-view-controller (MVC) pattern. You can twist it a little bit, but the framework is specifically desgined to work with this pattern.
WPF is a technology for developing windows applications. You can use various different design patterns when writing WPF applications, but the most popular one these days is called model-view-viewmodel (MVVM). You could also use the MVC pattern (organization of components) when writing WPF applications, but that wouldn't work as nicely as more native approaches.
So, regarding your questions:
They are not the same concepts - the technologies are different and the usual patterns (ways of organizing code) used with the two technologies also differ.
Learning one technology may make it easier to understand the other one slightly, because they are both .NET GUI frameworks and share some concepts. However, I don't think this will help a lot.
MVC (model-view-controller) is a design pattern, and is not specific to a particular technology set.
WPF (Windows Presentation Framework) is Microsoft's windowing library, and can be used in an MVC-designed system. However there's nothing to enforce this and MVC pattern usage can certainly be abused with WPF.
MVC is a widely used pattern and familiarity with it is going to be useful regardless of the technology set used (whether it's web-based, WPF, Swing etc.). Note that MVC is usually associated with GUIs, but there's no particular restriction and the pattern can be used wherever a model and its changes need to be reflected to different consumers with different views on that data.
No,
WPF and Silverlight are much more closely related than WPF and ASP.NET MVC. Silverlight is a seperate runtime and is basically a subset of .NET; Silverlight uses XAML markup for the UI, which supports a subset (and some web-specific) features from WPF and .NET.
ASP.NET MVC is Microsoft's implementation of the MVC pattern. What differentiates MVC from WebForms ("classic" ASP.NET web-development) is that MVC assists in using best-practices and giving the developer a high-level of control of the output of the application--WebForms was more RAD (Rapid Application Development) driven, making it easy to begin to work with--but putting some concerns about best-practes, pattens, and control to the wayside.
As for which is easier: MVC will likely be quicker to start with, but doing full-blown web-development requires a set of technologies (HTML/CSS/JavaScript/.NET) whereas WPF keeps your required knowledge more focused (XAML/WPF/.NET).
No. MVC is a pattern while WPF is a Microsoft technology.
You could with some effort likely use the MVC pattern in WPF but more popular in WPF is MVVM nowadays. MVC itself is not restricted to web only.
Grz, Kris.
2) Will be easy to learn other one If
i learn one of them ?
Shure: They both can be programmed using c# or vb. And they both can be programmed using Visual Studio.
But the same is true for any technology that incorporates .NET technology (Winform, ASP.NET, Silverlight...)