I was wondering what is the most conventional way to navigate between two unrelated view models using Caliburn.Micro? Let's say there's a tree of view models in one part of the application: ParentViewModel->ChildVM1->ChildVM2 and etc. Additionally there's an OmniVM which should be able to navigate to any of the aforementioned view models. By "navigating" I mean locating the appropriate instance (the activation part is straightforward after that).
I don't want to involve any usage of IEventAggregator, nor Container.Resolve kind of stuff.
Thanks for the response
devdigital said it in the comment and i am going to say it here again and as Rob (the architect who wrote the framework) would say it, Architecture matters in the UI too. This means you should consider how your presentation layer is organized. In other words, are you going to have a tabbed interface where the main window would be a Caliburn.Micro Conductor and the tabs conducted Screens, or are you going to have a Visual Studio kind of UI that uses docking windows and tool bars, consider this type of thinking when building the UI. Now if you don't like architecture and you just want to design your GUI then i could tell you that Screen and Conductor are the most important classes to consider for navigation. I Strongly Advise you to read the Screens, Conductors and Compositions article if you haven't already done so, it will give you an idea of what i am talking about and a bunch of helpful thoughts.
Edit: For your specific situation and since you have this deeply nested structure i would create an interface for navigation on the MenuViewModel, something like this:
public interface IMenuNavigator {
void NavigateToItem(Item i);
}
Then i would inject this into those inner view models, i think you have a feeling of what i mean. On the other hand, you can also use the IEventAggregator which is used for loosely coupled communication between unrelated components (viewmodels) such as in your situation, so you publish messages on the aggregator for navigation and the MenuViewModel listens to those and handles them correctly. You may even come with a better idea depending on your specific internal situation. Hope that helps.
Related
While adding extra functionality to the main view I have in my application, I've realized that the amount of code will soon become a problem (currently around 600 lines of code in my viewmodel and I still have plenty to add).
I've been looking around for articles on how to split/design your view into smaller components, but I haven't found a satisfying solution. One person suggested using child viewmodels but that presented with other problems (dependency between the viewmodels).
I've thought of using user controls, but there is nothing on the View that I use on other Views so it kind of defeats the purpose of user controls.
What is a correct approach in this situation?
Thanks,
Adrian
If you want to split a view into component parts, then you need to do view composition. If you are building an MVVM app, then you should really be using an MVVM framework. Something like Caliburn.Micro makes view composition incredibly easy.
There doesn't necessarily have to be dependencies between the view models, they should only know about what they need in order to produce their view. This could be a subset of the business object that the parent view model contains. As the parent view model will have references to all of the child view models, it can pass the relevant parts of the business object to them at the point of their construction.
I would agree with using Caliburn Micro.
However, to play devil's advocate you could split out your ViewModel File into separate files (same class name) and use the partial keyword before the class keyword. Its generally tidier and one step-away (non-breaking precursor) from breaking-up into separate classes.
I also agree Caliburn.Micro is a good solution for splitting your application in smaller components.
In Caliburn.Micro the communication between viewmodels is based on the Event aggregator pattern.
This makes a loose coupling between viewmodels
Splitting up is not ideal.
It looks as if the Caliburn toolkit focuses on events, whereas my application largely relies on ICommand implementations.
To me, the first encounter with Caliburn.Micro has been unsatisfactory.
The setup appeared to be tailored to VS2010 - which sounded promissing to me - because I do have VS2010 pro. But I got lost in the setup's of Silverlight.
Compared to toolkits like Prism it lacks the ease of an start.
It just takes to much time to switch now.
I use my own MVVM paradigm, it is less abstract than the Caliburn, it integrates multilanguage support everywhere, and it just faces one acceptable problem of some sources getting too big because of the nature of the Binding/DataContext paradigm.
For this problem I accept that "partial class" is a solution - even though I know there is a more elegant solution available.
In the heat of my work, I cannot change to another toolkit.
So I gently wait for Microsoft to allow for more flexibility around that Binding/DataContext paradigm.
It may be the case that Caliburn shows more intelligence allocating a viewmodel to some item. Does it ? (I think it does.)
What might be another option is to define a custom (xaml useable) object that triggers a custom allocator which control is to be allocated to which viewmodel. How about that ?
I am building a WPF app that is based on the MVVM pattern (using MVVM Light). It has an outer "shell" to it that gives the main look to the app (status bar, etc.) and then all the content is contained in various user controls that I swap out with the Telerik RadTransitionControl. My two questions related to this are as follows:
I am building my ViewModels using the ViewModelLocator part for Blendability purposes. This involves a basic static class that returns a new instance of a ViewModel for binding and instances are essentially shared as long as the app is running. The question for this is whether I should use a concept such as a "ViewLocator" in that it is a static class that has a static property for all of my views (the app has ~10 so it's not huge) and when I need to transition to a new view I just pull from the static set. The pros of this are ease of use, but are there cons? Is there a better way to pursue this?
What is the best way to transition views? Currently I am passing an enum to my shell view (via messaging) to indicate which view I need, but this seems really hacky and doesn't support passing certain views arguments. I toyed with a custom class, but I would almost need a different one for every view and it seemed like it might be overkill. What is the standard practice executed by WPF devs for this process?
Thanks in advance for the help. I'm fairly new to WPF so I want to make sure I learn the industry standards and avoid hacks wherever possible.
I work on an application that uses the same pattern. We have a static locator and reference the same ViewModel every time we switch to a different part of the application (details view, list view, map view, etc.) We have had a lot of success with the ViewModelLocator pattern - it is pretty easy to understand. We have not done significant testing with running the application for multiple hours.
We use a TabControl with the tab styling removed to transition between the main screens of the application. This gives us one point of entry (the selected index property that we bind on the "naked" Tabcontrol) to change the major screens of the application. For now, we do not use animations.
I like the concept of REST wherein each page is stateless. However, I haven't seen anyone using it in windows application. Way back, when I'm still using MVC and MVP patterns, one of my setbacks is handling states.
I don't know if this is a good idea, but I like to know your opinion on this. :)
Thanks.
I guess it depends on how you implement this. My view models typically keep state in properties that the views can bind to. However, I have sometimes found it useful to keep that state information in a separate object, which my view model hangs on to. My view can still bind to it and it declutters my view model.
I've built two large winforms apps using REST and I'm starting to experiment with WPF. WPF should be even easier.
I use MVC on the server for my REST resources and MVC on the desktop.
We were building out the next version of an in-house thick-client application using WPF/Prism (Composite Application Library). As we were nearly done with the client our team was put under new management and shortly thereafter:
We were then directed to drop the Prism framework to keep things simple. This includes not using any type of Inversion of Control.
We were directed to build out the WPF application without using MVVM or similar; and more along the lines of a traditional WinForm application. The idea is that if a developer sees a control in Visual Studio’s designer view, then (s)he should be able to click on the control and see exactly what it's doing without having to traverse through a view-model (or similar).
We have now been tasked with building out the WPF application using one primary Window, use a Frame Control to contain the content, and use a Ribbon outside of the frame for the menu items. Reason we were provided to use Frame Control:
a. We will show a view in the Frame with a Page (not a user control) and then load the page in the Frame.
b. When a new view is to be shown in the Frame, the current view (Page) will be closed/disposed and the new view (Page) will take its place in the Frame.
c. When a developer looks at the Page in design view, (s)he will be able to click on any control and see exactly what is being done.
Given the restrictions of 1 and 2 above, we’d like to present another method of building out the application that:
Can be presented as an alternative to using the “Frame Methodology” (item 3 above) but still provides the same type of functionality.
Does not use MVVM (see #1 and #2 above).
Provided the direction we’ve been given, any suggestions as to an alternative we can present? I’d request that the responses be kept on the professional level and thank you in advance.
I'd personally try to argue to use Martin Fowler's Presentation Model. (That's a joke, btw...)
Basically, you're being given a restriction that says "Use WPF, but don't use any of the features that make WPF usable." It really sounds like your requirements are such that you would be much better off explaining, reasonably, the advantages of patterns like MVVM.
It sounds like the weird requirements are really boiling down to this:
The idea is that if a developer sees a control in Visual Studio’s designer view, then (s)he should be able to click on the control and see exactly what it's doing
If that's the main issue, and the reason you're avoiding MVVM and other similar patterns, I would seriously take the time to educate the management. Looking at a Command, by name, instead of an event, by name (which is what you see in the designer) is really no more difficult.
However, in a large scale application, the separation of concerns is key. Even a properly designed Windows Forms application requires a clean separation of concerns - but with event based programming, this becomes much more difficult, especially from the designer. If you try to develop a large scale, clean, application using an event approach, you'll have event handlers, but those event handlers will all eventually need to delegate their work to a separate component.
This is actually adding an extra level of effort, from an understandability and maintenance point of view, on top of what you get with MVVM. With MVVM, you only look to the ViewModel, which is very discoverable.
BTW - The "rationale" for using a Page instead of a UserControl doesn't make any sense. You can do exactly the same thing you're describing with UserControls... The only reason to use a Frame and Page is if you want to take advantage of navigation, in which case, you can't dispose the old pages directly (or they get regenerated constantly). Also, the navigation tools probably wouldn't be used with a ribbon - the two conceptual models are quite different.
There are criticisms of MVVM which may be applicable to your project; however having unreasonable dictates of programming methodology is always a recipe for disaster.
One of the reasons that we have frameworks and spending time building layers and separation is to avoid the coding mess that always results when you can "simply click on the button in visual studio to see the code that is being executed".
There may not be a way of achieving what you've been asked to do without something similar to MVVM, because anything that has an architecture may well be labelled as being too similar.
However I have been using a system for many years that provides simple inter-object plumbing currently called Emesary you may want to read my C# .NET Emesary walkthrough.
But basically it allows my buttons to be implemented thus:
private void addButton_Click(object sender, RoutedEventArgs e)
{
GlobalTransmitter.NotifyAll(new Notification(NotificationType.CreateRecipe));
}
This may be an answer to your problem. It's under hyped, small and so simple but it just works well.
I've achieved a solution to the second question by using a Window, a user control for the ribbon bar (the user control contains the listview), and another user control for the Frame part. This second user control obvious is built using other user controls using a very simple view class. All views and controls are connected using Emesary.
As a school project I had to develop a WPF client which allowed for multiple people to make use of it at the same time. And I used Pages. My verdict: Save yourself a huge amount of effort, and use UserControls instead.
Sometimes the Page Navigator (which you'll use to scroll through) tends to bug out and cause you a lot of problems. Maybe it was my crappy coding, but who knows?
Though I must say, the control being called "Pages" is somewhat misleading... I went "Eureka!" when I found them, and swore at them thereafter.
I totally agree with #2 (MS bigs take note!). It would be cool if you could double-click a Control and it would take you straight to its command (or event if its command is lacking). However till then, make sure that you organize your Views and ViewModels in separate folders.
Having a dual screen (or a very wide one) will allow you to have two instances of VS open on the project, one focused around the View and the other around the ViewModel (my personal choice was having Expression Blend on the View).
Although not a very big application, I managed to convert my project to proper MVVM (ie. ViewModel for every UI element, RelayCommands and Mediator) in a matter of days, so once you understand it it's not too complicated to implement. Plus, there are tools out there (such as Josh Smith's RelayCommand and Marlon Grech's Mediator - totally free, by the way) which make MVVM half as difficult, and twice as powerful.
Using WPF without MVVM is like trying to eat rice without a fork. You'd be better off using WinForms if you're not going to take advantage of what WPF has to offer. My 2 cents.
I wish I could say your management is totally wrong.. but I cannot say that as it will not be the most accurate truth. I guess that the main reason to the changes you described is either because the new manager is not comfortable with the concept of MVVM being the new messiah of UI development or/and another reason could be the cost of educated sophisticated developers vs. cheap developers which can be instructed to get the things done as fast as possible, a concept which is widely known as lean development.
So, putting all I wrote so far under "not what you asked for", here is what I suggest:
you can still use object oriented pure approach, meaning you can have a model object which already have method to show UI information. so every object will be a window derived object, that way you will loose on SOC but you still going to be OOP/OOD.
But LOL, The next phase will bring you to seperation of model from view in order to not repeat the same code in many derrived windows which relay on the same data... so your management will endorse MVC/MVP as good solution .. and the distance from it to MVVM is kinda of short if they want WPF.
Conclusion: you will have to teach your manager why it is better to go for MVVM, unless the project is very short.
I have an app that has several modules that have completely different functionality and I'm trying to figure out the best way to implement this using prism.
To try and better explain, I'll try to use Northwind as an example. I have 3 modules, orders, customers & employees.
The customer module will allow you to do anything pertaining to a customer. Add, remove and edit. I'm going to use scope regions for the main view in the customer module to handle all the different views I need to show here.
In the scenario above, I only want to load a module when a user wants to work with say a customer, order or employee.
You have these modules laid out and realize that you need to be able to show Orders for customer or sales people which are obviously employees.
What would you do here in this scenario as you wouldn't want to create an entirely new modules for say employeeOrders and customerOrders and you wouldn't want to duplicate any order related code.
I'm starting to wonder if it's feasible to think about building a composite application using prism if you're building an app like Outlook, but for a LOB business app, I've yet to find a good sample of how to do this and not break some of the principles of MVVM and definitions of Prism in order to do so.
I'm just 3 weeks into Prism and still learning but this is the biggest issue I'm running into.
Any thoughts?
You should be using the Event Aggregator for these types of communication scenarios. Essentially, you want a module to provide functionality but also expose events that can be invoked from other modules. You can also register a service in the Unity container. For example:
public interface ICustomerOrderInvoker
{
void DisplayCustomerOrdersInRegion(string customerId, string regionName);
}
These techniques are somewhat orthogonal to MVVM. Your event handler can create a view/viewmodel pair and insert them into a region. Or your event handler can create a UserControl with all functionality implemented in code behind and adds it to a region. The beauty of the composite UI is that your modules can use MVVM and another team's modules can use straight forward user controls or MVP or MVC or anything really; the point is that all the modules are composed into one application regardless of how they are implemented because they use the patterns established in Prism like regions, events, etc.
In your particular case:
You have these modules laid out and realize that you need to be able to show Orders for customer or sales people which are obviously employees.
Your Order module will certainly be aware of the concept of a customer id since the Order entity is associated with a customer. The Order module should expose an CompositePresentationEvent that displays a view that has all the orders for a particular customer id.
The point of Prism is to create logically separate and loosely coupled pieces of functionality. This does not mean that the modules do not communicate with each other, but rather that the communication happens in a limited and loosely coupled manner. You can certainly write LOB applications using this pattern and MVVM; many of us have been for years now. :)
Im working on a similar problem (and am new to Prism too), as yet don't have a solution. I think when using Prism its tempting to use the framework as the reference implementation intends, but it doesn't need to be so.
Prism should (when used correctly) facilitate software development, not hinder it. So don't get too stuck in the idea that any implementation must meet strict decoupled refactorised super patternised standards!
What I am doing/intending to do is create a MainModule, which has in it much of my core functionality, including a MainView/MainViewModel user control. The Shell then has one region "Main" and on MainModule load the MainView is injected into it as per standard prism usage.
I'm using a Docking Manager from Telerik (compatible with Silverlight and WPF) on the MainView and have implemented a class IDockingManager / DockingManager class in Infrastructure which is registered with Unity as a singleton (ContainerControlledLifetimeManager) in the bootstrapper.
Anywhere in my app I can get the IDockingManager instance and inject a view by calling IDockingManager.DockView(IView view, DockingParameters args). The DockingParameters can contain information such as where to dock (Left, right, top, bottom, tabbed document) and also the parent container to dock in.
This is the part I've not got to yet - I can dock left/right/top/bottom on the main view but I want to implement an attached property or something on my child views registering them as a DockSite when docked. So for instance I could dock a Treeview on the left and dock underneath that a listview by using the Treeview name as parent DockSite and DockBottom as the side.
Hope that makes sense, I've rambled without really explaining too well. Basically what Im saying is Im not using regions at all (except to inject the MainView) in this application and have created a class to handle view injection into dockable containers. It's not strictly Prism but Prism is there to make my life easier, not the other way around ;)