WinForms and NHibernate, databindings and sorting - winforms

My final goal is to have a Grid with multi column sorting (by Ctrl-Click on the column headers) using data from NHibernate. For that purpose I plan to use ComponentOne's FlexGrid for WinForms. According to it's documentation it supports sorting if the given DataSource does so.
I'm not yet sure if I'm going to use paging. But if so, sorting should definitely take place inside or below NHibernate.
How is sorting supported by Winforms Databindings?
Are there any samples/classes supporting a bindable/sortable way connecting a Grid with NHibernate?

you can implement the interface IBindingListView which supports multicolumn sorting and set the implementor as datasource. It should work with Datagridview, don't know if FlexGrid supports it though.

Related

How to architect graphically-intensive Silverlight app using MVVM?

I'd like to create a Silverlight app using WCF Ria Services and the MVVM design pattern.
The main page of the app will consist of a "shell" and a large number (10s or 100s) of objects of different look (shape/size/properties) linked to each other (forming a sort of graph).
These items need to be mouse-draggable and their current position/state needs to be saved to the back-end database.
I feel that the best way to achieve this would be to have a small ViewModel and View for each item displayed, put all the important properties into the ViewModel and then somehow display all these Views in the main "shell".
However, I don't know how exactly this could be achieved. I considered using MVVM Light, but didn't find any example that would show something similar.
Can anybody point me to some examples or ideas about how this could be done?
"When all you have is a hammer, everything looks like a nail" :)
MVVM is not designed to manage graphic intensive situation like the one you describe. It is a glue for stitching together high-level concepts in a flexible manner. With MVVM you are adding overheads that will impact performance (e.g. binding uses reflection behind the scenes). The more objects involved, the greater the impact.
The best starting point I can suggest is to imagine what you need from a 3rd party control (e.g. a custom control/container) and, if one does not actually exist already, build it as if it were a third party custom control.
You will find in practice that custom controls are seldom based on MVVM, for performance reasons if not just because "they often don't need it". They may well expose MVVM compatible properties for the external interface, but not for the low-level internals.
MVVM is a relatively high-level technique. Do not feel you have to implement it on everything.
Following MVVM do the next:
Model - create model object which will be responsible for fetching and persistence coordinates of the shapes on the screen;
View Model - one view model which will initiate fetching and persistance model objects;
View - in your case, it's a place where you do most of your work. Create custom control based on ItemsControl with Canvas panel. Custom control should pass collection of the model objects in ItemsSource, allow to drag and drop containers and call the view model command when user drops container in some place
Have a look at the Telerik controls, specifically radTileView, this seems to have the functionality that your looking for. They also have a persistance framework that should allow you to save the position of the tiles back to you database.

UI control with grouping

