在java Swing中将用户界面与域分离

Question

作为一个Java新手，我在将用户接口逻辑与域逻辑分离时遇到了一些困难。

我有一个小的(琐碎的？)Swing应用程序有一个JFrame，包含JLabel、JTextField和JButton。按JButton时，会弹出一个JFileChooser对话框。选择文件后，JTextField包含文件的绝对路径。到目前为止还没有什么奇观。我想要完成的下一件事是将文件的绝对路径“注入”到一个文件管理器类中，该类将在选择和更新JTextField时处理文件的实际处理(每次使用JButton选择文件时)。

我有以下问题：

1. 如何让文件管理器知道何时开始读取文件？(例如，计算该文件中的行数)
2. 我如何实现域层，以便在UI层中共享最少的信息？我应该在UI中添加一个filemanager实例吗？
3. 是使用JTextField的值作为对文件管理器的引用，还是使用JButton操作将该值设置为文件管理器？我的意思是:使用JTextField的propertychangelistener还是使用JButton的actionlistener？
4. 应该使用filebean在域层中存储文件的绝对路径，还是直接将其插入文件管理器？区别是:当我使用属性更改侦听器时，当UI输入发生变化时，绝对文件路径的值可以更新，但是当我使用结构器或setter直接插入值时，我必须在文件管理器中处理更改，而不是处理文件be中的更改。
5. 如何在域逻辑中的文件管理器中引用UI中使用的filebean？
6. 域逻辑与业务逻辑相同吗？我的意思是:文件管理类应该在包中。b-逻辑类和filebean类应该在包whatever.domain？

应用程序分为几个包：

• 不管是什么:主修课
• whatever.presentation : swing的东西
• whatever.domain :数据资料
• whatever.logic :应用程序逻辑

希望我说得够清楚..。

提前谢谢你把事情弄清楚了。

Answer 1

就我个人而言，当我处理这些问题时，我试着把可重用性和责任(谁对什么负责)作为主要需求来看待。

也就是说，我试着把我的模型设置在这样的地方，这样他们就不会关心数据是如何或从哪里来的，他们只需提供接口访问就可以了。

要将所有元素连接到一起，我依赖于向客户端提供事件的模型，因为模型不应该关心谁想知道，只需提供所需的功能。因此，为了向客户提供反馈，我需要依赖一系列的侦听器。

我会将侦听器分解成特定的作业，这样的文件读取通知将是它自己的侦听器，对模型的更改(添加/删除/更新)文件bean将是另一个。其他通知将需要不同的侦听器，这将阻止您创建实作并不真正想知道的怪物侦听器。

对于在模型中设置值，我会在属性设置器/getter方面出错。这将您的模型与实现分离开来(如果您以自动化的方式使用该模型怎么办？)

如果可能的话，内部数据最好由模型来管理。也就是说，如果您更改了模型正在管理的文件bean上的一个属性，则该模型应该能够监视并处理该更改。尽管如此，您可能希望在将来的某个时候使用一个哑模型，在那里您可以批量更新一系列文件bean，然后要求模型自己进行更新。

就我个人而言，我可能会提供外部更新模型的方法，同时提供至少一个能够提供自我监控的实现，这使您可以灵活地为正确的情况选择正确的模型。

这里也存在着内存泄漏的危险。如果在不再需要侦听器时不能正确地从文件bean中删除任何侦听器，那么最终可能会阻止bean在以后被垃圾收集。

在可能的情况下，使用接口。当试图将这些模型结合在一起时，这提供了极大的灵活性。

对于您所描述的，我将允许文件bean由文件管理器负责，这样文件管理器就成为文件bean的容器。

取决于您的项目有多大，以及您将来可能希望如何重用代码，这将极大地影响代码的布局。

我通常把UI代码放在UI包和子包中，但那只是我自己。我倾向于将接口内容从实现内容中分离出来(通常是在单独的Jar文件中，但同样，这就是我)。这意味着我只需要包含接口库和我可能使用的实现，使用某种类型的工厂在需要时实际实例化实现(或者根据需要直接实例化)。例如JDBC驱动程序。

你想把目光投向责任范围。根据您的描述，我觉得文件bean属于文件管理器的职责范围，所以我将两者结合在一起。

这只是我的观点

Answer 2

以下是一些建议：

• 使用SwingWorker，如图所示的here，在倾听进度的同时保持图形用户界面的活跃。
• 使用Action (举例说明的here )封装功能。
• 使用File，一种方便的跨平台抽象。使用它来组成新的抽象，而不是拔出非跨平台的部分。

增编:另见http://java.sun.com/products/jfc/tsc/articles/architecture/和answer。