I've been doing some prototype work on a new Silverlight application using Caliburn Micro as our MVVM Framework. The team has generally been happy with it. In order to address some issues with throttling requests to services, it was suggested that I look into ReactiveUI's ReactiveCollections and their implementation of INotifyPropertyChanged.
Does anyone have any experience around using the two together? Since they are both primarily MVVM Frameworks, there's a good bit of overlap, so I wonder if it might be more trouble than it's worth to try and make them work together.
Some of the things we really like about Caliburn Micro are:
The Convention based binding, etc...Very nicely done in our opinion.
Bootstrapping. We like the way this is handled, it's easy to extend when you need to, but the out of the box stuff works well for many of our use cases.
Composition/Screen Management. We really like Rob's notion of conductors, screens, etc. It flows very nicely for us.
The ReactiveUI stuff that has drawn us to it (at least initially).
The Reactive Collections and INotifyPropertyChanged stuff. Particularly
the ability to throttle the reactions.
Reactive's asynchronous stuff seems a bit cleaner to deal with than Rob's Co-routine implementation.
I've barely had a chance to play with ReactiveUI yet, but as I was looking at it and seeing the overlap between the two, I wondered who might have tried to work both into a project. I haven't been able to find anything via Google (which could well be my fault).
I'd love to know if you tried this; what issues did you have? Which parts of each framework did you use and why? Are there any good examples or blog posts out there on using them together?
Cheers,
Steve
Use both! This blog post should get you most of the way there - it's actually very easy to take existing ViewModels that use other frameworks and "RxUI'ify them". This way you can try out ReactiveUI on a single ViewModel without having to pick either Caliburn Micro or RxUI.
Related
I have a WPF application that should be compact, with minimal possible memory footprint. The GUI is simple from the point of view of flow, few pages and grids, but quite rich from the point of view of graphics, animations etc.
I have experience writing applications with Prism and I like it very much. But it looks too heavy for simple tasks. It is not a LOB application, but I still need testability, GUI/flow/business separation etc.
Should I use MVVM anyway?
I am not sure if the overhead of using the MVVM design pattern is something I should worry about or not when trying to minimize the memory usage of my application.
Yes, use MVVM if you're working with WPF
WPF is designed so you have a UI layer and a data layer, and this suits the MVVM design pattern perfectly. I find it makes the coding and maintenance much faster and easier.
You don't have to use a full fledged MVVM framework, or even any MVVM framework at all. You can pick and choose the parts you're interested in using (a base object that inherits INotifyPropertyChanged, a RelayCommand or DelegateCommand, the messaging system, etc) and drop all the rest. Or you can build your own.
The amount of overhead is minimal and definitely not worth avoiding the pattern for, however some MVVM frameworks do include unneeded features and can cause some overhead, so be sure you only pick the pieces you want out of them.
The point is, use the MVVM design pattern if you're working with WPF. It will make your life, and any future developers that work on the project lives, much easier :)
I really would recommend using MVVM.
We used the pattern in a huge project and it worked well, with the following recommendations:
we use the very useful, and as the name says, light, MVVM Light Toolkit lib
we do not use the ViewModelLocator thing. Too hard to make it work when you dynamically instantiate Views. The good old this.Datacontext = new TheViewModel(); in the code-behind is fine
we do not use the Messenger thing. Too complicated for very little benefits. A good old event fired from the view model is way more simple IMO.
we do not use the EventToCommand thing, which complicates the XAML for nothing in lots of cases.
we do write code behind when the code is purely related to the view. For mouse gesture features (drag & drop...) or other specific UI things, code-behind is fine for control events handling.
First of all: Yes, MVVM is a recommend way of how to architect an C# / WPF application
Second: You can use MVVM with not framework at all, then it is as lightweight as you build it.
Look here for an overview of possible MVVM frameworks:
SO in depth discussion of different MVVM frameworks
I am pretty new to WPF and I have an discussion this morning with my architect who is from C,C++ background.
We are trying to create a video calling application which depends on native dlls by making PInvoke. The WPF application is mainly the UI and in code behind we are making Pinvoke Calls for Video /Audio and listing the available drivers.
So If we are talking Data as from database then there is not much of the "Data" involved in our application.
The WPF application we are trying to modify is Boghe and surprisingly they too are not using MVVM.
While I am keen on implementing MVVM the architect points it as unnecessarily splitting the files in to 3 parts.
He says if we want to change any thing in the view like changing a button or any control then it can be directly done in code behind. Why then use MVVM?
Though I have theoretical answers but can't help but agreeing to his point. Is he actually right?
He says if we want to change any thing in the view like changing a button or any control then it can be directly done in code behind. Why then use MVVM?
Of course it can be done this way. The question is whether it should be done this way.
For a fairly small code base, you can probably get away with mixing up data access, core logic, and UI manipulation in code behind. In the long run however, that will not make for maintainable or testable code, and the mess is likely to get worse over time and turn into spaghetti code. Take my word for it, because a good portion of my time at work is put into reversing such old messes.
Some consequences of mixing everything up in code-behind are:
Code that fundamentally violates the "Single Responsibility Principle" (SRP).
Code that's hard to understand because it does very different things all in the same place.
Code that breaks easily. I change something here and for some arcane reason, some feature breaks over there.
Code duplication / violation of the "Don't Repeat Yourself" (DRY) principle. You often find the same logic in several places. Is this accidental, or on purpose? If I change logic here, must the same/similar logic over there be changed too?
Note that with the exception of the first point, these are not theoretical concerns, but very real, immediate problems of your typical "legacy" code base.
In my opinion, it's not entirely correct to say that MVVM introduces more code-behind classes. This is clearly a statement from someone who does not appreciate the fundamental separation of concerns that comes when you isolate the data, business logic, and UI logical layers from one another: Even with MVVM you have only one code-behind class for your views. The other two classes (yes, there will likely be two more) simply can't be considered "code-behind" because they aren't directly tied to the view / designer.
Short Answer: No!
ViewModels are not the same as Codebehind in different files.
With a proper MVVM implementation, you do not have a codebehind, or at least
a very small one.
But in the ViewModel you do not have direct access to the window, as in MVVM
the communication between ViewModel and View is done over Binding, there is
no direct reference to a View (normally).
MVVM brings in some enormous advantages over view centric approaches.
It is testable, it is far easier changeable, it is an adapter, ...
edit
And if he really is your software architect, he should know better...
at least thats what I expected from a software architect
I too agree with stakx and Mare Infinitus; MVVM provides a lot of benefits and is not just creation of multiple code behind files.
From my experience MVVM is the best way to learn and use the power of WPF, it kind of encourages and forces you to use WPF features like Binding, Commands, Styles, Converters etc. I have seen application's being developed without MVVM and they turned out to be WPF application in Winforms style having problems stakx mentioned (and more).
Apart from UnitTesting(which I think is very imp. in your application), re-usability etc. one very important benefit of using MVVM is that it can support multiple views, i.e. you can have multiple UI's for your application all of them can use same ViewModels; This may not be a requirement for you today but you may require to have a new interface few years down the line or support other platforms like Silverlight or Metro in future, MVVM will save you a lot of effort in that case.
I would suggest you to go through this post which explains real benefits of MVVM and explains other so called benefits (although I feel they are real benefits in practice) - MVVM Backlash
one purpose is that you can unittest your view logic(viewmodel) without the view.
here one nice comment from Rachel regarding viewmodel first approach:
Remember, with MVVM your ViewModels are your application. The View is
just a pretty interface that allows users to interact with your
ViewModels.
If you have only two people in the project, and everyone's all-in-one person, he's right.
But if you do not want designers messing up the controller (or ViewModel), or programmer that changes view to something, you know, as programmers do design.
In addition, You have the clue where to do changes immediately, without searching enormous text files.
Also, the separation by MVVM or MVC is one of basic principles of programming, it's Data-Logic-View separation, and if architect says you not to do it, may be it's time to ask another architect :)
I hope the title reflects what I'm really asking. It seems to me that when people undertake XAML based development whether to use MVVM is not even a question, rather an understood fact. Coming from a background of Winforms and Webforms, I found that we almost never used MVP (for example). It was well understood that the main reasons to go down the MVP path (other than being a purist) is higher level of unit testing, and the ability to share "view logic" with different UIs. As far as the later is concerned, it has never been a requirement in my projects. If anything we might have had several user controls for this purpose.
As far as unit testing, I never found it necessary to test my code behind because it did nothing more than handle UI events and act as a proxy (create instance of and bind) to my business layer. I can understand if people bypass the business layer and create instances of their favorite data access layer directly in the code behind, then apply business logic to it right there, where MVP would be a huge benefit. In my cause I always front the DAL with a BLL, so where is the real "win" here as far as unit testing?
Point being it was never automatic to use MVP. I am now looking at possibly using Sliverlight (for the first time) in a project and I feel like I'm going to be committing a sin if I don't use MVVM.
I know there are a slew of little things that are MVVM specific perhaps that were not a consideration before when I was making the "to MVP or not to MVP" decision. I've read about Blend support (I don't even have Blend), maybe some other important aspects? The bottom line is though, is MVVM really that much more important to Silverlight than MVP was to Webforms for example? Or are we riding the renaissance days of .NET development where patterns and best practices are taking center stage (sort of like Java).
We moved from Vb.Net winforms to C# and WPF/Silverlight under MVVM. It is definitely a change of pace from our adhock coding. I love being able to create multiple views to work with the same view model. Makes it easy to customize screens for our customers that want it without a whole lot of programming changes.
I found these posts in Stack Overflow that might answer your questions:
Benefits of MVVM over MVC
Why MVVM and what are it's core benefits?
MVVM Unique Benefits
Those have some good answers comparing MVP to MVVM.
Hope that helps.
**** Additionally **
If you were referring to Expression Blend, I used blend when I first learned xaml. Now that I know what I am doing in it, I rarely use it unless I need to do something complicated with animation or whatnot. I use visual studio for coding it since, from my experience, Blend is still cumbersome. Don't get me wrong, it's a great program and does animations great, but it's for designers, not coders really.
From my limited experience with WPF and MVVM, my opinion is this:
MVVM is a pattern, but is not the end-all-be-all of WPF. Especially in the case of MVVM "purists." There are times and places for event handlers and code behind, even in WPF. The benefit of the xaml development and MVVM is the separation of logic from design, but at times, you logic involves your design much more directly than MVVM allows.
I guess the main reason why MVVM is so advocated because of the power of DataBinding.
With web forms for example, you will need to create your own interfaces, framework etc... to implement MVP, whereas in Silverlight/WPF, databinding is just there, so whether or not you use it, it is up to you.
In my opinion, I think MVVM simply adds in a layer of testable view logic (ViewModel) instead of like the MVP pattern where your business logic can really be in the presenter itself.
In summary, if it is already there, easy to use, use it.. it is like you have a car, but u can still choose to walk 10miles to your nearest market, or you can drive (most would advocate you to drive).
Thats my 2 cents.
I am a little out-of-date in WPF right now and would be interested to hear peoples opinions on the latest version of Prism (which I used a couple of versions ago) vs an MVVM Light + Unity approach (which I have never done - decent examples URLs would be good).
My project will be a large one comprising multiple modules written by several developers. There is also the funds to bring in a 3rd party control suite in order to set up a nice workspace using one of the fancy Docking/Workspace layout managers out there (and I know some play better with the Prism regions than others).
If you were starting a project from scratch right now, what would you go with and why?
Details on specific recommended architecture patterns would be useful (e.g. auto discovery of module dlls? Injecting logging service?).
Basically, any thoughts and advice would be good. I'd like to get a good discussion going. Perhaps there is another direction entirely that you would suggest going in? I'm very much in the research phase and would like as much input as possible.
I put this on here because I thought it would get less biased points of view than the Prism/MVVM Light forums but, if there is a more suitable place for this question, please point me in that direction.
If you need modularity, you'd want to look at Prism. Prism has some elements that can help you with MVVM (DelegateCommand and CompositeCommand, for example), but I think it's more complete with another MVVM framework.
There was a question a few days ago about how to model Prism. Check that out for a detailed explanation of how to consider Prism's functionality.
High Level Modelling Advice for Prism MVVM
Unity is an implementation of an inversion of control container and it's definitely good, but Prism has the ability to use other containers. It has builtin support for MEF (which, in turn, is builtin to .NET 4.0), but it's not your only choice. Look at some of the samples included in Prism and decide what approach you like better. Unity is not complete on its own for UI compositing in my opinion. MEF might be a closer choice if you wanted to try to composite a UI with the MVVM Framework + IoC Framework approach.
MVVM Light is actually a complimentary framework to Prism. Other MVVM frameworks to consider:
MVVM Foundation (very lightweight... good for small projects)
Caliburn (very robust framework)
Caliburn Micro (shares a name and an author from Caliburn, but it's akin to MVVM Light with some nice conventions)
ReactiveUI (Formerly "ReactiveXAML". This is a bit of a brain melter, but if you learn Reactive Extensions for .NET (Rx), this framework is simply amazing... magical in my opinion.)
If I were going to start a new project: I would go with Prism and ReactiveUI.
Prism because you have to have modularity with large projects and I like the ability to remove and add large units of functionality to an app just by deleting or adding DLLs (and you don't have to implement the DLL sniffing feature like you would with just an IoC + MVVM approach). Easier to test, easier to debug, easier to develop separately. Nice all around.
ReactiveUI because with UI programming these days, most of your time is spent managing your time on the UI thread. Blocking is a no-no... users don't want to see a UI freeze; they want to see that animated GIF wait symbol spinning so they know they can work on something else while your data is loading. In addition, so much of the value applications provide these days is taking data from disparate systems and putting them together in the UI... not only will you need a good compositing system (Prism), but you will also need a good MVVM framework that treats asynchronous operations as its bread and butter... ReactiveUI is it.
I have to develop a basic "line of business" application with the usual functionality like orders, stock control, sales, reports, etc.
I will use WPF to develop this application to run on Windows but I want to develop it "open" so I can do a Windows Forms application using the same structure (maybe to run over Mono) or even a Silverlight module. Can someone that did something like that (and survived) give me a sugestion on a guideline or something like that where I can find good practices? I'm a Delphi developer with some intermediate knowledge on C# but there are so many "amazing" libraries, frameworks and patterns that I'm a little lost on what would be good for that project.
Something like: Use EF (maybe wait for ef4?) or nHibernate, or ADO.NET, and expose your data using WCF, or webservices, or forget Mono because of the flexibility loss, etc. Can someone give me a tip on how you would do it? If someone has a bad experience in this type of project, it would be nice to hear from you as well. There is a lot of learning in the wrong decisions too :)
Mono doesn't implement WPF, it's not even on the roadmap. I'm not sure about Entity Framework...
You could probably do it in Silverlight (which has an open source implementation), but it's not ideal for creating desktop (although it is possible since Silverlight 3)
Where do I start?
First, from your description, you're in over your head.
Second, you're trying to pick a technology stack when everything is new to you.
In the best situation, I'd recommend a good training class in a few of the technologies you mentioned so you get a better understanding of them. I'd also recommend a mentor, someone who's done this before.
Reality though, may not allow for training or a mentor. In that case I'd recommend writing several real-life throw away programs. Take one piece of business functionality and try to write it in a few of the technologies you mentioned. If one feels better, and gives you what you want DECISION MADE! Don't stop with the first one that seems to work, try some more.
You should also listen to some good podcasts. I recommend Dot Net Rocks for a good grasp of the technology. The earlier podcasts for this site were also a very good source for some design discussions StackOverflow podcast
Best of luck.
I had to do something very similar recently in WPF. I have an ASP.NET background, but I have never worked with WPF (or WinForms for that matter), and it had me stumped for a while, but the longer I have been working on it (about 3 weeks now), the easier it has gotten. I really just searched Stack Overflow and Google for code snippets similar to what I was doing, and worked through them and changed them as needed. My company bought a book that helped me out as well (It was WPF Unleashed published by Sams), and it was pretty good. I do wish you luck on your first WPF app.
If you separate the business model and business logic from the user interface,
using MVC (Model View Controller) or MVVM (Model View View-Model) or a simular design pattern,
then you can have multiple user interfaces connected to the same business model + business logic and even connect the same user interface to other business models + business logic.
Thank you all for your suport... Brad, I'm already following your advices, doing some test cases to see what looks good... my problem is that altough I can develop an application in WPF and have a intermediate understanding in using the wpf databindings, generics, linq, anonymous objects, all the cool stuff, I always hear about this and that as the solution for all the worlds problems (like mvvm, or parallel programming, or functional languages, etc) and makes me feel "wrong" in my decisions and a bad developer if I do not use any of this nice technologies. I know the concepts but do not dominate it, and seems a lot of things to learn, sadly I do not have that much time.
Thomas, exactly because mono do not support WPF i want to make the application as isolated as i can, so I can do a simple winform layer to manipulate the data.
darthnosaj, thank you, I'm doing that too, searching internet and found much information (and this nice site full of hellpful people :) )
And Danny, thats what i think i need... will take a look on some sample applications using mvvm and see if that works for me. For what i heard is almost a crime not to use in that case in wich I want that kind of isolation.
Again, thanks all :)
I would suggest you keep your application N-Tier. Make all the entities, data adapter, and business logic separated from the actual desktop application. This way you can use WPF on the Windows platform and use Mono/GTK# on the Linux/Mac platforms.
You will only need to write duplicate code to support the actual GUI application functionality, while your code from the separate entity/data access/business logic library (e.g. DLL/class library) can be used in both your WPF and Mono/GTK# projects. Just add the DLL as a reference to the WPF and Mono/GTK# projects.
There is a good video from Channel 9 on building N-Tier applications
There is also MSDN documentation and guidelines on building N-Tier applications