I'm looking in silverlight for a control that support grouping and the possibility to customize the group header with a template (like a grid with text and images)
I tried the DataGrid, but I can set only a String as the group header (or if I'm wrong how can I display a string and two images?)
Thank you
Francesco
BTW: I'm using MVVM and bindings.
EDIT: I'm looking primarily to something standard (microsoft) or free component. Or we (the company for which I work) already use ComponentOne.
You didn't specify free or not but if you are looking for off the shelf products Telerik offers a number of Silverlight controls. Their RadGrid allows for custom datatemplating as well as your other requirements of grouping and image usage.
Another good one that I have used on testing but never in production is jibGrid on Codeplex. You may want to check that one out as well jibgird on CodePlex It does support grouping but I can't recall usage of images in the header.
If you are looking for using the default datagrid you can customize the header and column headers using datatemplates See this msdn link for more information As far as grouping, sorting and filtering this is not offered out of the box as with the aforementioned controls. To do this you will need to write a little code own your own. This msdn article provides some steps on how to accomplish this.
Hope this helps
I decided to use the FlexGrid of ComponentOne.
In this way I used the grouping mode to group (together with the disclosure function), and the merging function to merge the first column of each group.

Should we use server generated XAML to deliver our Silverlight/WPF UIs?

Back in January 2009, Dino Esposito published an article on MSDN titled "Managing Dynamic Content Delivery In Silverlight". We are considering using an approach like this for an upcoming project and were wondering if anyone had any advice on whether this is a good approach. Are there any traps or pitfalls we should look out for? We currently use Prism and would need to look at how the two would live happily together.
Yes! This approach, in my opinion, is what makes Silverlight and WPF so incredibly powerful. I have done this in the past and it is AMAZING how well it works. Data binding and ViewModels make it especially easy to do. Even better is if you use the dynamic capabilities of C# 4.0 to push dynamic properties into your ViewModel that your View can bind to. In other words, you can push down dynamic values that your dynamic views can bind to.
When you get it all working, it is beautiful.
A bit of self promotion here, but my ViewModel base class has a lot of support for this type of dynamic data binding approach.
As far as doing this with Prism, you can take advantage of the modularity Prism that prisim was built with. You can override the RegionRegistry, for example, with one of your own that knows how to create the dynamic view given the region name.
Beautiful, Beautiful stuff here.

Do any of the .net data classes implement INotifyPropertyChanged?

Short question:
Do any of MS's built in Data Objects support INotifyPropertyChanged?
Long explination:
So I'm going to be displaying alot of data with databound controls.
The data is going to be chaging somewhat frequently with user interaction.
The application is a basic windows form app.
Rather than wire up events for all the data to the display controls I'm hoping that I can use data objects that implement INotifyPropertyChanged, that way the controls don't need to know the how, when or why their data changed just that they need to update themselves.
Sanity check:
Am I even barking up the right tree here?
The point of INotifyPropertyChange is to report property changes. To that extent, it's supposed to be implemented by specific model classes, not by general-purpose data objects. A more general solution for such objects is provided in form of PropertyDescriptor.AddValueChanged - since PropertyDescriptors can represent "virtual" properties, such as DataRow fields, or WPF attached properties.
I have been working for a few months on a rather large windows forms app, and we are using DataBinding and INotifyPropertyChanged for everything. It works really well, and I have no real problems to report. We are using our own classes, because there really isn't a data layer in this application, so I don't know for sure about the MS data classes.
BindableCollection< T > implements INotifyPropertyChanged

Is DataGrid a necessity in WPF?

I have seen a lot of discussions going on and people asking about DataGrid for WPF and complaining about Microsoft for not having one with their WPF framework till date. We know that WPF is a great UI technology and have the Concept of ItemsControl,DataTemplate, etc,etc to make great UX. Even WPF has got a more closely matching control- ListView, which can be easily templated to give better UX than a traditional Datagrid like display. And I would say a readymade DataGrid control will kill or hide a lot of creativity and it surely will decrease the innovations in User Experience field.
So what is your opinion about the need of DataGrid in WPF as a Framework component? If you feel it is necessary then is it just because the world is so used to the DatGrid way of data display for many years?
Some other threads having the discussion about DatGrid are here and here
Link to WPF ToolKit - Latest WPF DatGrid
DataGrids are excellent for displaying large amounts of tabular data bound to a backing store.
But what happened in the WinForms world was that people often used them for everything that required a multi-element scrolling list. Souped-up third-party DataGrids soon became available that allowed columns and fields to contain buttons and ComboBoxes and icons, etc.
The DataGrid became a workhorse because there was a need for something it could be coaxed into behaving like. Similar happened to DataTables before generic collections came along--and when you're using lots of DataTables, presenting it in the UI with a DataGrid is the path of least resistance.
I think that when WPF came out, a lot of programmers like me were still thinking in this fashion, and sought out WPF ports of the DataGrid concept.
Can't think of a better control to display tabular data, especially in business apps where you don't want to reinvent the wheel by templating/developing a (Headered)ItemsControl to make it behave like the good old DGV. I'm sure you saw this.
Nobody is disputing that you can make a DataGrid control in WPF yourself. The same can probably be said about WinForms, although it would be more difficult. I've implemented some functionality with ListView - presenting tabular data is easy, you could even say it's well supported. However, the amount of code, manually written code, needed to make an editing ListView is enormous.
The business applications usually require editing of many tables, and you don't want to be creative, you want to be quick. That's why DataGrid is needed in my opinion.
Yes DataGrids will never go away as essential business UI components. People love their spreadsheets and we want to share in that love!
Note that MS are shipping these extra controls - they have created the WPF Toolkit on CodePlex to provide a fast-turnaround, open-source style of deployment.
It already includes a DataGrid and Calendar.
Yes it is!
Among many other controls that ms failed to deliver. (Datepicker, NumericControl)
MS should first give us the tools to get the job done, that is the least i expect from a programming enviroment with the hype of wpf.
It is essential, but you can achieve nearly the same effect with a ListView that is using a GridView, can't you?
After working with WPF for about 2 years now. I would say that a DataGrid is really just a glorified ListBox (since [almost] everything in WPF is styleless).
One could style a ListBox to take an Entity of some sort and show a "record" control for each entry. Depending on how flexible these are made, they could automatically adjust based on the entity passed.

Resources