dialog box for updating data???

dhubbuck wrote:
Hi
We are moving forward with GUI for .NET and wondering what you feel about using dialog boxes to update add data.
We have created a basic shell form which will be used to show the views of our application.  One of the views would be a grid based on an ultragrid control.  Rather than update on the grid we are planning to bring up a child form for adding new records and modify existing data.  We are using a model class for the data. Also working with Prodatasets and TempTables on the UI.
Would you
     create a new temp-table record in the dialog box.
     write it back to the db on the ok button
     refresh the ultragrid and reposition to the correct row.
or
     Share the model and bindingsource with the grid and dialogbox as though we are adding the row within the grid?

From my experience there are a number of reasons to create a new temp-table record in the dialog box (and process it separately):

- you might need more information than is present in the grid. i.e. more fields. You don't want to download that extra information for every record in the grid if you don't need it there.

- your update mechanism for 'multi record' data in the grid (which, by the way, is display-only) is probably going to be different from the 'single record' update mechanism that is sufficient for the dialog (much simpler indeed)

in both cases you need to refresh the grid since data may be created at the server side, such as key values.

Since the dialog is modal there is no real benefit in reusing the model of the grid.

Unless, of course, you are thinking of allowing updates in the grid as well.

Also our main shell screens usually have a gridview dockpanel and then multiple panels grouped as tabbed dockpanels.
We have passed  the buffer from the bindingsource so the tabbed views using a binddata method.  This allows us to show the current rows buffer values in the tabbed views everytime the bindingsource position changed event fires.  Does this seem reasonable or are we going down the wrong track?
Anybody got any thoughts about the above?

I am not sure what you mean by 'we have passed the buffer from the bindingsource'. You can use the same bindingsource in the views. Here it does make sens to do that. Unless, again, the viewers show considerably more data than the grids. It all depends on the amount of data, the number of records, the network capacity and the required scalability of your application.

Since the dialog is modal there is no real benefit in reusing the model of the grid.

In Gui for .Net, forms are only modal because they are called that way; the same form can be called non-modally via oForm:Show(), as opposed to WAIT-FOR oForm:ShowDialog(), so I believe you should design for the more general case unless you want to only ever allow a form to be modal. So I would re-use the grid's Model - IMO the grid is just one way of viewing that data.

From my experience there are a number of reasons to create a new temp-table record in the dialog box

Does the dialog box have its own Model? If so, why? Or do you simply create the TT in a 'side-channel'?

(and process it separately):

I came across Command Query Responsibility Segregate (CQRS) the other day (http://abdullin.com/cqrs/ ) which almost exactly mirrors this. From that link,

" In an oversimplified manner, CQRS separates commands (that change the data) from the queries (that read the data). This simple decision brings along a few changes to the classical architecture with service layers along with some positive side effects and opportunities".

Is this more-or-less what you're advocating, Peter? I like the principle (in principle but don't have any experience with it.

- your update mechanism for 'multi record' data in the grid (which, by the

way, is display-only) is probably going to be different from the 'single

record' update mechanism that is sufficient for the dialog (much simpler

indeed)

Transaction scope might be one way they differ, but what are the other differences?

(this is probably also a good conversation for one of the architecture-minded sub-communities)

-- peter

Hi,

Thank you for your email. I'm currently out of the office travelling for business. I will return on November 24. During my absence I will have no or very limited access to my email. For urgent matters, call me on my mobile and leave a message on my voice mail or call our office.

Best regards,

Wouter.

--

Wouter Dupré

Senior Solution Consultant

Progress Software NV

Stocletlaan 202 B| B-2570 Duffel | Belgium

Office +32 (0) 15 30 77 00 | Mobile +32 (0) 478 50 00 49 wdupre@progress.com

Also our main shell screens usually have a gridview dockpanel and then multiple panels grouped as tabbed dockpanels.
We have passed  the buffer from the bindingsource so the tabbed views using a binddata method.  This allows us to show the current rows buffer values in the tabbed views everytime the bindingsource position changed event fires.  Does this seem reasonable or are we going down the wrong track?
Anybody got any thoughts about the above?
I am not sure what you mean by 'we have passed the buffer from the bindingsource'. You can use the same bindingsource in the views. Here it does make sens to do that. Unless, again, the viewers show considerably more data than the grids. It all depends on the amount of data, the number of records, the network capacity and the required scalability of your application.

