最新的 Swing MVC 示例 + 问题 [英] Up-to-date Swing MVC example + Question

问题描述

我正在寻找一篇文章或教程，以举例说明使用 Swing 框架的最新 MVC 模式(2.0?)应该是什么样子.

I'm looking for an article or tutorial that gives an example of what an up-to-date MVC pattern (2.0?) should look like with the Swing framework.

此外，由于更习惯于分层架构，我想知道域对象或 POJO 是如何融入图片的.我假设它们是分开的并由模型调用是否正确?至于模式本身，在将类分组到包方面是否有广泛使用的约定?

Also, being more used to a layered architecture, I'd like to know how the domain objects or POJOs fit into the picture. Am I right in assuming that they are separate and called by the model? As for the pattern itself, are there widely used conventions in terms of grouping classes into packages?

TIA，

詹姆斯 P.

推荐答案

这是个大问题.我将与您分享我对这个主题的一些想法，看看会产生什么结果.

That's a big question. I'll share some thoughts with you I have on this subject and see what comes out of it.

Swing 比模型->视图->控制器更像是模型->视图.Model->View 的问题在于，通常 Swing 应用程序将 View 对象子类化，并且该对象成为该视图的 View 和 Controller 合并为一个.在大型应用程序中超时会导致很多问题和意大利面条式代码.

Swing is more Model->View than Model->View->Controller. The problem with Model->View is that typically Swing applications subclass a View object, and that objects becomes both the View and the Controller for that view mushed into one. Overtime in large applications this leads to lots of problems and spaghetti code.

我多年来一直在做的是创建一个单独的对象，称为控制器，它不扩展任何 UI 类.在这方面，它是一个普通的老物件.此控制器将负责实例化 View 的顶级组件，将侦听器连接到视图以响应用户，并转身并调用模型以完成工作.

What I've been doing now for several years is to create a separate object called a Controller that doesn't extend any UI classes. It's a plain old object in this respect. This Controller will be in charge of instantiating the top level components for the View, connecting listeners to the view to respond the user, and turning around and making calls onto the model to accomplish work.

视图将继承 Swing.View 负责响应鼠标事件、键盘事件等.任何类型的 Swing 特定事件都在 View 中处理.它还将提供用于更新视图的高级方法，控制器将使用这些方法回调更新 UI.经典秋千模型也是视图的一部分，因为您选择的组件与您将使用的模型密切相关.View 还负责将高层事件分派给 Controller，Controller 负责响应这些高层事件.这些事件可能是 UserEvent.ADD、UserEvent.EDIT、AuthenticationEvent.LOG_IN、AuthenticationEvent.LOG_OUT 等.这些事件是应用程序事件，读起来更像是产品经理可能会识别的内容.Controller 不响应 Mouse、ChangListener 等.我实际上已经为这些构建了自己的 EventDispatch 和 Event 框架，因为 Swing 很难有效地扩展和使用.该视图的工作原理类似于:

The View will subclass Swing. The View is responsible for responding to mouse events, keyboard events, etc. Any sort of Swing specific event is handled in the View. It will also provide high level methods for updating the view that the controller will use to callback to update the UI. Classic swing models are also apart of the View because your choice of components are very much tied to the models you'll use. The View is also in charge of dispatching high level events to the Controller, and the Controller is in charge of responding to those high level events. These events might be UserEvent.ADD, UserEvent.EDIT, AuthenticationEvent.LOG_IN, AuthenticationEvent.LOG_OUT, etc. These events are application events and read more like what a product manager might recognize. The Controller doesn't respond to Mouse, ChangListener, etc. I've actually built my own EventDispatch and Event framework for these because Swing's is so difficult to extend and use effectively. The view works something like:

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

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

In my controller I have simple methods that are wired to those events. Here might be an example of one:

@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 );
}

注释是一个扩展，我必须将事件侦听器方法快速添加到 EventDisptach 源中.但是，关键是控制器上的每个方法都是使用高级事件从视图中调用的.这使得控制器与视图的显示方式有些隔离.Controller 的 login 方法不必担心由哪些组件组成视图.他只是接收一个事件并执行工作.Controller负责应用的流程.

The annotations are an extension I have to add event listener methods quickly to an EventDisptach source. But, the point being is each method on the controller is invoked from the view using high level events. This enables the Controller to be somewhat isolated from how the view is displayed. The Controller's login method doesn't have to worry what components make up the view. He just receives an event and performs the work. The Controller is in charge of the flow of the application.

由于事件系统与 Swing 分离，所以我在模型层重用它，以便模型可以将事件分派回控制器，控制器可以将这些更改传递给 UI.

Since the event system is divorced from the Swing I reuse it in the model layers so the model can dispatch events back to the Controller, and the Controller can relay those changes to the UI.

模型和控制器是 POJO.他们了解事件，但仅此而已.该模型是应用程序的逻辑，包括 DAO 级别、可能执行后台作业的服务、与服务器通信的任何服务层以及大多数人可能会说是 DTO 的对象.我不认为 DTO 应该只是简单的 getter/setter 结构.我确实允许一些逻辑在那里，因为它们是漂浮在所有层之间的一件事.因为每一层都可以访问它们，所以它们提供了一个很好的地方来集中每一层可以重用的逻辑.视图、控制器和模型可以访问这些方法，为什么不将它们放在在它们之间移动的对象中.

The model, and Controller are POJOs. They understand events, but that's it. The model is the logic of the application including a level of DAOs, services that might do background jobs, any service layer that talks to the server, and objects most people might say are DTOs. I don't prescribe to the notion that a DTO should just be simple getter/setter structs. I do allow some logic in there because they are the one thing that floats between all layers. Because every layer has access to them, they provide a nice place to centralize logic that each layer can reuse. The View, Controller, and Model can access these methods so why not put them in the object that moves between them.

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

Typically this logic is closer to business logic or model maintenance logic. I'm careful about coupling larger architecture systems to these methods. These methods aren't going to talk to the database, or call server side methods so they don't carry references back to larger architecture pieces. They have all the advantages of DTOs: light, easily constructible, low dependencies, but still maintain the principles of Object Oriented Design: encapsulation, reuse, and information hiding.

我还开始使用 Spring 将模型的各个部分与其依赖项以及控制器对模型的依赖项连接起来.我发现这个模型效果很好，而且比不使用它更令人愉快.如果我正在使用这些技术，那么访问 Spring JDBC 模板和 JMS 模板等技术也很好.但是，这是可选的.

I've also started using Spring for wiring the parts of the model with their dependencies and dependencies the controller has on the model. I've found this model works very well and it's much more pleasant than not using it. It's also nice to have access to technologies like Spring JDBC templates, and JMS templates if I'm using those technologies. But, it's optional.

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

I never reuse Controllers. Controllers are the most specific thing in your system, and generalities only make them harder to maintain. Generalities do belong in the View and Model because it makes the development easier. So design patterns tend to find themselves on those sides, but seldom in the Controller. Controllers are simple method calls back and forth.

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

I've found that doing this has made building Swing UIs much easier, and more straight forward. I'm less likely to get into infinite event loops from listening and manipulating two controls at once. I also find it's easier to test and break the system apart because much of my logic exists outside of Swing's grasp. That makes functional testing possible without a huge toolkit trying to simulate mouse clicks, etc.

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

There's not a lot of code here to illustrate sorry, but hope this helps.

这篇关于最新的 Swing MVC 示例 + 问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！