CRUD-Methoden in benutzerdefinierten Swift-Klassen

Question

Ich frage mich, ob es eine gute Idee ist, CRUD-Methoden in benutzerdefinierte Swift-Klassen aufzunehmen, oder geht es ihnen besser in einer separaten Klasse?

Zum Beispiel habe ich eine Klasse namens User.swift:

class User { 
    var firstName: String 
    var lastName: String 
    var id: int 
} 

Nun wäre es in Ordnung, die get zu schließen und Methoden hier zu schaffen? Diese Methoden werden API-Aufrufe über Alamofire machen:

class User { 
    var firstName: String 
    var lastName: String 
    var id: int 

    static func add(user: User) -> User { 
     let parameters = ["firstName": user.FirstName , "lastName": user.LastName] 
     return sendRequest(.POST, url: "example.com/users", parameters: parameters) 
    } 

    static func getById(userId: Int) -> User { 
     return sendRequest(.GET, url: "example.com/users/\(userId)") 
    } 
} 

Sollten diese Methoden werden in einer separaten Klasse, wie in einer ApiHelper Klasse?

Meine Anwendung überträgt das User-Objekt in Arrays und Wörterbüchern an mehreren Stellen, also frage ich mich, ob es gut ist, es nur mit den Eigenschaften sauber zu halten.

Answer 1

Ich denke, besser, solche Methoden in einigen ApiHelper/Router Singletone Klasse, als auch erklären, wie sie async, die Arbeit mit einem gewissen Parse-System (RestKit wahrscheinlich) und zurück geholt Objekte über Schließungen mit einer gewissen Verzögerung

Answer 2

die verschiedenen arbeiten müssen, Meinungen über den richtigen Ansatz führen oft zu einer hitzigen Diskussion. Und dies erstreckt sich auch auf Fragen, ob wir Validierung in der Modellklasse (User) oder in der Steuerung, wie wir mit Versionen, Serialisierung, Fehler, Rückgängig/Wiederherstellen, Sperren, Asynchronität, etc., etc.

Und der resultierende Code sollte immer noch sauber, verständlich, erweiterbar, testbar und in eine Bibliothek gelegt werden, damit wir ihn in anderen Projekten wiederverwenden können!

IMHO, es gibt keinen richtigen Ansatz. IMHO würde ich mit den folgenden Prinzipien beginnen:

Ihre User Klasse wird in Ihrer Lösung als Entity gesehen. Eine Entität hat eine Eigenschaft ID und möglicherweise andere prinzipielle Methoden, z. B. gibt sie eine init frei, die ein Wörterbuch von Attributen verwendet, in denen die Klassen-/Strukturinstanz initialisiert werden kann.

Das Unternehmen kennt auch ein "Persistent Store", so Ihre User Klasse auch auf ein Protokoll "Storable" entsprechen kann, welche Methoden Klassen- und Instanz wie save aussetzt, create, update, delete, query usw.

Dies ist nur die Spitze eines Eisbergs, was eine komplette Lösung darstellt. Sie könnten schauen, wie andere dieses Problem gelöst haben. siehe Ideen,

• Verwenden Core Data Objekte, die Sie aus dem JSON bevölkern

• Umsetzung der Active Record Pattern

• Blick auf einige Object Relational Mapper (es gibt eine Menge von Implementierungen und Bibliotheken) . Auch wenn Sie von JSON zu Objekten mappen müssen, gibt dies einige Hinweise.

• Wenn Sie immer noch nicht zufrieden sind, werfen Sie einen Blick auf ASP.NET

die "Active Record" -Ansatz Nutzung Sie mit so etwas wie dieses kann beginnen:

public final class User { 
    public init(firstName: String, lastName: String) { 
     self.firstName = firstName 
     self.lastName = lastName 
    } 
    public var firstName: String 
    public var lastName: String 
    public internal(set) var id: Int 
} 


protocol ActiveRecord { 
    static func create(object: Self) throws -> Self 
    static func fetch(id: Int) throws -> Self 
    static func update(object: Self) throws -> Self 
    static func delete(id: Int) throws 
} 

extension User: ActiveRecord { 
    static func create(object: User) throws -> User { 
     ... 
    } 
    static func fetch(id: Int) throws -> User { 
     ... 
    } 
    static func update(object: User) throws -> User { 
     ... 
    } 
    static func delete(id: Int) throws { 
     ... 
    } 
}