-2

I need to build our future business applications with WPF using MVVM.

My typical application consists of several windows/tab pages with grids and form style windows. Both edit windows and grid windows can be different depending on the logged in user, so most of them will be built datadriven. And I'm trying to write as few code as possible, as not written code is the only one to be guaranteed error free .

So, now my question: how to structure the entire thing?

The View is clear to me - is is built using XAML or by code.

The ViewModel should contain the business logic and the validation rules and should let feed the View the data, and should contain the commands for the actions.

So, where to put the data? A select returns a DataTable. Should this datatable exposed through the ViewModel to the View for the grid windows? And for the form windows? Should the single DataRow exposed trough the ViewModel to the View? Are there other helper or intermediate classes needed?

Thank you for any useful suggestion!

Wolfgang

Wolfgang Riedmann
  • 1
  • 1
  • I like to write for WPF beginners, and you might be interested in starting with this SO answer about [Transitioning from WinForms to WPF](http://stackoverflow.com/questions/15681352/transitioning-from-windows-forms-to-wpf/15684569#15684569) – Rachel May 19 '16 at 15:53
  • Thank you for your comment - it clarifies something for me, but unfortunately it does not answer my main question. – Wolfgang Riedmann May 22 '16 at 04:38
  • The ViewModel should retrieve the data, and expose it in a way that is easily consumable by the View, such as an ObservableCollection of items that represent each grid. After all, its purpose is to model the view. I would highly recommend not using a DataRow object, and instead write definite classes for your objects. Then if you have a Popup, Window, Control, etc that is meant to display one object, you can pass it the object it should be displaying. – Rachel May 23 '16 at 14:01
  • Thank you very much, Rachel! Do you mean to write one single class for every single model or a generic class? The underlying selects will be different for single users or selections by users. – Wolfgang Riedmann May 24 '16 at 06:06
  • You would typically create a separate Model class for each object you are representing. So if your select statements return the same object in two different queries, you would use one object Model to represent the item. But if they are considered different objects, you would have two separate Models to represent each item. – Rachel May 24 '16 at 13:23
  • For the same grid the user can select wich columns to see, and therefore the select is constructed dynamically. Also I need a flexible object model. In my current Win32 application, I'm using a database based dictionary for input masks, captions and hyperlabels of the various fields. And of course my new WPF applications should not go backwards in functionality. – Wolfgang Riedmann May 24 '16 at 18:47
  • Personally I would see about making your object model contain properties for all available columns, and only populate the ones the user selects. An alternative would be to make something generic such as DynamicDataRecord with properties for Column1, Column2, etc. Not ideal, but it would accurately represent the nature of your dynamic data. – Rachel May 24 '16 at 18:59
  • Thanks - I will follow your advices. – Wolfgang Riedmann May 25 '16 at 16:20

2 Answers2

0

Its best way to go with WPF and MVVM,

I suggest before you start go thru the basics of MVVM. for your reference you can understand better here

Abin
  • 2,868
  • 1
  • 23
  • 59
0

The preferred UI paradigm in WPF is to have tab controls and grids in a single window, something like this:

Comic Sans is not optional

You don't have to stop there, you can nest them as deeply as you need to for the sake of clarity.

15ee8f99-57ff-4f92-890c-b56153
  • 36,786
  • 7
  • 62
  • 114