Question

我是iOS开发的新手，我正在开发一种语言闪存卡应用程序，其中向用户呈现闪卡，然后用户可以说是否记得它。如果他们点击是，那么该卡计划在将来某个时间返回，具体取决于各种变量，如果他们点击否，那么该卡计划很快回来。（Spaced Repetition System）

我的问题是，当我使用CoreData 作为应用程序的存储时，将这个调度逻辑放在哪里？

我想到的两个地方是：

在闪存卡的NSManagedObject的子类中。

例如，我可以做类似的事情：

Flashcard : NSManagedObject {
    ...
    @NSManaged var nextReview: NSDate?
    func reschedule() {
    // logic to assign a new date to nextReview
    }
    ...
}

然后在控制器中，它可以访问CoreData（Model）和View我可以简单地写：

// When the user has tapped a response:
flashcard.reschedule()

我可以看到这种方法的一个优点是，如果我必须在不同的控制器中分配新的日期，我就不必重写调度逻辑。

或：

计算控制器中的新日期，然后更新模型。

FlashcardViewController {
    ...
    // When the user has tapped on a response:
    let newReviewDate = scheduler.calculateNextReviewDate(...)
    flashcard.nextReview = newReviewDate
}

重新安排逻辑应该是控制器应该负责的事情，还是模型应该做的事情。或者CoreData NSManagedObject是否只是具有验证getter和setter的数据？有没有一种在iOS开发中首选的方式？

我想当它归结为它时，我想知道NSManagedObject子类是否应该管理它自己的逻辑。

作为一个额外但相关的问题，这类事情，决定组织代码的方式似乎对我来说是一个弱点。有什么好的资源我可以阅读以了解更多关于这些决定的信息，更重要的是，何时以及为什么使用它们会有好/坏。

Answer 1

出于你提到的原因，我会把逻辑放在模型中。

但是，我不是直接将它放在NSManagedObject的子类中，而是为它创建一个类别，例如FlashCard+Schedule.swift。这样，除了您声明的优点之外，如果您想要重新生成模型，所有逻辑仍将存在于单独的文件中。

编辑：这是一个很好的article涵盖了更高层次的这个主题（架构模式）。

Answer 2

既不是模型也不是控制器。这称为业务逻辑。业务逻辑应该在一个单独的类中，只执行（单一职责）。我宁愿选择具有业务逻辑的服务类，并将模型保留为简单存储，将模型格式化为UI /视图的控制器。

Answer 3

这是一个建议，因为我最近在Swift中编写过这样的应用程序。

我的解决方案是每张卡都存有记忆得分，只要标记为“正确”或“不正确”就更新（并且我也允许“无反应”）。

接下来选择哪张牌的逻辑是Dealer单身，可以依靠这些得分来做出有或没有随机元素的好选择。实际上，算法非常简单，因此很好地成为了“处理”视图控制器的一部分。

将逻辑放在CoreData模型中

3 个答案: