使用 java.nio.file.spi 来实现对远程文件系统的访问是否有意义？
基本上，我编写了一个应用程序，通过某种类似 FTP 的协议将文件从本地文件系统复制/移动到远程文件系统。
将协议特定位封装在文件系统服务提供者接口中是否是一个好方法？
据我了解，这将使我的库可以使用新的 IO API 与其他应用程序一起工作，对吧？
Basically I write an application which copies/moves files from the local file system to a remote file system over some FTP-like protocol.
Would it be a good approach to encapsulate the protocol-specific bits inside of the file system service provider interface?
As far as I understand that would make my library work with other applications using the new IO API, right?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您似乎正在考虑专门为远程文件系统创建一个
RemoteFileSystemProvider类。此类将镜像FileSystemProvider，提供类似的功能来访问您正在使用的远程文件系统。如果您的项目或团队可以重复使用它，那么在创建代码时镜像FileSystemProvider对象是值得的。这使得熟悉 java.nio.file 包的任何人都可以轻松了解如何使用您的包。但请记住，
FileSystemProvider本身不符合任何接口，也不扩展包中的任何类。这是一个切入点，您的班级也将是一个切入点。但是，如果您模仿方法结构，您将生成要读取和写入的Channel对象，这将符合可重用的java.nio规范。这将允许任何知道如何使用通道的代码能够使用远程文件系统提供程序生成的通道。然而，构建此类内容的第一步是专门为该远程文件系统构建一个包。它将处理所有通信并实现基本功能，例如
getUploadChannel、getDownloadChannel、renameRemoteFile、copyRemoteFile、< code>deleteRemoteFile，以及任何其他必要的功能。这将为您提供一个针对该特定文件系统及其功能定义的良好常识接口。该包可以在任何上下文中使用，以实现与该文件系统的连接。如果您确保该对象使用通道来上传和下载文件，那么它将准备好与任何使用 java.nio 的 API 集成。只有在完成、测试和工作之后，我才会考虑我想要模仿或实现哪个界面以交付给团队的其他成员。这将确保对远程文件系统协议或 java API 的任何更改对整个系统的影响最小。
It seems that you are thinking of creating a
RemoteFileSystemProviderclass specifically for your remote file system. This class would mirrorFileSystemProvider, providing similar functionality to access the remote file system you are using. If this is something that your project or team can get repeated use from, then it is worthwhile to mirror theFileSystemProviderobject when creating your code. This allows anyone familiar with thejava.nio.filepackage can easily understand how to use yours.Keep in mind, however, that
FileSystemProvideritself does not conform to any interfaces or extend any classes within the package. It is an entry point, and your class would also be an entry point. However, if you mimicked the method structure, you would be generatingChannelobjects to read and write, which would conform to thejava.niospecifications that could be reused. This would allow any code which knows how to work with channels to be able to work with channels generated by your remote file system provider.My first step in building something like this, however, would be to just build a package specifically for this remote file system. It would handle all of the communication and implement the basic functions like
getUploadChannel,getDownloadChannel,renameRemoteFile,copyRemoteFile,deleteRemoteFile, and whatever other functionality is necessary. This will give you a good common-sense interface defined for this specific file system and its functionality. This package could be used in any context to just implement a connection to this file system. If you make sure that this object uses channels to upload and download files, then it will be ready to integrate with any API which usesjava.nio.Only after this was completed, tested, and working, would I consider which interface I'd like to mimic or implement for delivery to the rest of the team. This will ensure that any changes to the remote file system protocol or to the java API will have minimal impact on the overall system.
我会认真使用类似 FTP 的协议。在高级 API 上实现低级 API 的麻烦在于，您掩盖了所有真实成本，并使事情看起来很简单，但实际上非常困难或昂贵。以seek()为例。
I would get down and dirty and use the FTP-like protocol. The trouble with implementing low-level APIs over high-level APIs is that you disguise all the true costs,and make things look easy that are in fact extremely hard, or expensive. Consider seek() for example.