The following scenario came up in our project:
We have hierarchical business objects. The root node is meant to be a project. The project contains different kind of data in it. This data is split up in "Static Data", "Result Data" and "Control Data".
Project
|
+--- Static Data
| |
| +---- Dataset 1
| |
| +---- Dataset 2
|
+--- Control Data
| |
| +---- Dataset 3
| |
| +---- Dataset 4
|
+--- Result Data
|
+---- Resultset
The application has a kind of Project Explorer (like Solution Explorer in VS) that shows the data structure as it is shown above in a tree view. To achieve that I create different view models with the corresponding models, e.g. ProjectViewModel, StaticDataViewModel and DatasetViewModel for the leaves.
If the user clicks on one of the datasets a view opens that shows the data.
When I display the datasets in a other view, should I use the DatasetViewModel that is used in the tree, or should I create a new View Model (DatasetDetailsViewModel)?
Two things I read about the MVVM pattern:
1. The ViewModel should not be aware of how its data is displayed in the View.
2. The ViewModel is some kind of state machine.
Having those two points in mind I am not sure whether I could use the same ViewModel for tree view and details view. As on the one hand I could use the same view model, because it's just a different kind of displaying the dataset. The tree view is just showing the name of the dataset, whereas the detailed view shows the actual data that is contained. On the other hand, the view model is some kind of state machine, and the views may have states that do not fit together. For example if I have a visibility flag, I might set it to true for the treeview but in the detailed view I want to set to false.
So I am not sure if I should rather create a new view model or use the existing one from the treeview.
Opinions wanted!
Thanks,
Florian
I would probably leverage the hierarchical datatemplate in wpf see this article.
And basically it seems to me that you just need a TreeView control with its ItemSource or DataContext to ProjectViewModel and then create some other datatemplates for your other viewmodels.
See your ViewModel just needs to PROVIDE all the information for the view to display, it doesn't nor shouldn't care exactly how it gets displayed, or what technology displays it (e.g. WPF) . That's where MVVM is supposed to shine, it separates ui logic from the actual implementation of the ui.
DataTemplates are great because you can reuse sections of xaml. If you have a DataSetViewModel you can create a DataTemplate that will display that type a certain way without any further configuration on your side.
Everytime you want to create a new viewmodel you need to ask yourself, "Is there a viewModel that has all these properties already? If you answer yes, I wouldn't create a new ViewModel, less is more sometimes.
Hierarchical templates are good for usercontrols that have nested viewmodels
Related
I would like to build the following architecture:
There are 3 models - projects, views, and components.
A component, with different attributes for each type, is an item on a view or on a different component, and thus the blue lines. A view is an item on a project or on a different view (red lines).
I need to implement it in MongoDB (is there any other preferable database?).
How should I build the entities in spring to dynamically get the parent's data from the correct table (for components - sometimes it's from the components table and sometimes from the views table)?
Thanks!
I have a quick (hopefully) question on how to implement a composite field using MVVM.
I have 2 examples, one is on the sql end I am storing gps coordinates in the following manner "Latitude,Longitude" for instance "45.55555,-80.00000". the other example is storing feet and inches as a single double field with it being ft.in.
How should I go about this? Should I have two fields and in the model or Viewmodel composite them if the other piece exists? Should I bind them to the same field and somehow validate the sets?
thanks!
In the Model I normally use a structure/layout that is closest/easiest to the source so it can be easily/quickly read and written.
In the ViewModel I aim for a representation of the View to accommodate the bindings.
In general I make the ViewModel responsible for the transformation between the Model and ViewModel.
So whether or not a property of the ViewModel and the Model should have one field or two depends on the requirements of the View and the Source.
I'm using GWT CellTree to build a left-side navigation menu. There is no straight-forward way to traverse from the selected object to its parent node in a CellTree. One approach is to use recursion to walk through the tree and the other one is to design the business model in such a way that you map the children to their parents.
For example, a metric category can have subcategories (which are Metric Categories again) and Metric Items.
Metric Category
|
|_ Metric Category
|_ Metric Item
From your experience, do you know of any advantages / disadvantages with the above approaches?
Answering my own question -
There seem to be no obvious advantages or disadvantages with both of the approaches. Designing the business model to support it seems to be better as it gives more flexibility (just that you need to write more code).
I am using EF 4.0, linq to entities, VS 2010 and SQL Server 2005 Stored Procedures to do a small search application. I have designed the EDM and the required layers. The presentation layer displays the search results properly.
The dilemma now is that the search should be flexible enough to read from different tables. For example, for the present search the application is reading from table A. Tomorrow the application may need to read from table B which may have totally different column names than table A.
Using EDM how can i map table A columns to Table B columns , without having any effect on the presentation layer.
Any suggestions/pointers/links would be greatly appreciated.
Thank you so much for your time and help.
I have used the Data Repository explained in the below link it shows the IDataRepositoryand the DataRepository class. also how you can fetch data dynamically using the fetch() and Find() functions
http://huyrua.wordpress.com/2010/07/13/entity-framework-4-poco-repository-and-specification-pattern/
and its working pretty fine
I would recommend decoupling your presentation layer from your data. Create a business layer with a generic class that can be populated from different tables (entities) depending on your needs.
So, depending on the day, the generic class (or classes) would be populated from Table A, or Table B, or table X. However your presentation layer would be oblivious to this and only aware the data from the generic class.
You could design this a number of ways. One way would be to design an interface that the entities must conform to in order to populate the generic class. So no matter what the table structure is, you would need to map the data in it to the interface in order to populate the generic class and hence display it as search results.
I'm working on an table drill-down style iPhone app that has prepopulated data. I use Core Data and NSFetchedResultsController to populate the table views. In the last level of the table view which shows an item (managed object) I want my user to be able to select that item which should eventualy be shown in another view. That other view would be a kind of a favorite list (implemented in a tab view). The user would then have a choice of deleting or adding other items to the favorite list.
My model has three entities each representing one level of table view. Higher level entity has a to-many relationship to lower level entity and inverse relationships are to-one
How do I use the existing managed object (object in the last level of table view) to save it and show it in favorite list view? Should I create new entity and establish relationship between the two?
My model has three entities each
representing one level of table view.
That is thinking backwards. What you have is three entities that exist logically in a hierarchy and the hierarchy of views reflects that logical structure. The views exist to display the data, the data does not exist to display the views. It's an important concept to grasp and if you fail to do so, your application design will always be overly complex, fragile and hard to extend and maintain. The data model always comes first and the logical relationships within the data model itself and the users interactions with that data ultimately control the UI structure of the app.
It's an easy trap to fall into because the instructional materials always start with the interface first. However, in real app design, you start with the data model first and work forward to the interface.
In this case, if you want to store favorites of some entity you have two choices. If the entity being a favorite is part of the core relationship between data and the user and you only have one set of favorites, then you could legitimately add a boolean "isFavorite" attribute to the entity and then just fetch al the entities where "isFavorite==YES"; If you have multiple list of favorites then the best method would to to create a FavoritesList entity and then relate each favorites entity to the objects it is supposed to list.
If the favorites are a minor and peripheral part of the user's interaction with the data you could store the objectIDs in the user defaults.
Yes, you could create a new entity and store the relationship. It's not necessarily the only way to do it -- you could store pointers to your NSManagedObjects in a container like an NSMutableArray -- but if you want to remember that list for later (i.e. save it between launches), it might make the most sense to also store it using Core Data.