Development of Multilayered Applications in Swift

Osnovna ideja ovog rada bila je dati pregled različitih softverskih arhitektura za aplikacije pisane u programskom jeziku Swift za operacijski sustav Apple Mac OS X. Pregled smo započeli od najjednostavnije moguće arhitekture koju Apple predlaže za Mac OS X aplikacije, a to je MVC arhitektura. Upotrebom ove arhitekture razvili smo prvu verziju aplikacije koja je implementirala traženu poslovnu logiku, te smo nju koristili kao bazu za kasnije arhitekture koju su trebale poboljšati izvorno rješenje. Iako je MVC vrlo efikasan i jednako toliko rasprostranjen oblikovni obrazac, njegovom primjenom naišli smo na vrlo konkretne nedostatke, poput masivnih kontrolera koji su sadržavali puno koda i puno odgovornosti. U sljedećoj verziji aplikacije to smo nastojali popraviti uslojavanjem, tako što smo aplikaciju razdvojili na podatkovni, poslovni i prezentacijski sloj. Na taj način oduzeli smo dio odgovornosti iz kontrolera i došli do koda koji je lakše održiv. Time smo napravili korak unaprijed u kvaliteti arhitekture. Naposljetku, aplikaciju smo redizajnirali tako da podliježe standardima MVVM oblikovnog obrasca. Ovdje kontroler služi samo kao logika grafičkog prikaza, pa je time on dodatno rasterećen. Umjesto da je u kontroleru, sva poslovna logika premještena je u ViewModel, odnosno podatkovni model koji služi ViewControlleru, no nije rađen specifično za pojedini ViewController već je općenito iskoristiv za različite ViewControllere. Ovime smo dotaknuli završni dizajn aplikacije, znatno unaprijeđen od verzije od koje smo krenuli.The main idea of this thesis was to give the overview of different software architectures for the applications written in Swift programming language, for Mac OS X operating system. We began the overview from the simplest possible architecture that Apple suggests for Mac OS X applications, and this is the MVC architecture. By using this architecture, we have developed the first version of the application that implemented all the required business logic, and we used that architecture as a common ground for all the latter architectures that were supposed to improve the original solution. Although very effective, and about equally spread, the MVC architecture had some very concrete drawbacks like massive controllers with lots of code and lots of responsibility. In the next version of the application, we were improving the solution by introducing data layers. We did that by introducing data access layer, business layer, and presentation layer. By doint that, we made the controllers a bit lighter with less responsibility, and now got to the code that was better and more easily maintainable. This made us a step forward in the quality of the architecture. Lastly, we designed the application so that it conforms to the standards of the MVVM design pattern. In this version, the controller only served a purpose of serving the view with its associated actions, which made it even lighter than in the previous version. Instead of being in the controller as before, all the business logic was now moved into the ViewModel classes which acted as a data model for the controllers, but they were not controller – specific meaning they are easily reusable by all the different controllers. This led us to the final design, much enhanced from the initial architecture