程序逻辑应该驻留在 gui 对象类内部还是该类外部?

发布于 2024-10-18 06:23:52 字数 923 浏览 0 评论 0原文

我有一个关于如何构建与 GUI 对象相关的代码的问题。假设我有一个对话框,其中有一个列表控件,其中包含从数据库获取的一堆名称。用户可以编辑名称。逻辑是驻留在该对话框类内部还是应该来自外部。为了说明我的意思,这里有一些伪代码,显示了在对话框类之外处理逻辑时的代码结构:

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

因此该类的用户会执行以下操作:

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

另一方面,数据库逻辑可以驻留在在 NamesDialog 类本身内部。在 show 方法中,我可以查询数据库中的名称,并且当用户与控件(本例中为列表控件)交互时,可以从事件处理程序更新数据库。因此,NamesDialog 类只有 Show() 方法,不需要使用 SetNames 或 GetNames() 等。

通常首选哪种方法?我没有太多的工作经验,所以我不确定哪种处理方式才是正确的。有时,处理类中的所有内容会更容易,但访问与之交互的对象可能会很困难。通常可以通过将相关对象设置为单例来实现,就像上面示例中的数据库管理器一样。

I have a question about how to structure code in relation to GUI objects. Suppose I have a dialog that has a list control that has a bunch of names obtained from a database. The user can edit the names. Does the logic reside inside that dialog class or should it be from the outside. To illustrate what I mean, here’s some pseudo code showing the structure of the code when the logic is handled outside the dialog class:

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

So the user of the class would 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 can reside inside the NamesDialog class itself. In the show method I can query the database for the names and as the user interacts with the controls (list control in this case), the database can be updated from the event handlers. As a result the NamesDialog class only has the Show() method as there is no need to use SetNames or GetNames() etc.

Which method is generally preferred? I don’t have much work experience so I’m not sure which is the proper way to handle it. Sometimes it's easier to handle everything in the class but getting access to objects it interacts with can be challenging. Generally can do it by having the relevant objects be singletons like the database manager in the above example.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

你的呼吸 2024-10-25 06:23:52

尝试使用 MVC 来确定大小。

Try MVC on for size.

你的笑 2024-10-25 06:23:52

在设计 GUI 程序时,有一些类似的方法:

好吧,最后一个是个笑话。

前两种是设计 GUI 程序的首选方法。两者都很好,所以无论您选择哪个,都不会出错。
然后你应该对你的逻辑进行全面的单元测试,它应该在演示者和模型中。

There are few similar approaches when designing a gui program :

Ok, the last one is a joke.

The first two are preferred ways of designing a gui program. Both are good, so whichever you pick you won't make a mistake.
Then you should fully unit test your logic, which should be in presenter and model.

请持续率性 2024-10-25 06:23:52

一般来说,您倾向于将实际工作与 GUI 本身去相关。这样做的原因有两个:

  • 通过解除操作的相关性,您可以重用它们。多个控件可以重复使用相同的操作(想想保存:CTRL+S、文件>保存、文件>另存为),并且它也可以由命令行/脚本触发。
  • GUI 旨在响应,您不希望它卡住,因为它正在向数据库传输某些内容或从数据库传输某些内容,因此您希望在另一个线程中执行“操作”。

一般的编程方式是通过消息传递/事件处理。 GUI 发送和接收事件/消息,该工作实际上由一个(或多个)后台线程执行。

典型的模型是 MVC(模型-视图-控制器),但还有其他合适的替代方案,因此不要陷入困境。

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

  • By decorrelating the action, you can reuse them. Multiple controls may reuse the same action (think of Save: CTRL+S, File>Save, File>Save As) and it can also be triggered by command-line/scripts.
  • The GUI is meant to be responsive, you don't want it stuck because it's transferring something to/from the database, thus you want to execute the "actions" in another thread.

The general way of programming is through message passing/event handling. The GUI sends and receive events/messages, and the work is actually performed by one (or several) background threads.

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

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文