As Peter says, you can re-use a binding source and bind multiple UI controls/elements to it (from different forms even). So you'd have something like the below. Note that Panel-1 is basically one or more controls on a panel/frame/form (so it could be a grid or some text controls). Obviously you can have more than one PBS per Panel.

                                     / Panel-1
Model - Query-1 - ProBindingSource-1 - Panel-2
                                     \ Panel-n

You could also create multiple queries against your Model and have one form/panel/control .

      / Query-1 - ProBindingSource-1 - Panel-1
Model - Query-2 - ProBindingSource-2 - Panel-2
      \ Query-n - ProBindingSource-n - Panel-n
 

I prefer the latter since I can selectively show different sub-sets of the Model's data in different Views (forms); I can also now use a model as a client-side cache without too much extra work. In  my worlld, the ProBindingSource should be a very simple, lightweight control with the Model doing the hard work of query management, data fetch/commit (server) and create/update/delete (local to model).

Would you
     create a new temp-table record in the dialog box.
     write it back to the db on the ok button
     refresh the ultragrid and reposition to the correct row.
or
     Share the model and bindingsource with the grid and dialogbox as though we are adding the row within the grid?

So in other words, I'd go with #2 here in the sense of the Model being shared and the add-row functionality being the same regardless of whether it's in the grid or a dialog.

Which approach you choose depends on what you consider your model and its responsibilities to be. I would say that the most important thing is that you have one Model for one logical set of data; how you present that data just needs to be consistent across your application.

-- peter

pjudge wrote:
I came across Command Query Responsibility Segregate (CQRS) the other day (http://abdullin.com/cqrs/ ) which almost exactly mirrors this. From that link,
" In an oversimplified manner, CQRS separates commands (that change the data) from the queries (that read the data). This simple decision brings along a few changes to the classical architecture with service layers along with some positive side effects and opportunities".
Is this more-or-less what you're advocating, Peter? I like the principle (in principle  but don't have any experience with it.

This describes exactly what I am advocating (although I don't have time to follow the link now).

I have quite a lot of experience with both approaches (the most recent one NOT being the CQRS approach) and am convinced CQRS is the best way for the following reasons:

1. Performance

2. Simplicity

3. Performance

P.S. Did I mention performance?

So my biggest questions is whether it performs well.

Where - roughly-speaking - do you see the performance benefits most? I can see that passing only 1 row (assuming you've only updated 1 record) for a 'commit' operation vs. passing the entire temp-table is hugely beneficial.

And does it differ significantly from the case where a service-oriented app has one save_data.p (in-out dataset (with 1 row)) and a fetch_data (in context, out dataset)?

-- peter

Thanks for the input everybody

The CQRS link seems to be what I was thinking. I'll have a look at in more detail and try and get my head around it.

I came across Command Query Responsibility Segregate (CQRS) the other day (http://abdullin.com/cqrs/ ) which almost exactly mirrors this. From that link,
" In an oversimplified manner, CQRS separates commands (that change the data) from the queries (that read the data). This simple decision brings along a few changes to the classical architecture with service layers along with some positive side effects and opportunities".
Is this more-or-less what you're advocating, Peter? I like the principle (in principle  but don't have any experience with it.

I have successfully played around with an updatable grid following some of the John Sadd Walkthroughs for basic CRUD operations.

In my Model I would have a method to FetchData and also a Method to add a new Model Row before its saved back to the database.

I could then call my SaveData Method to write the Model changes back to the database.

So are we saying I could use this same Model within the form for adding/updating records as we have with the grid.

        / View1Grid - Model1 - FetchData Query1 - PBS1 - UltraGrid

Shell                        \

                                  View2AddForm - Model1 AddModelRow - PBS2 - TextBox1

                                                                                                        \ TextBox 2

Or would we create a new instance of the model for the AddForm  

Or would we have a new Model for the AddFrom

You could also create multiple queries against your Model and have one 

form/panel/control .
      / Query-1 - ProBindingSource-1 - Panel-1

Model - Query-2 - ProBindingSource-2 - Panel-2

      \ Query-n - ProBindingSource-n - Panel-n
I prefer the latter since I can selectively show different sub-sets of the 

Model's data in different Views (forms); I can also now use a model as a 

client-side cache without too much extra work. In  my worlld, the 

ProBindingSource should be a very simple, lightweight control with the Model 

doing the hard work of query management, data fetch/commit (server) and 

create/update/delete (local to model).

I like the Idea of the above do you have any sample code of the above with a form with a grid that calls another from to update the record?

Thanks again

Dale