Best architecture for an iOS networked application
Truth be told, there are no exact and formal answer to the problem. The goal of this set of entries is to collect the most interesting approaches from different resources.
The most common and basic setups for simple apps are:
- Create a separate class for every network request to web-service API which all inherits from the base request abstract class and in addition to create some global network manager which encapsulates common networking code and other preferences.
- Have some singleton API dispatcher or manager class as in the first approach, but not to create classes for every request and instead to encapsulate every request as an instance public method of this manager class.
The network layer is one of the most important things when building an application architecture, and all iOS apps are different so there are different approaches too.
First of all we are going to talk about some well-know patterns:
Unit of work
A Unit of Work keeps track of everything you do during a business transaction that can affect the database. When you’re done, it figures out everything that needs to be done to alter the database as a result of your work.
Remote Facade In an object-oriented model, you do best with small objects that have small methods. This gives you lots of opportunity for control and substitution of behavior, and to use good intention revealing naming to make an application easier to understand. One of the consequences of such fine-grained behavior is that there’s usually a great deal of interaction between objects, and that interaction usually requires lots of method invocations.
Data Transfer Object (DTO)
An object that carries data between processes in order to reduce the number of method calls.
Wrap all the special API code into a class whose interface looks like a regular object. Other objects access the resource through this Gateway, which translates the simple method calls into the appropriate specialized API.
An object model of the domain that incorporates both behavior and data.
Data Access Object (DAO)
Separates low level data accessing API or operations from high level business services. Following are the participants in Data Access Object Pattern:
Data Access Object Interface — This interface defines the standard operations to be performed on a model object(s).
Data Access Object concrete class — This class implements above interface. This class is responsible to get data from a data source which can be database / xml or any other storage mechanism.
Model Object or Value Object — This object is simple POJO containing get/set methods to store data retrieved using DAO class.
The above patterns resolves different problems and they are abstractions that can help in the momnet we design our architecture. They are just guides..
So, in resume:
- We should always desing a model layer.
- Consider the persistence (we could use Core Data, Realm, Couchbase Lite).
- We should create a networking layer.
Considerations in the networking layer:
- It’s like a mediator between domain model and controllers. Always?
- We should avoid to write all our network and business logic in our service layer.
- What about complex model serialisation?
- What about cache?
And as you can imagine the complexity can still growing up…
The fact is that there are a libraries that could help, simple patterns and no just for network layer but the whole app. Some libraries are:
ReactiveCocoa/RXSwift, Alamofire, Mocha, Dependency Injection and more..
In this series we are going to use all of them to finally have a general architectural approach, which can be adapted for any application, and of course we are going to use swift…