最新的Swing MVC示例+问题

Jam*_* P. 8 model-view-controller swing pojo

我正在寻找一篇文章或教程,给出一个示例,了解使用Swing框架时最新的MVC模式(2.0?)应该是什么样子.

此外,更习惯于分层架构,我想知道域对象或POJO如何适应图片.我是否正确地假设它们是独立的并且被模型调用?至于模式本身,在将类分组到包中有广泛使用的约定吗?

TIA,

詹姆斯P.

chu*_*ubs 26

这是个大问题.我将与你分享一些关于这个问题的想法,看看它是什么.

Swing比Model-> View-> Controller更像Model-> View.Model-> View的问题在于,Swing应用程序通常是View对象的子类,并且该对象同时成为该视图的视图和控制器.在大型应用程序中加班会导致许多问题和意大利面条代码.

我几年来一直在做的是创建一个名为Controller的独立对象,它不扩展任何UI类.在这方面,这是一个普通的老对象.该Controller将负责实例化View的顶级组件,将侦听器连接到视图以响应用户,以及转向并调用模型以完成工作.

View将是Swing的子类.View负责响应鼠标事件,键盘事件等.任何类型的Swing特定事件都在View中处理.它还将提供高级方法来更新控制器将用于回调以更新UI的视图.经典的秋千模型也是View的一部分,因为您选择的组件与您将使用的模型非常相关.View还负责向控制器发送高级别事件,Controller负责响应这些高级别事件.这些事件可能是UserEvent.ADD,UserEvent.EDIT,AuthenticationEvent.LOG_IN,AuthenticationEvent.LOG_OUT等.这些事件是应用程序事件,更像是产品经理可能识别的事件.Controller不响应Mouse,ChangListener等.我实际上为这些构建了自己的EventDispatch和Event框架,因为Swing很难扩展和有效使用.视图的工作方式如下:

public void mouseClicked( MouseEvent evt ) {
   User u = getUserAt( evt.getPoint() );
   dispatch( new UserEvent( UserEvent.EDIT, u ) );
}
Run Code Online (Sandbox Code Playgroud)

在我的控制器中,我有简单的方法连接到这些事件.这可能是一个例子:

@EventCallback( command = "exit" )
public void exit( AppEvent evt ) {
    onExit();
}

@EventCallback(command = "help.about")
public void showAbout(AppEvent evt ) {
    audioFinderFrame.showAboutDialog(engine.getLicenseInfo());
}

@EventCallback( command = MediaSourceEvent.START_REFRESH )
public void refreshStarted(final MediaSourceEvent event) {
   if( frame != null ) frame.refreshMediaSource( event.getSource(), true );
}
Run Code Online (Sandbox Code Playgroud)

注释是我必须将事件监听器方法快速添加到EventDisptach源的扩展.但是,重点是控制器上的每个方法都是使用高级事件从视图中调用的.这使得Controller可以与视图的显示方式有些隔离.Controller的登录方法不必担心构成视图的组件.他只是收到一个活动并完成工作.控制器负责应用程序的流程.

由于事件系统与Swing分离,我在模型层中重用它,因此模型可以将事件分派回Controller,Controller可以将这些更改中继到UI.

模型和Controller是POJO.他们了解事件,但就是这样.该模型是应用程序的逻辑,包括DAO级别,可能执行后台作业的服务,与服务器通信的任何服务层,以及大多数人可能认为是DTO的对象.我没有规定DTO应该只是简单的getter/setter结构.我确实允许一些逻辑,因为它们是在所有层之间浮动的一件事.因为每个层都可以访问它们,所以它们提供了一个集中逻辑的好地方,每个层都可以重用.View,Controller和Model可以访问这些方法,因此不要将它们放在它们之间移动的对象中.

通常,此逻辑更接近业务逻辑或模型维护逻辑.我很小心将大型架构系统与这些方法相结合.这些方法不会与数据库通信,也不会调用服务器端方法,因此它们不会将引用带回更大的体系结构部分.它们具有DTO的所有优点:轻便,易于构造,低依赖性,但仍然保持面向对象设计的原则:封装,重用和信息隐藏.

我也开始使用Spring来连接模型的各个部分,以及控制器在模型上的依赖关系和依赖关系.我发现这个模型运行得很好,比不使用它更令人愉快.如果我正在使用这些技术,那么访问Spring JDBC模板和JMS模板等技术也很不错.但是,它是可选的.

我从不重用控制器.控制器是系统中最具体的东西,而且通用性只会使它们难以维护.通用性确实属于视图和模型,因为它使开发更容易.因此,设计模式倾向于发现自己在这些方面,但很少在控制器中.控制器是来回简单的方法调用.

我发现这样做使得构建Swing UI变得更容易,更直接.我不太可能从一次听取和操纵两个控件进入无限的事件循环.我还发现测试和分解系统更容易,因为我的大部分逻辑都存在于Swing的掌握之外.这使得功能测试成为可能,而无需使用巨大的工具包来模拟鼠标点击等.

这里没有很多代码来说明抱歉,但希望这会有所帮助.