WPF Prism + Existing WPF Application

I've an existing application.

With about 3 years of good experience with WPF/MVVM - I feel I should have started with Prism (I've no knowledge of PRISM framework as of now - and I plan to learn it now).

Goals are to - - Make the appication a SOLID (design) based framework. Existing code is mix of MVVM (recent new features) and code behind model (existing features)

Since it's a massive application - moving everything to Prism would be quite a task.

Questions: - I plan to start a new development (a big feature implementation). Can I use Prism for the new development? I am happy to write most of the components from scratch and slowly go function wise to move entire application to Prism.

eg Existing front office real time trading application, planning to add back office/middle office functions to it, and slowly move front office functions to Prism.

  • I have a feeling that learning PRISM can be as much learning curve as it was moving from winforms to WPF - is that true? any suggestions about Books that I should follow? I am a bit of procedural learner and prefer step by step learning from basics (ie everything about Prism).

  • What are the massive advantages I am going to gain with Prism. Can there be any performance hits at GUI level?

  • Regards, Vinay


    I recommend the official guide which by the way begins by defining Prism as follows:

    Prism provides guidance in the form of samples and documentation that help you easily design and build rich, flexible, and easily maintained Windows Presentation Foundation (WPF) desktop applications. Using design patterns that embody important architectural design principles, such as separation of concerns and loose coupling, Prism helps you to design and build applications using loosely coupled components that can evolve independently but which can be easily and seamlessly integrated into the overall application. In short, these applications are "built to last" and "built for change." These types of applications are known as composite applications .

    I've highlighted the sentence that I think best summarizes along with the term they use to refer to this kind of applications: composite applications.

    If your application could benefit from having loosely coupled modules then Prism may be the way to go. For instance, when developing an ERP, you may choose to implement each relevant functional area as a module. You may want to be more granular and use modules for different parts of the UI such as in the stock trader reference implementation.

    I haven't found the learning curve to be significantly steep. Indeed, the guide is quite well organized and you can go straight to the concepts you require in each moment without having to read the whole thing. By no means is such a change as moving from WinForms to WPF: it builds on the MVVM foundations you are familiar with, adding some higher-level abstractions and using some known patterns such as publisher/subscriber events.

    Bottom line is that for decently sized applications, you should gain maintainability by investing in using Prism. Being already proficient in MVVM, the learning should be pretty easy.

    EDIT : answering comment

    So, I could start a PRISM based GUI set in the existing WPF application?

    Absolutely, yes. You can take the bits you find useful, and most likely use more and more eventually. Be advised that you may need to change the initialization of your application to implement the Bootstrapper. However, it is not compulsory, so just take a look at the patterns and start using those that you see fit. It's not an all-or-nothing framework.


    Migrating an existing app to Prism is quite an undertaking. Having part of an app be Prism while part of it not be is possible but I think you'll find yourself becoming very frustrated at having to jump back and forth between the 2 worlds and having to find ways to get them to play nicely together.

    I personally wouldn't go down this path. If you are looking to get the benefits of dependency injection, then it would be much easier to gradually adopt a dependency injection library than to adopt the much much larger Prism framework. Specifically, as you are building new features write them such that their dependencies get injected... initially this code will fail so then you'll go to where each of those dependencies are actually defined and add a line of code to register them with your DI container.

    链接地址: http://www.djcxy.com/p/84598.html

    上一篇: 通过数据绑定将代码传递给代码

    下一篇: WPF Prism +现有的WPF应用程序