28

This question is inspired from this closed question:

What does Prism actually offer the developer? And is it worth it?

I have already implemented my own custom MVVM implementations in enterprise applications. I am interested in knowing:

  • Why should I learn PRISM (specifically PRISM, not other MVVM frameworks)?
  • Benefits of PRISM over custom MVVM implementation and
  • Is it worth the investment in learning PRISM?

I hope this question is not subjective and everyone please don't get into arguments :)

Community
  • 1
  • 1
akjoshi
  • 15,374
  • 13
  • 103
  • 121

4 Answers4

26

As with many frameworks that do a common task for you, you get:

  1. Tested by many more eyeballs: than just yourself. This (hopefully) includes unit tests, which you may or may not be doing while building your own framework.
  2. More readable for other developers: nobody else has experience with your custom MVVM framework. But if another developer joins your project, or joins your team, or joins your company, they can jump straight into Prism code.
  3. Better documentation: Along the same lines, anyone new joining likely has to learn the ropes by manually gathering the collective knowledge from your brain, and any other users on the team, and by looking at the source code. Third party frameworks have their own documentation, and tons more blog posts on the internet.
  4. Better community: You can ask questions on StackOverflow about "how do I do X with Prism?" You can't ask that with your custom framework.
  5. Likely more capable: by needing to serve more users than just you/your team, more features will have been added. If you need to do something MVVM-related that you've never done before, chances are support for it isn't built in to your own MVVM framework. But it's likely in Prism.
  6. Better structure: Let's say you wanted to do something MVVM-related but it wasn't in Prism. Very likely, there's a good reason for that! If something's not in a (reasonably-mature) framework made for working in a given domain, that's a sign that what you're trying to do is an unnatural or awkward way of approaching the problem. Working with your own framework, it's too easy to say "oh I'll add that feature," then 6 months later realize you made a huge mistake because this new feature makes your code very hard to follow or ends up being a vector for lots of bugs or whatnot.
  7. A CV line-item: I would have mixed feelings toward hiring someone who had "implemented and used custom MVVM framework." While it could mean they're smart, it could also indicate the dreaded "not built here syndrome." On the other hand, putting "Microsoft Prism MVVM Framework" among a huge list of technologies could be nice, but isn't a wow-er. The best of both worlds would be a longer bullet point, along the lines of "Deep understanding of the MVVM pattern, achieved by first implementing a toy MVVM framework for learning purposes before switching to MVVM Prism." Yes, the difference between these three isn't going to make or break your CV, and not-built-here syndrome is something that would hopefully come up in an interview, but it's just worth keeping in mind, especially if you're applying for a place that gets enough resumes they can afford to throw out anything that unnerves them slightly.
akjoshi
  • 15,374
  • 13
  • 103
  • 121
Domenic
  • 110,262
  • 41
  • 219
  • 271
  • 9
    Good answer.. But for 7: I'd argue you can get away with a lot less code and mental burden with implementing your own MVVM framework that does exactly what you need and nothing more instead of incurring the PRISM cost.. If you look at MVVM-Light: Its hugely popular because it captures the simplest building blocks of the MVVM pattern without you having to understand a monster-stack with all it's magic like in PRISM. Simply said: Using Prism where you could get away with a 300 LOC framework that does what you want is simply not worth it. – Tigraine Jun 06 '11 at 12:30
  • @Tigraine: +1 for pointing out that Prism might not be the *right* MVVM framework, which was indeed part of the OP's question. Hopefully other people can give a better contrast between MVVM frameworks in their answers. Mine was more aimed at the "custom MVVM implementation vs. ..." part, which I thought brought a whole host of issues that people think about far less often than they should. – Domenic Jun 06 '11 at 12:35
  • @Tigraine: seeing your update: what's "not worth it" about using Prism vs. a 300 LoC Framework, if both do what you want? The only downside seems to be the possible scariness of a monster-stack with all its magic, but I feel like points 1--6 will definitely come up in applicability to your 300 LoC framework, as your application grows. – Domenic Jun 06 '11 at 12:37
  • 3
    I was mostly commenting on your 7. point as Prism is indeed a monster.. And I've had several projects where I had to slim down the stack so new team members and others helping out can get up to speed faster if they have no prior knowledge of the technology. And since the whole stack (WPF in itself is already pretty complex) is pretty heavy I like to have logical building blocks that make sense for the current project structure rather than having my people google "best way to do XYZ in prism v4" – Tigraine Jun 06 '11 at 16:16
  • 4
    but I am of course not at all against Prism.. I usually tend to use Caliburn.Micro .. but there are projects that can easily get away with 2-3 base classes (like the ones in MVVM light) and maybe 1-2 reflection based things to get you through the day.. and if you do reach the point where a full-blown framework does make sense you should be able to refactor.. – Tigraine Jun 06 '11 at 16:18
  • +1, for never seen an answer so marvelling without mentioning even a single tech-point :-). All true indeed. – NileshChauhan Mar 03 '13 at 21:08
9

PRISM can be interesting to you because it's more than an MVVM framework. Yes, a part of it can be considered in fact an MVVM framework (the NotificationObject, the EventAggregator and the Command objects are all examples of that), but it offers much more.

It allows you to create Composite Application of multiple loosely couples "Modules". It has a very flexible and extensible navigation framework (Region Navigation), offers integration with IoC containers (notably Unity and MEF) and a ton of other features.

Other than that, the documentation (including an ebook) is pretty good and comes with a lot of examples and quick starts. I believe it's worth the investment, which shouldn't be much, by the way.

Hope this helps :)

akjoshi
  • 15,374
  • 13
  • 103
  • 121
AbdouMoumen
  • 3,814
  • 1
  • 19
  • 28
3

Prism is an application composition framework with MVVM features, but is not (in my opinion) a fully-featured MVVM framework. It offers the minimum required to do some basic MVVM development.

See my previous answer to a similar question for a breakdown of application composition frameworks and MVVM frameworks. Most applications pick one from both categories:

Alternatives to Prism + MEF for modular MVVM apps

Community
  • 1
  • 1
Anderson Imes
  • 25,500
  • 4
  • 67
  • 82
1

With prism and MEF you can build highly extensible and maintainable. Net application. With each module with its own UI in its own separate dll. The only connection between your modules or extensions and MainUI will be region in which you will inject the UI of your extension. And believe me it's highly extensible and maintainable

iaminvinicble
  • 390
  • 5
  • 7