Ввод логики в модель CoreData

Question

Я новичок в разработке iOS и работаю над приложением языковой флэш-карты, где пользователю предоставляется флеш-карта, и пользователь может сказать, помнят ее или нет. Если они нажмут «да», значит, карта в будущем будет возвращаться в зависимости от разных переменных, если они нажмут «нет», значит, карта скоро вернется. (Разнесенная система повторения)

Мой вопрос: Где было бы хорошее место для установки этой логики планирования, когда я использую CoreData в качестве хранилища для приложения?

два места, где я думал, являются:

В подклассе NSManagedObject для флэша.

Например, я мог бы сделать что-то вроде:

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

, а затем в контроллере, который имеет доступ к обоим CoreData (Model) Вид и я мог бы просто написать:

// 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 быть только данными с проверкой геттеров и сеттеров? Есть ли способ, который предпочтительнее в разработке iOS?

Я думаю, когда дело доходит до него, я хочу знать, должен ли подкласс NSManagedObject управлять своей собственной логикой.

В качестве дополнительного, но связанного с этим вопроса, этот тип решения, определяющий, каким образом организовать код, кажется, является слабым моментом для меня. Есть ли хорошие ресурсы, которые я могу прочитать, чтобы узнать больше об этих решениях и, что более важно, когда и почему было бы хорошо/плохо использовать их.

Answer 1

Я бы поставил логику в модели по причинам, которые вы упомянули.

Однако, вместо того, чтобы помещать его непосредственно в подкласс NSManagedObject, я бы сделал для него категорию, например. FlashCard+Schedule.swift. Таким образом, помимо преимуществ, которые вы указали, если вы хотите восстановить модель, вся логика будет по-прежнему находиться в отдельном файле.

Редактировать: Вот хороший article, охватывающий эту тему (архитектуры) на более высоком уровне.

Answer 2

Ни модель, ни контроллер. Это называется бизнес-логикой. Бизнес-логика должна быть в отдельном классе, который делает только это (Single Responsibility). Я предпочел бы иметь класс обслуживания, который выполняет бизнес-логику, и оставить модель как простое хранилище и контроллер для форматирования модели для UI/view.

Answer 3

Как предложение, потому что я недавно написал такое приложение в Свифте.

Мое решение должно было содержать счет памяти, хранящийся с каждой карточкой, обновляя его, когда он был помечен как «правильный» или «неправильный» (и я также не допускал «никакой реакции»).

Логика того, какая карта для выбора следующей была в одноэлементном Dealer, который мог бы положиться на эти оценки, чтобы сделать хороший выбор с помощью случайного элемента или без него. Фактически, алгоритм был настолько прост, что он очень хорошо сочетался с «торговым» контроллером представлений.