您能就MFMailComposeViewController的放置位置给出一些建议吗？
在一个非RxSwift和非Clean架构的项目中，我会在一些视图控制器中实现它，比如：
extension ViewController: MFMailComposeViewControllerDelegate {
func presentMailComposer() {
if !MFMailComposeViewController.canSendMail() {
// TODO: - Handle error here
return
}
DispatchQueue.global(qos: DispatchQoS.QoSClass.userInitiated).async {
let mailComposeViewController = MFMailComposeViewController()
mailComposeViewController.mailComposeDelegate = self
mailComposeViewController.setToRecipients(["mail@example.com"])
mailComposeViewController.setMessageBody("Message body", isHTML: false)
DispatchQueue.main.async(execute: {
self.present(mailComposeViewController, animated: true, completion: nil)
})
}
}
func mailComposeController(_ controller: MFMailComposeViewController, didFinishWith result: MFMailComposeResult, error: Error?) {
if result == MFMailComposeResult.failed {
// TODO: - Handle error here
}
}
}
在Clean体系结构中，您将把Mail Composer放在哪里？
你能从导航器/路由器上展示这个吗？它毕竟是一个"场景"，即使我们不一定有一个导航器/路由器和一个专用于MailComposer的ViewModel。
有两个不同的地方可能会出现错误，我真的不认为Navigator应该处理这些错误。
谢谢！
Clean Architecture背后的基本前提是"业务规则"，即应用程序的逻辑，不依赖于UI，也不由UI执行。相反，你的应用程序的逻辑在控制之中。
这意味着应用程序的某些逻辑部分知道用户何时可以发送电子邮件，但它不知道是如何发生的。
如果您使用RxSwift，您可以将用户交互视为模型转换。所以你的例子会变成：
func sendMail(recipients: [String], tile: String, message: String, isHTML: Bool) -> Observable<Bool>
上面的内容可以作为闭包传递给您的逻辑，也可以嵌入到您的逻辑使用的协议中。
如果您想使用Robert Martin的特定结构，那么情况会有所不同，因为您根本不会在模型对象中使用Rx。(他建议你的互动者不要依赖外部图书馆。)
在这种情况下，交互者将通过响应模型对象向演示者发送消息以显示电子邮件视图控制器，并且控制器将成功/失败结果发送回交互者，或者更有可能发送回不同的交互者。
以下是鲍勃叔叔说他是如何构建事物的：https://camo.githubusercontent.com/c34f4ed0203238af6e43b44544b864dffac6bc08/687474703a2f2f692e696d6775722e636f6d2f576b42414154792e706e67然而，在他公开展示的一款iOS Swift应用程序中，他没有使用这种结构。https://github.com/unclebob/MACS_GOMOKU
在您发表评论后详细说明，签名确实有效，但它需要一些支持结构。。。
首先，有一个很好但不是绝对必要的部分，我们使视图控制器的表示反应：
extension Reactive where Base: UIViewController {
func present(_ viewControllerToPresent: UIViewController, animated: Bool) -> Observable<Void> {
return Observable.create { observer in
self.base.present(viewControllerToPresent, animated: animated, completion: {
observer.onNext()
observer.onCompleted()
})
return Disposables.create()
}
}
}
这不仅是因为视图控制器只能由另一个视图控制器呈现，而且它必须是系统中当前没有呈现任何内容的视图控制器。我们可以通过从根开始并向上遍历表示堆栈来找到视图控制器：
extension UIViewController {
static func top() -> UIViewController? {
var result = UIApplication.shared.delegate.flatMap { $0.window??.rootViewController }
while let child = result?.presentedViewController {
result = child
}
return result
}
}
现在，我们制作了一个专用的Reactive类，而不是让一些视图控制器符合MFMailComposeViewControllerDelegate协议。
class MailComposeViewControllerDelegate: NSObject, UINavigationControllerDelegate, MFMailComposeViewControllerDelegate {
let subject = PublishSubject<MFMailComposeResult>()
func mailComposeController(_ controller: MFMailComposeViewController, didFinishWith result: MFMailComposeResult, error: Error?) {
if let error = error {
subject.onError(error)
}
else {
subject.onNext(result)
}
}
}
一旦所有这些部分都到位，编写sendMail函数就很容易了：
func sendMail(recipients: [String], tile: String, message: String, isHTML: Bool) -> Observable<MFMailComposeResult> {
let delegate = MailComposeViewControllerDelegate()
let controller = MFMailComposeViewController()
controller.delegate = delegate
return UIViewController.top()!.rx.present(controller, animated: true)
.flatMap { delegate.subject }
}
就像我说的，你应该而不是直接调用这个函数。相反，您应该将它注入将调用它的对象中，这样您就可以模拟它进行测试。
同样的模式适用于UIImagePickerController甚至UIAlertController！
你可能会发现我写的这篇文章读起来很有趣。它使用承诺而不是Rx，但原理是一样的：https://medium.com/@danielt1263/封装用户功能-ec5e5c02045f
这取决于您决定管理项目的方式。
最终，mail composer元素是一个UI元素，因此应该在UI处理类中执行呈现，例如VC、您制作的某种扩展等
在我看来，你可以做的是对你的邮件编写器进行子类化，并在它完成时从中创建一个完成块响应，然后相应地处理UI中的错误，这样它就会管理自己(因为它是一个全局控制器，有一个通用的VM是浪费代码的)。
然后，当你呈现邮件编辑器时，你让用户添加一个完成和一个失败块/使用Rx的信号返回结果。