Timeline for Create an instance (view) given its dependency (view model)
Current License: CC BY-SA 3.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 31, 2015 at 2:17 | comment | added | devuxer | Thanks for taking the time to follow up and get to the bottom of this :) I'm definitely not converting anything. Just trying to wire up view models to views. I agree the container would be a good place to do this. I've done something similar to what you're suggesting associating Attributes with Filters in ASP.NET MVC. I'll give your suggestion a try next time I run into this situation, which I expect to be soon. | |
| Jan 30, 2015 at 22:43 | comment | added | moarboilerplate | In that case, a UserControl is a valid View. I think I misunderstood your question to mean that you were converting from one type to another (my mistake, your question is certainly clear enough, but the context did help). As long as you're not converting, but you are treating a viewmodel as a dependency of a view, it's a valid design. Now that I understand your original question, you'll want to register each concrete type in your container with the same interface, defining a specific name for them, and wire your view registrations up telling Ninject to bind x type to y parameter name. | |
| Jan 30, 2015 at 22:08 | comment | added | devuxer |
In WPF terms, I would think of a Window as a top-level view and any UserControl that I place in a Window as a child view. Perhaps I'm using the wrong terminology? In any case, binding each UserControl to a view model is pattern that has worked well for me on several projects.
|
|
| Jan 30, 2015 at 21:56 | comment | added | moarboilerplate | With the exception of dealing with multiple windows, I would say, generally yes. You might have reusable components of views, but they should not be treated as views themselves. I'd be interested in seeing an example of a child view, and what makes it a view. | |
| Jan 30, 2015 at 21:46 | comment | added | devuxer |
I'm not sure what you mean by "breaks the paradigm"? Are you saying that any given page/screen in my app should be represented with a single view file? I'm not saying that I don't have single views that bind to hierarchy of view models (I'm working on an example right now with an ItemsControl, where the ItemsSource binds to a collection of child view models), but for complex views, it can be helpful to break them up into child views, particularly if some of those child views are re-used in other views.
|
|
| Jan 30, 2015 at 21:15 | comment | added | moarboilerplate | Okay, I see where you're coming from with the need for a POCO view. However, I still question the need for child views. What is your reasoning for a 1:1 relation between a view and a viewmodel? It breaks the paradigm. Generally one view handles one parent viewmodel, and knows how to access/bind to its child viewmodels. So you might have an OrderViewModel with OrderItemViewModel children, but only an OrderView that binds to the collection of children. | |
| Jan 30, 2015 at 19:35 | comment | added | devuxer | For more on why I'm building some views in C#, see msdn.microsoft.com/en-us/magazine/dd483292.aspx. | |
| Jan 30, 2015 at 19:35 | comment | added | devuxer |
I essentially have a hierarchy of views and a pretty much identical hierarchy of view models, with each view bound to a corresponding view model. What makes my situation unusual is that I have a mix of XAML views and C# views (due to performance issues with WPF ItemsControls). For XAML views, I bind the DataContext to a property on the view model, but for C# views, I pass the view model into the constructor. In this particular case, I did simplify my code somewhat by eliminating the dictionary and using LINQ OfType and Concat instead, but I maintained the basic strategy.
|
|
| Jan 30, 2015 at 18:59 | history | answered | moarboilerplate | CC BY-SA 3.0 |