使用模型来表示视图的整体状态
是否有一个标准实践来表示未链接到单个组件的用户界面的状态？
例如，Swing 界面可能具有一系列选项卡，并具有以下约束：每个给定实体类型（这可以表示为 HashSet）单个选项卡只能显示一次。或者一条消息可以给出最后执行的操作的结果。或者，可以将 JPanel 链接到单个实体实例以进行编辑。
Is there a standard practise for representing the state of a user interface that is not linked to a single Component?
For example, a Swing interface could have a series of tabs with a constraint that a single tab should only be displayed once per a given entity type (this could be represented as a HashSet). Or a message could give the result of the last operation carried out. Or a JPanel could be linked to a single entity instance for editing purposes.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为您所描述的是模型-视图-视图模型模式。这在网络领域非常流行。 mvvm 的顶级 Google 链接也是一篇MSDN 文章，给出了相当不错的内容概述。
I think what you are describing is the Model-View-ViewModel pattern. This is all the rage in dot-net land. The top google link for mvvm is also an MSDN article giving a fairly decent overview.
是的，为视图本身创建一个模型是完全可以接受的，它与应用程序模型完全分开。 Swing 已经在内部执行此操作，跟踪元素的布局方式、表中的行和列以及文本字段中的光标位置。
我建议您的视图模型逻辑尽可能与实际组件代码松散耦合，以便更容易维护，例如为每个不扩展实际 Swing 对象的职责或行为创建一个单独的类。
例如，如果我们想确保只有某种类型的
JFrame的一个实例，例如选项对话框甚至主应用程序窗口，则可以使用单例样式来完成该类保存对框架的引用，并在有人调用您的方法时返回它，如果它不存在则创建它，如果它被隐藏则使其可见。这很常见。Yes, it's perfectly acceptable to create a model for the view itself, which is completely separate from the application model. Swing already does this internally, keeping track of how elements are laid out, rows and columns in tables and the cursor position in text fields.
I would recommend keeping your view-model logic as loosely coupled from the actual component code as possible to make it easier to maintain e.g. make a separate class for each responsibility or behaviour that doesn't extend an actual Swing object.
For example, if we wanted to make sure we only ever have one instance of a certain type of
JFrame, such as an Options dialog or even the main application window, this could be done with a singleton-style class which holds a reference to the frame and returns it when someone calls your method, creating it if it doesn't exist, and making it visible if it is hidden. This is very common.