Архитектура iOS: объект с множеством опций - PullRequest
Новая
       15

Архитектура iOS: объект с множеством опций

0 голосов
/ 05 ноября 2018

Это довольно специфическая ситуация, поэтому я постараюсь объяснить как можно больше деталей.

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

REST API были сделаны в C #, и нет документации о том, что может и не может быть нулевым (ноль, в случае Swift). Итак, я заканчиваю с: 

    struct Reservation: Codable {
var objectID: String?
var objectName: String?
var objectPrefix: String?
var reservationNumber: String?
var grownUPS: Int?
var teens: Int?
var children: Int?
var babies: Int?
var reservationDate: String?
var dateInserted: String?
var toDate:String?
var fromDate: String?
var price: Int?
var owner: String?
var note: String?
var agencyName: String?
var renterNote: String?
var reservationID: String?
    // 20 more properties

init(objectID: String? = nil,
         partnerID: String? = nil,
         objectName: String? = nil,
    // 20 more properties        
    )
    {

    self.objectID = objectID
    self.objectName = objectName
 // 20 more properties

}

Поэтому, когда я нажимаю на объект, я передаю объект Reservation, проверяю каждое поле, если не ноль, затем устанавливаю TextField. При нажатии кнопки «Сохранить» я обновляю модель из всех полей TextFields, DatePickers и т. Д., А затем выполняю сетевую публикацию или отправляю запрос в зависимости от того, существует ли новое резервирование или редактирование.

Если я нажимаю на добавить, я пропускаю пустой объект Reservation, поэтому все поля на странице «детали» пусты, и выполняю проверку при нажатии кнопки Save.

Пока это работает, но все вокруг выглядит "Anti-Swift". Множество опций, много защитников / распаковок, тесная связь между «основным» и «подробным» представлениями, настройка данных, извлекаемых из сети в закрытом состоянии (фактический вызов Alamofire скрыт, но я не уверен, что будет ноль, поэтому я необходимо установить для каждого свойства его TextField с нулевой проверкой / цепочкой).

Какие-нибудь советы по архитектуре, как это улучшить? Все учебные пособия посвящены простому, локальному, необязательному подходу, благодаря которому все выглядит блестяще.

Имейте в виду, что у меня нет документации о том, что может быть нулевым (данные, ранее введенные через Интернет или из внутреннего настольного приложения).

Ответы [ 3 ]

0 голосов
/ 05 ноября 2018

SwiftyJson решает именно то, с чем вы сталкиваетесь. Он отлично справляется с обработкой дополнительных цепочек и разворачивает большое количество объектов очень эффективно и очень быстро.

Если преобразование какого-либо типа завершается неудачно, оно не прерывается, но выдает пустое значение, так что ваше приложение работает без проверки каждой переменной.

Вот базовый пример конвертации. Для получения подробной информации, пожалуйста, просмотрите их документацию. 

// Getting a double from a JSON Array
let name = json[0].double

// Getting an array of string from a JSON Array
let arrayNames =  json["users"].arrayValue.map({$0["name"].stringValue})

// Getting a string from a JSON Dictionary
let name = json["name"].stringValue

// Getting a string using a path to the element
let path: [JSONSubscriptType] = [1,"list",2,"name"]
let name = json[path].string

// Just the same
let name = json[1]["list"][2]["name"].string

// Alternatively
let name = json[1,"list",2,"name"].string
0 голосов
/ 05 ноября 2018

Я не думаю, что вас должны беспокоить опционные и опциональные распаковки.

Одна из возможностей опциональных заключается в том, , что любой, кто работает с вашим кодом, знает, что эта вещь может принять nil в качестве значения .

Логика развертывания, либо вы используете guards, nil объединение, либо любую другую методику развертывания, описывает вашу бизнес-логику. Тот факт, что у вас есть «большая» модель, IMO, просто факт, который следует принять. Это нормально, пока ваш код не станет надежным, читаемым, тестируемым и понятным, не вызовет ненужных побочных эффектов и т. Д.

Вы можете «исправить» эту проблему, добавив еще один уровень абстракции вместо развертывания или около того. Но, ИМО, это следует делать очень осторожно и только в случае реальных выгод .

0 голосов
/ 05 ноября 2018

Одна вещь, о которой я могу подумать, - это удалить опциональность некоторых свойств, определив значения по умолчанию, например, var babies: Int = 0 или, если вы используете декодируемый Swift, вы можете сделать что-то вроде этого 

babies = (try? container.decode(Int.self, forKey: .babies)) ?? 0

, поэтому вам не нужно делать вашу переменную babies необязательной

редактировать на основе комментария: the ?? aka coalescing nil operator попытается развернуть необязательное значение слева и, если оно равно nil, вернет значение справа, которое в данном случае равно 0

...