2

I am in processing of finalizing MVVM UI framework for few WPF/C# applications, which we are expected to kick start. Just to deliver the idea, these applications can generally be categorized into small / large based on some quantifiable weight (eg. total number of screens and much more).

I presume to propose Caliburn Micro for small and PRISM for the large category. The rationale behind this is to avoid heavy weight framework since these applications are low latency systems (time bound) and I am trying to cut short all corners which is overkill.

But this is where I am stuck, as it is highly likely for an individual category to be elevated or lessen to other category. In such case, I might sometime end up having light framework for larger application (when we elevate category from small to large) or larger framework for small application (when we lessen category from larger to small). I am not so confident to go with my approach (two different type of framework) since I had rely on two different framework to achieve this with have no flexibility of switching.

Question: Is there any framework which has the elasticity to offload components, which i don't need in my application ?

S.N
  • 4,910
  • 5
  • 31
  • 51

2 Answers2

7

A big framework doesn't necessarily slow you down if you don't use all of it. Also, any framework will slow you down if you don't use it correctly. I've had hideous speed problems with Caliburn Micro in the past because I was doing things wrong - they go away when you do things right, but of course we all make mistakes.

Using two different frameworks for different classes of application sounds like a disaster waiting to happen. As you've already realised, something's going to change category, and changing framework is a very time-consuming process even in the best-structured code imaginable. Choose one and use it for everything, unless you have compelling evidence that it's unsuitable for specific purposes. Personally, I really like ReactiveUI, which is fairly unusual but does make getting things right an awful lot easier than Caliburn.

Whatever you do use, you're going to have to be very, very careful with WPF to make sure it keeps up with your requirements for display time, and do a lot of work with asynchronous functions to keep the UI thread available for rendering.

Matthew Walton
  • 9,809
  • 3
  • 27
  • 36
  • Thank you for your valuable comment. Quoting your first sentance, can you show me any quantifiable evidence ( probably a link says PRISM doesn't slow you down if decided use in small app). In such case, we are done. Thanks in advance. – S.N Jun 14 '13 at 12:30
  • 2
    I can't, but can you show any quantifiable evidence in the other direction? Can you show evidence that components you're not using but can't avoid loading due to the framework's design cause you performance issues? You can't make this kind of decision based on hunches, and you haven't detailed if you've got any evidence. – Matthew Walton Jun 14 '13 at 12:41
  • I have no evidence on x or x' as I am in process of listing out what would be ideal – S.N Jun 14 '13 at 13:28
2

I see no good reason to use different frameworks like you suggest. Pick one, and get to know it well.

we are expected to kick start

Unless the developers are already familiar with MVVM, I actually don't think there is any framework that let's you kickstart. MVVM needs to be understood well, but is a good pattern for complex applications.

Question: Is there any framework which has the elasticity to offload components, which i don't need in my application ?

Simply don't load components you don't use. Those frameworks don't load heavy components by default.

lightbricko
  • 2,649
  • 15
  • 21
  • (a) The concern is not about knowing MVVM but about a framework. (b) Offloading components means, components those are not used within framework should be able to offloaded. This is mandatory for me since small applications may not require all features. Hope it make sense. – S.N Jun 14 '13 at 12:37
  • There is certainly no good reason to offload components, at least not with prism. It's light-weight and if a prism-based application is slow, it's not because of prism. If you don't need a specific component, simply don't load it to begin with. If you **really** want to offload assemblies, then you can load them into an isolated AppDomain and then unload it, but there is no reason to. Also, prism is open source so you can customize it if needed: http://compositewpf.codeplex.com/ – lightbricko Jun 14 '13 at 12:59
  • Prism does seems overkill for small apps and you can see similar is been discussed here (http://stackoverflow.com/questions/4877481/wpf-is-prism-overkill-for-small-apps). The whole point was get it correct since we are at the incubation stage. It make sense for me the last point which you mentioned with respect to customizing Prism source based on my need.Let me sleep on it. – S.N Jun 14 '13 at 13:08
  • I agree with the accepted answer in that link. However, that question is about small applications, not about 'prism for large applications + another framework for small applications'. That is a very different scenario. Also, your link doesn't claim it's overkill regarding system resources (such as too many components being loaded). – lightbricko Jun 14 '13 at 13:16
  • The link is to give you a head start on why I not using PRISM as a generic solution for both application category. – S.N Jun 14 '13 at 13:22