Should the program logic be inside the gui object class or external to the class?

Question

I have a question on how to structure the code regarding GUI objects. Suppose I have a dialog in which there is a list control that contains a bunch of names retrieved from the database. User can edit names. Does logic exist inside this dialog class or should it be externally. To illustrate what I mean, there is some kind of pseudo-code showing the structure of the code when the logic is processed outside the dialog class:

NamesDialog : wxDialog { Private: ..stuff.. Public: ... SetNames(wxStringArray names); wxStringArray GetNames(); ..stuff.. } 

This way the class user will do something like:

 wxStringArray names = DatabaseManager::Get()->GetNames(); names.Sort(); NamesDialogObject.SetNames(names); NamesDialogObject.ShowModal(); wxStringArray modified_names = NamesDialogObject.GetNames(); AddToDatabase(modified_names); //or something like this. 

On the other hand, the database logic may be located inside the NamesDialog class itself. In the show method, I can query the database for names and, when the user interacts with the controls (in this case, list management), the database can be updated from event handlers. As a result, the NamesDialog class has only the Show () method, since there is no need to use SetNames or GetNames (), etc.

Which method is usually preferable? I don't have much work experience, so I'm not sure if this is the right way to handle this. Sometimes it's easier to handle everything in a class, but accessing the objects it interacts with can be tricky. This can usually be done if the corresponding objects are the same as the database manager in the above example.

Answer 1

Try MVC for size.

Answer 2

There are several similar approaches when developing a GUI program:

• presenter first
• MVP
• cowboy coding

Well, the last is a joke.

The first two are the preferred ways to develop a GUI program. Both are good, so no matter what you choose, you are not mistaken. Then you should fully use unit logic to use your logic, which should be in the presenter and model.

Answer 3

In general, you tend to decorate the actual work from the GUI itself. There are two reasons for this:

• By defragmenting an action, you can reuse them. Several controls can reuse the same action (remember "Save: CTRL + S", "File"> "Save", "File"> "Save As"), and can also be launched using the command line / scripts.
• The GUI is designed to respond, you do not want it to get stuck because it was transferring something to / from the database, so you want to perform "actions" in another thread.

A common programming method is messaging / event processing. The graphical interface sends and receives events / messages, and the work is performed by one (or several) background threads.

A typical model is MVC (Model-View-Controller), but there are other suitable alternatives, so don't dwell on it.