Looking into various MVVM frameworks for SL. In the Caliburn documentation I saw a code in a controller that calls MessageBox. Is this right or is this just for intro? Is there something like MessageBox service in Caliburn like in Chinch MVVM?
It's indeed introductive code, just to demonstrate that the controller method is actually executed. Yet, I agree on the issue you pointed out: the presence of raw UI code in the presenter could lead to an inappropriate mix of view concerns.
About the MessageBox service: in Caliburn v2 (trunk), ShellFramework module, there is a Question/Answer ViewModel abstracting the functionality of a MessageBox, with the advantage of letting you to design the UI for the dialog.
Also, it's very straightforward to roll your own IMessageBox abstraction and provide a basic implementation using the default WPF MessageBox.
Marco is correct. This is just to demonstrate that the action is called. I wouldn't recommend this in practice. I will try to make some changes to the samples or add some comments that make this clearer. Caliburn has services built-in for calling custom message boxes.
Related
I am loving MvvmCross so far, but I am new to the MVVM technique. MVVM seems to center around the View and ViewModel and navigating between them. However, what about application-wide model items? Maybe my application has a mode that it can be in that affects all views and viewmodel behavior. This seems like an ApplicationModel or ApplicationViewModel. Or maybe just use the App class itself to store application wide stuff? What is the recommended practice for this concept? If using the App class itself is a good idea, I assume there is an easy way to get a hold of the reference to the App instance from anywhere? Haven't looked yet.
A ViewModel is a Model for a View - so that's where the current MvvmCross focus sits.
For this application wide behaviour, I think it's best to consider it one use case at a time.
The example you've provided is:
Maybe my application has a mode that it can be in that affects all views and viewmodel behavior.
There's not much detail here, but for this type of thing I might perhaps:
place this Mode inside a Singleton service
would use a messenger to send ModeChangedMessages when the Mode changed
would provide that service and the messenger to the relevant ViewModels using constructor injection
the ViewModels can then subscribe for ModeChangedMessage on the messenger
would perhaps use inheritance in my ViewModels to share code between them (ie they'd inherit from a BaseViewModel class)
There are of course other ways to do this, but that's one suggestion
If there's some other application wide use case you'd like to ask about, please ask another question - but please include more detail - eg perhaps provide some pseudo-code about what you want to share. I find real use cases easier to work out - abstract ideas are harder to talk about.
If it helps:
There's an introduction to services and constructor injection in N=2 on http://mvvmcross.wordpress.com
There's an introduction to the Messenger on N=9 in http://mvvmcross.wordpress.com
I'm new at C#, WPF and MVVM pattern. Sorry for this quite long post, I am trying to set all my points of understanding (or non understanding).
After studying a lot of texts on the commanding mechanism provided by WPF and the MVVM pattern, I have a few problems getting my mind straight on how to use these things.
I understand that the commands provided for WPF allows to define multiple "calling points" for command logic that is held in a component of the visual tree. When a command is called, the call bubbles through the visual tree (starting at the command target or the focused element) until it bumps into an element holding a CommandBinding that defines where is the command logic.
What seems nice about that is that you can define public commands without specifying either the logic nor the calling points at first.
I also understand that following the MVVM pattern, the ViewModel of a View should handle the logic whereas the base WPF implemtentation of commands only allows visual elements to handle it because the call bubbles through the visual tree.
I then found that custom implementations such as Josh Smith's RelayCommand can be used in this case, as you bind a command called by an element of the view (button for example) to the RelayCommand object in the underlying ViewModel.
But then, I dont see how it's a command (by the definition of WPF commanding pattern) anymore since we're directly specifying an implementation that is referenced in the ViewModel. With this method, we loose all the benefits of being able to call a command from anywhere without knowing where the logic is implemented. In this case, why not directly use a Click event handler (for example) ?
Could someone explain me where I'm wrong ?
(thanks for those who read the post to the end !)
Regards.
NR
But then, I dont see how it's a command (by the definition of WPF commanding pattern) anymore since we're directly specifying an implementation that is referenced in the ViewModel.
This is still a command, and implements ICommand, but it's no longer taking advantage of the routing strategies built into WPF. It's a command, but no longer a RoutedCommand - so in a sense, you're right - it's not following the original concepts of WPF's routed commanding infrastructure, but it's still a command.
With this method, we loose all the benefits of being able to call a command from anywhere without knowing where the logic is implemented. In this case, why not directly use a Click event handler (for example) ?
You're still keeping the benefits of having the logic separated from the View. The View doesn't need to know how this is implemented, and the ViewModel can implement the command without knowing how the View will trigger it. The command can still come from a gesture, a button, etc - and be changed (completely within the XAML), without changing the logic and code at all.
Switching back to event handlers breaks this - if you use event handlers, changing the View's implementation requires updating the event handlers (code behind).
After some further research on how to use the original WPF command behaviour in a MVVM project, I found this link : http://matthamilton.net/commandbindings-with-mvvm !
From what I understand, it provides a way to "attach" to the view, CommandBindings handled by the viewmodel. This way, the viewmodel would be able to implement a commandbinding that would be discovered when the command call walks the visual tree.
Bye.
I'm over-thinking this and getting myself into a muddle but can't clear my head.
I'm new at WPF and I'm trying to get familiar with MVVM. I understand the theory. I need a view, a model and another model (called the view-model).
However, what happens if my model is constructed by a parameter of the View's constructor.
So, assuming I have a totally empty project, the only thing is I've an overloaded MainWindow constructor which takes the model:
public MainWindow(Logging.Logger logFile)
{
InitializeComponent();
this.DataContext = logFile;
}
The Model is the logFile. Can I still implement the MVVM when I don't have a separate Model class?
Any thoughts would be appreciated.
You're overthinking this.
There are several components to MVVM:
View:
The view provides a, well, view on the data. The view gets its data from a viewmodel
ViewModel:
The viewmodel is there to organise your data so that you can organise one or more sources of data into a coherent structure that can be viewed. The viewmodel may also perform basic validation. The ViewModel has no understanding of the UI so should not contain references to controls, Visibility, etc. A viewmodel gets its data from services.
Services:
Services provide data from external sources. These can be WCF, web services, MQ, etc (you get the idea). The data the service returns may need to be shaped so that it can be displayed in the UI. To do this you would take the raw data from the service and convert it to one or more Model objects.
Model:
A model object is an object that has been created so that it can be easily displayed/work with the UI.
You may find that you don't need to shape your data coming from your services (lucky you), in which case there's no need to create model objects. You may also decided that you don't want your services talking directly to your viewmodels but instead what to have them get their data via a "mediator" object. That's also good in some situations (usually when you're receiving a continuous stream of data from a source/multiple sources).
MVVM is a bit like porridge: there are lots of potential garnishes you can add, but you don't necessarily need to add them all. Or want to.
Does this help?
Edit: just stumbled on this: a more in-depth expression of what MVVM is:Mvvm Standardisation. This may also be useful
The Model is something the ViewModel will know about but not the View. If you need to present info about a Logger, you can certainly have a LoggerViewModel that knows about a Logger, and in turn the View winds up getting to know about the ViewModel. There are several ways to do that, and setting the DC in the view constructor is one of them.
After that basic understanding of who knows about who, what really makes the MVVM architecture pattern, IMO, is that ViewModel communicates to the View via databinding. Nothing more and nothing less. Lots of goodies come out of this, but that is the crux of it that makes it different than other separation of concerns patterns (like Presentation Model, MVP, etc)
That said, you need to get a feel for it by working through some sample projects. Asking questions here on SO is fantastic when you get stuck on something, but you must realize your question here is a bit fuzzy at best. Also, unless you are really looking to present logging info in your view, logging is not an MVVM concern. Its interesting alright but not MVVM.
Google Josh Smith's MVVM demo on MSDN for a perfectly meaty yet approachable beginning sort of project. And ask more questions or refine the one here as they come up!
HTH,
Berryl
forget the view! at least at the beginning ;)
try to think about what you want and what you need. what i understand is that you wanna handle a logfile. so you need a viewmodel for that.
public class LoggerViewmodel{}
you can put the logfile as a parameter to the vm ctor. now you have to think about what you wanna do with your logfile? for everything you want create a property (LastModified, LastRow, whatever) on your viewmodel.
btw there a two different ways to do mvvm, first is view first and the other is viewmodel first. i do both in my projects and take the appraoch wich fits better (viewmodel first the most time ;)) to my needs.
pls edit your questions and add what you wanna do with your logfile, then we can give you a better answer.
edit:
Can I still implement the MVVM when I don't have a separate Model class?
to answer your question the short way - yes you can. you have to seperate the view and viewmodel and use binding to bind the view to the datacontext(viewmodel).
I'm using MVVM and Unity, I've understrood how to show the shell View (MainView with its MainViewModel) but I couldn't find the right way to instantiate other windows, for example : Details Button that opens a new form and show other details.
So, I'm looking for a common way how to instantiate/Call other Views(WPF windows) with their ViewModels using MVVM and Unity.
This answer may help with understanding how to link multiple views/viewModels together. I don't typically find myself needing to open additional windows just displaying different views in the current window.
Please let us know if you're looking specifically for an MVVM solution for opening new windows.
Take a look at this answer: Handling user interactions in MVVM. You can utilize an interaction service to instantiate new WPF windows will still remaining decoupled.
You can also provide indirect communication in WPF by leveraging the Mediator pattern to publish a message from a view model that causes a new view to be instantiated. This answer Simple Mediator implementation gives a quick overview.
I recommend you read over the User Interaction Patterns guidance, as it covers many of the scenarios you will face when using MVVM.
I am currently using caliburn.micro in my WP7 project and I am quite happy with it. My application is very data-heavy, so I took a look at Agfx (http://agfx.codeplex.com), seems it can save me a lot of time on data requesting and caching.
But the problem here is that agfx also provide a base view model, while I've already had one which inherits Screen of caliburn.micro. Of course I can encapsulate a new view model base which inherits ModelItemBase from agfx, and implements IScreen. But I kinda don't like this, is there any better soultion or best practice you can share with me about how to integrate the 2 great frameworks?
Best Regards,
-Peng
I am actually using AgFx with another UI framework which has its own ViewModelBase. My own understanding is, the ModelItemBase that's provided by AgFx is a model base rather than a viewmodel base. It basically takes care of the data.
My viewmodel which inherits from my ViewModelBase, does a lot more stuff like Tombstoning, application bar bindings, etc. It's designed for displaying the data on the view.
I think it fits in mvvm and works out really well. Hope this helps. :)