The Binder Architecture
The Binder Architecture is a declarative architecture for iOS development inspired by MVVM and VIPER. It is an attempt to take the best ideas of MVVM and VIPER and implement them without the boilerplate code that the two architectures,especially the latter,suffer from. The central idea of the Binder architecture is implementing application logic as a function,as opposed to an object. In place of the ViewModel or Presenter,The Binder Architecture defines a function called?the binder. Such approach enforces declarative application logic that provides all the benefits of declarative paradigm and results in a significant reduction of the boilerplate code that can be found in MVVM and VIPER. OverviewThe architecture defines three main layers:
Business LogicEvery good app provides some kind of a value to the user. Sometimes it does that by exposing a web service,sometimes by solving problems locally on the device and often by a combination of the two. An app can communicate with web APIs,different business services,databases or other data persistence solutions,system services or device sensors and various other things. All of those will have their entities,managers and other kinds of types and objects. A code that interacts with them and builds on top of them is often referred to as the?business logic. That is the bottom-most layer of our architecture. One could write a book on how to properly implement the business logic layer and even that might not be enough. Thankfully there is a simple rule of thumb that we can use to define boundaries of the layer: imagine that we are making a cross-platform app (i.e. an app that can run on iOS,Android,TV,watch and/or desktop) and ask ourselves: “What is the code that can be shared across all of the platforms?” The answer is the code of the business logic layer. The business logic layer exposes its functionality through a number of Services. Each Service is responsible for its own concern. For example,a webshop app could have? Here is a simple example of an entity and a service.
?
We are showing only the public interface,not the implementation. It probably communicates with some web API and it might use CoreData for the persistance,but we don’t really care about its implementation. We only need to know that it represents our business logic on top of which we are building our app. Now,you have probably noticed the?Signal?type there. We will be using?ReactiveKit?and?Bond?to demonstrate functional reactive aspects of the architecture,but other solutions will work well too. ? https://github.com/DeclarativeHub/TheBinderArchitecture (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |