I've been using EntLib for some time, and have recently found Unity. At first glance it looks like it handles most everything that EntLib does, but seemingly lighter-weight.
Which is recommended for day, MVVM architecture, and pros/cons of one over the other?
Thanks.
Unity is a dependency injection container with support for interception. EntLib is a library of 9 application blocks, one of which is Unity. EntLib has a much broader scope, it handles other cross-cutting concerns - think of logging, validation, exception management, data access, caching, etc.
Back in 2008 when we were designing Unity during our work on EntLib4.0, we quickly realized that it is something that many developers can benefit from by itself. That's why we shipped it standalone.
EntLib5.0 is fully DI-driven, and it uses Unity container by default. You can swap it out for another container if you wish. The same goes for Prism, which is container-agnostic. If EntLib was designed to be leveraged in any layer of your app, Prism was designed specifically for building composite UIs (in WPF and Silverlight). EntLib and Prism are complementary, not overlapping.
Unity is a dependency injection container and its own application block; whereas EntLib is a grouping of application blocks which Unity could in theory be part of.
You also have Prism which wraps Unity/EntLib and varying blocks to produce a buffet of varying blocks geared towards MVVM development in both Silverlight and WPF.
Initially I would say head towards making use of Prism as you will already be familiar with EntLib and can make use of Unity as your DI container. Prism also easily lets you use what you need and ignore what you don't from the varying blocks.
Related
I am looking into potentially using Caliburn Micro for an upcoming Windows Phone and Windows RT application and I'm wondering if it's possible, or advisable, to reuse view models across both platforms?
I have seen examples using Portable Libraries and in another framework called MvvmCross, but I'm not sure if I could do this using Caliburn because I can't add Caliburn to a Portable Library and therefore can't share interfaces, such as INavigationService, with view models sitting in the shared portable library.
I am thinking of simply having one set of view models for Windows Phone and another for WinRT.
Any ideas on how to proceed?
As an experiment I took parts of CM and made it portable so my view models could live in a portable. I mainly wanted to take advantage of screens and conductors in a portable and only have one set of view models.
The creator of CM has mentioned making CM 2.0 support portables but it will be a decent amount of work.
I've experimented with MvvmCross and the v3 stuff is really slick even if you're not targeting iOS or Android.
So, for CM, the only option with the current version is to have separate view models for WinRT and WP.
I'm building a workbench/IDE style application which uses MEF to locate and load tools into the workbench at start up.
I'm using MVVM Light to build the workbench and the separate tools. I've got a point now where I want tools to be able to communicate which each other and the workbench.
I don't mean direct communication, more like "Hey I have some data here if anyone's interested" and interested tools can pick up the data.
This looks much like C# events and I know I can export an interface from my tool(s) which defines the event(s) but I'm also wondering about using the MVVM Light messenger to provide the communication.
I've seen on here that people are using the EventAggregator from Prism to do the same thing and as the messenger from MVVM Light is roughly analogous I figured I could use it.
I'm after advice really, has anyone used the messenger for MEF - MEF object and would you advocate it over plain old C# events.
What you are looking at here is the mediator pattern. You could use plain old C# events to do the same thing... but do to it right you would most likely end up implementing your own kind of pub/sub pattern. And if you are going to do that, why re-invent the wheel?
I like using prism's EventAggregator because it is part of the Prism framework injected with MEF. I use a lot of other things from Prism, so it's nice to get this for 'free'. It also promotes loose coupling with your components, and like all of the good mediator implementations it is implemented with the weak event pattern which prevents the memory issues you would need to avoid yourself when destroying objects that have subscribed to an event.
For what it's worth, I used to use MVVM Light, but I found Prism to be a more mature framework, with better documentation, examples and a larger user base to learn from. That's really just my opinion- I know loads of people who love MVVM Light. Play with them both and pick the one that makes you happy :)
I've decided to dabble a bit in MonoDroid and MonoTouch and port one of my WP7 apps as a starter. I would really like to reuse my existing ViewModels but since both Android and iOS seem to have no such thing as XAML's strong databinding I would like to ask if anyone went that route before and can recommend some best practices or existing solutions.
We're doing this with an application right now, but writing for iOS first (even before Windows). It is not full of rainbows and ponies for sure.
I would recommend the following:
Use a MVVM framework on Windows that doesn't require you to expose ICommand on every action the user takes (like Caliburn, for example), it also shouldn't require a dependency to it from within all of your ViewModels.
Conditionally inherit the WPF-specific pieces of your ViewModelBase class, you can do this with partial classes or an #if iPhone directive. INotifyPropertyChanged or ICommand are examples.
Use an IoC container, it is very helpful to abstract out things like saving settings to the filesystem which will be very different on all platforms. Also helps to sort out your dependencies as well, which is very helpful for separating out platform-specific code from non-platform specific.
Use a "messenger" of some kind (example here), usually included with an MVVM framework. This is a must in my opinion, at least for iOS. Apple's MVC is so all over the place, it's better to have global messages you can subscribe to in a weak referenced (and decoupled) way.
Use MVC on each platform like you would natively, then treat each ViewModel as you would if you were calling it manually. There are no UI bindings, no ICommand, so keep your ViewModel's simple.
Linking files is the best trick ever. You don't want a copy of each view model per platform, so make sure you know how to link to a file within projects in Visual Studio and MonoDevelop. This also makes #if iPhone and #if Android statements possible.
I know you are working with an existing application, so it's tough. It may be simpler to just reuse your business model and that's it. Android and iOS have MVC patterns of their own, and are drastically different from WPF. You might also only need a subset of each ViewModel on mobile devices, which could make it easier to just rewrite.
In our case:
We're using TinyIoC (also has it's own messenger)
We will use Caliburn-Micro when we start on WPF, we don't need some of the features in full Caliburn
I've recently finished a large project which we wrote wp7 first, and which was then ported into touch and droid.
As part of this we've released our own mvvm framework - including some databinding support for touch and droid - the source is available at http://github.com/slodge/mvvmcross
The experience of porting to droid was good - the axml layout files provided a good hook for databinding. Currently, however, i'm not quite as happy with the binding we achieved for touch - although montouch.dialog does at least provide us with some nice looking code sometimes.
I have to create now a multi-screen Silverlight 4 RIA application with MVVM.
Each of these screens has to be devided in multiple regions (for example master-detail scenario whereas each of them is a different section and one has control on the other).
Can you give me some ideas what should be the right way to implement such an application?
Is Prism the right choice? I started reading the Prism manual and liked very much the idea of having regions and screens switched and controls in a very flexible manner, but, as said above, I find it too overkill to split it all over many assemblies.
If Prism IS the right choice, then I would appreciate any kind of guidance or reference to guidance on this particular scenario (multiple screens & regions and OTOH not getting my solution spotted with a gazillion projects.
I believe that PRISM is the correct choice for building an application with multiple regions and views. You could argue that that is almost the definition of a composite application.
But I would also remember that you don't have to use all the components PRISM has, you can pick and choose. I would recommend that you consider each aspect of PRISM and test/prototype to ensure you are happy with the facilties offered. In a large application I have built I use PRISM but after some prototype investigations I only used EventAggregator and the Modularity capabilities.
I chose not to use the region support as I found working with ItemControl and ContentControl components in Silverlight gave me the ability to inject views and partial views into my interface.
I found experience from ASP.NET MVC proved useful in considering how to coordinate/break up my UI into partial views.
Hope that helps. The Stocktrader application is a great example to learn from (included with the PRISM distributable).
I have a relatively basic question but more than anything just need some clarity really, I have been using Prism (Composite Application Guidance) to create a WPF MVVM desktop application in C#, this bit I am all clear about (or so I thought) along with IoC and Module based architecture etc. At the same time I have started using MEF and realise that there is a kind of grey area between the two (I have found and read a number of articles/blogs on hosting MEF Extensions in IoC containers and the like.
However....recently I have started looking at Enterprise Library 5 and this is whats led to my confusion. Where do they all fit together? So Prism uses DI with a Module based architecture... EntLib uses Di with an Application Block type architecture... and MEF doesn't use DI at all? Does this mean that EntLib and Prism are entirely separate architectual methods or that one is a subset of the other? Also could MEF be used with either/both?
Any explanation would be most welcome.
Many thanks
I, too, was puzzled by the difference between IoC and MEF. The simplest way I found to describe them, was this:
MEF is for discovering and instantiating something you don't know about.
IoC is for requesting something you do know about.
A little bit of context. MEF will always instantiate the import that you request at least once. You are not capable of creating it yourself, and putting it into the catalogue ready to be used. MEF is responsible for creating and satisfying the imports. Dynamically loaded DLLs, where you don't know which DLLs are arriving, is a good example.
IoC on the other hand - you request an implementation from the current library, and you are given one. But you are also responsible for ensuring that an implementation exists.
IoC is for dependency injection. MEF is for extensibility.
Take a look at these 2 posts:
Should I use MEF for my general IoC needs?
Prism and MEF
As to Enterprise Library, in v5.0 we've made it container-agnostic. Even though Enterprise Library ships with Unity container out-of-the-box, it is architected to work with any container of your choice or MEF. You do need to provide an appropriate configurator (see info on configurators at the end of this summary)