作为 Java Swing 新手，我在将用户界面逻辑与域逻辑分离时遇到了一些麻烦。
我有一个带有 JFrame 的小型(普通？)Swing 应用程序，其中包含一个 JLabel、JTextField 和一个 JButton。当按下 JButton 时，会弹出一个 JFileChooser 对话框。选择文件后，JTextField 包含文件的绝对路径。到目前为止没有什么特别的。 接下来我要完成的是将文件的这个绝对路径“注入(inject)”到文件管理器类中，该类将在进行选择并更新 JTextField 时处理文件的实际处理(每次选择文件时使用 JButton)。
我的问题:
- 如何让文件管理器知道何时开始读取文件？ (例如计算该文件中的行数)
- 如何以在 UI 层内共享最少信息的方式实现领域层？我应该向 UI 添加文件管理器实例吗？
- 我应该使用 JTextField 的值作为对文件管理器的引用，还是应该使用 JButton 操作将值设置到文件管理器中？我的意思是:使用 JTextField 的 propertychangelistener 或使用 JButton 的 actionlistener？
- 我应该使用 filebean 来存储域层中文件的绝对路径，还是直接将其插入到文件管理器中？不同之处在于:当我使用属性更改监听器时，绝对文件路径的值可以在 UI 输入更改时更新，但是当我使用构造函数或 setter 直接插入值时，我必须在文件管理器中处理更改而不是处理 filebean 中的更改。
- 如何在域逻辑中的文件管理器中引用 UI 中使用的文件 bean？
- 领域逻辑与业务逻辑相同吗？我的意思是:文件管理器类应该在 whatever.b-logic 包中，filebean 类应该在 whatever.domain 包中？？
应用分为几个包:
- 随便:主类
- whatever.presentation : swing stuff
- whatever.domain:数据内容
- whatever.logic:应用程序逻辑
我希望我足够清楚...
预先感谢您清理问题。
最佳答案
就个人而言，当我处理这类问题时，我会尝试将可重用性和责任(谁负责什么)视为主要要求。
也就是说，我尝试以这样的方式设置我的模型，以便它们不关心数据来自或去往的方式或位置，它们只是提供接口(interface)访问来实现它。
为了将所有元素连接在一起，我依靠模型向客户端提供事件，因为模型不应该关心谁想知道，只提供所需的功能。因此，为了向客户提供反馈，我需要依靠一系列的听众。
我会将监听器分解为特定的作业，这样的文件读取通知将是它自己的监听器，对模型的更改(添加/删除/更新)文件 bean 将是另一个。其他通知将需要不同的监听器，这会阻止您创建实现不想真正了解的怪物监听器。
为了在模型中设置值，我会在属性 setter / getter 方面犯错。这将您的模型与实现分离(如果您以自动化方式使用该模型怎么办？？)
如果可能，内部数据最好由模型管理。也就是说，如果您更改模型正在管理的文件 bean 的属性，模型应该能够监视更改并处理它。话虽如此，您在未来的某个时候可能需要一个哑模型，您可以在其中批量更新一系列文件 bean，然后让模型自行更新。
就我个人而言，我可能会为模型提供外部更新的方法，同时提供至少一种能够提供 self 监控的实现，这使您可以灵活地为正确的情况选择正确的模型。
这里也存在内存泄漏的危险。如果您在不再需要时没有从文件 bean 中正确删除任何监听器，最终可能会阻止该 bean 在以后被垃圾回收。
尽可能使用接口(interface)。这在尝试将这些模型组合在一起时提供了很大的灵 active 。
对于您所描述的，我允许文件 bean 由文件管理器负责，这样文件管理器就成为文件 bean 的容器。
取决于您的项目有多大以及您将来可能希望重用代码的方式将极大地影响代码的布局。
我通常将 UI 代码放在 UI 包和子包中，但这只是我的做法。我倾向于将接口(interface)内容与实现内容分开(通常在物理上位于单独的 Jar 文件中，但同样，这就是我)。这意味着我只需要包括接口(interface)库和我可能使用的任何实现，如果需要(或直接根据需要)使用某种工厂来实际实例化实现。以 JDBC 驱动程序为例。
您想关注责任范围。根据您的描述，我觉得文件 bean 属于文件管理器的职责范围，因此我会将两者绑定(bind)在一起。
这只是我的观点
关于java - 在 Java Swing 中将用户界面与域分开，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11513785/