Чудові запитання. Давайте розберемо кожного окремо.
Яке належне використання URLRequestConvertible в реальному світі API?
URLRequestConvertibleПротокол є легкий спосіб забезпечити даний об'єкт може створити дійсні NSURLRequest. Насправді не існує суворого набору правил чи рекомендацій, які змушують вас використовувати цей протокол якимось особливим чином. Це просто протокол зручності, щоб дозволити іншим об'єктам зберігати стан, необхідний для правильного створення NSURLRequest. Дещо більше інформації, що стосується Alamofire, можна знайти тут .
Чи слід створювати по одному маршрутизатору на кінцеву точку?
Точно ні. Це перемогло б ціль використання Enum. Об'єкти Swift Enum надзвичайно потужні, що дозволяє вам ділитися великою кількістю загального стану та вмикати ті частини, які насправді відрізняються. Можливість створити NSURLRequestщось настільки просте, як наведене нижче, дійсно потужна!
let URLRequest: NSURLRequest = Router.ReadUser("cnoon")
Я не можу зрозуміти, чому enum використовується для побудови маршрутизатора? Чому ми не використовуємо клас із статичними методами?
Використовується перерахування, оскільки це набагато стисліший спосіб вираження декількох пов'язаних об'єктів під загальним інтерфейсом. Всі методи поділяються між усіма випадками. Якщо ви використовували статичні методи, вам потрібно було б мати статичний метод для кожного випадку для кожного методу. Або вам довелося б використовувати перелік стилів Obj-C всередині об'єкта. Ось короткий приклад того, що я маю на увазі.
enum Router: URLRequestConvertible {
static let baseURLString = "http://example.com"
case CreateUser([String: AnyObject])
case ReadUser(String)
case UpdateUser(String, [String: AnyObject])
case DestroyUser(String)
var method: Alamofire.HTTPMethod {
switch self {
case .CreateUser:
return .post
case .ReadUser:
return .get
case .UpdateUser:
return .put
case .DestroyUser:
return .delete
}
}
var path: String {
switch self {
case .CreateUser:
return "/users"
case .ReadUser(let username):
return "/users/\(username)"
case .UpdateUser(let username, _):
return "/users/\(username)"
case .DestroyUser(let username):
return "/users/\(username)"
}
}
}
Щоб отримати метод будь-якої з різних кінцевих точок, ви можете викликати той самий метод без необхідності передавати будь-які параметри, щоб визначити, який тип кінцевої точки ви шукаєте, це вже обробляється вибраним вами випадком.
let createUserMethod = Router.CreateUser.method
let updateUserMethod = Router.UpdateUser.method
Або якщо ви хочете отримати шлях, ті самі дзвінки.
let updateUserPath = Router.UpdateUser.path
let destroyUserPath = Router.DestroyUser.path
Тепер спробуємо той самий підхід, використовуючи статичні методи.
struct Router: URLRequestConvertible {
static let baseURLString = "http://example.com"
static var method: Method {
}
static func methodForEndpoint(endpoint: String) -> Method {
}
static var path: String {
}
static func pathForEndpoint(endpoint: String) -> String {
}
static var pathForCreateUser: String {
return "/create/user/path"
}
static var pathForUpdateUser: String {
return "/update/user/path"
}
}
ПРИМІТКА. Якщо у вас недостатньо властивостей або функцій, які вмикають регістри, перерахування не представляє багатьох переваг перед структурою. Це просто альтернативний підхід з різним синтаксичним цукром.
Перелічення можуть максимізувати повторне використання стану та коду. Пов’язані значення також дозволяють робити деякі дійсно потужні речі, такі як групування об’єктів, які чимось подібні, але мають неймовірно різні вимоги ... наприклад, NSURLRequestстворення.
Який правильний спосіб побудувати параметри для випадків перерахування для поліпшення читабельності? (довелося розім'яти цей разом)
Це приголомшливе питання. Ви вже виклали два можливі варіанти. Дозвольте додати третю частину, яка може дещо краще відповідати вашим потребам.
case CreateUser(username: String, firstName: String, lastName: String, email: String)
case ReadUser(username: String)
case UpdateUser(username: String, firstName: String, lastName: String, email: String)
case DestroyUser(username: String)
У випадках, коли у вас є пов'язані значення, я думаю, що може бути корисно додати явні імена для всіх значень у кортежі. Це справді допомагає побудувати контекст. Недоліком є те, що тоді вам доведеться повторно оголосити ці значення у своїх операторах перемикання так.
static var method: String {
switch self {
case let CreateUser(username: username, firstName: firstName, lastName: lastName, email: email):
return "POST"
default:
return "GET"
}
}
Хоча це дає вам приємний, послідовний контекст, він стає досить багатослівним. Це ваші три варіанти на даний момент у Swift, який з них є правильним, залежить від вашого випадку використання.
Оновлення
З виходом 🔥🔥 Alamofire 4.0 🔥🔥 URLRequestConvertibleтепер він може бути НАБАГАТО розумнішим, а також може кидати. Ми додали повну підтримку Alamofire для обробки недійсних запитів та генерування помилкових помилок за допомогою обробників відповідей. Ця нова система детально задокументована в нашому README .
caseтверджень. Для мене це виглядає величезним методом. Я не впевнений, що це призведе до читабельного коду ...