Summary of "ghost architecture": Applicable scenarios and method overloads

The previous blog post on the "Phantom Architecture" has made use of the introduction and the relevant technical points, this article is a summary of the nature of the article, analysis of the framework of the application scenarios and limitations, first of all, let us review the iOS development of the MVC model, referring to the Stanford public class Paul Don's explanation, as shown in:

Model and view in the MVC mode can not communicate directly, in the "Phantom Architecture" system model and view still cannot communicate directly, in the traditional MVC, this communication is blocked many times because the model and view entities can not be completed without the data binding , in the past you might have thought of writing a method in view to accept a model, and then write a concrete implementation that can only be done with the overloads of the method without the help of generics, and in cases where there is no protocol extension, you need to choose between the parent class and the code that writes the duplicates.
In the "Phantom Architecture" system, through the Modeltype and ViewType can be without the help of the controller to achieve the logical binding, is still using the method of the use of value, Controller played "switch", relying on generics and protocol to the data type constraints, and avoids duplication of code, does not need to care about the data source isomorphism and heterogeneous.
We need to create an instance of model and view in the controller, and as with MVC we can do the model and view, but the logical relationship between model and view is defined in the GetData of the view. For example, the event in the demo cell will be labeled red, if you want to modify the controller's flag bit to affect the model and the logic between the view, such as the demo in the controller to add a switch, The background color of the event and festival is exchanged after the click, which is the logic that the controller has introduced a flag bit to affect the view and model, and if you want to continue to maintain the "phantom architecture" system, you need to overload the Givedata and GetData methods, The flag bit in the incoming controller. First, add the default implementation to GetData, because in the view code we just want to rewrite the overloaded methods we need:

//视图使用的协议protocol ViewType{    func getData<M:ModelType>(model:M)}//数据使用的协议protocol ModelType{}//定义默认方法giveDataextension ModelType{    func giveData<V:ViewType>(view:V){        view.getData(self)    }}extension ViewType{    func getData<M:ModelType>(model:M){    }}

In order to maintain the "phantom architecture" flexibility, we rewrote givedata and GetData, instead of rewriting them in specific compliance, and extending the protocol directly:

extension modeltype where  Span class= "hljs-built_in" >self : hasdate{func givedata<  V:viewtype>  (View:v,tag : Bool) { let  tableCell =  view As?  showedtableviewcell{tablecell GetData (self , tag :        tag ) }}}extension viewtype where  self : showedtableviewcell{func getdata<  m:modeltype>  (Model:m,tag : Bool) {}}  

You do not need to modify all the model now, but you need to override the new defined method in view:

Func getdata<m:modeltype> (Model:m,tag:bool) {//cannot be written as guard let Datemodel = model as? Dateviewmodel else{} made me a little surprised .Guard LetDatemodel = Model as? HasdateElse{return}//handling the same propertiesDatelabel.text = Datemodel.date//Processing data source heterogeneous        if  Let Event= Datemodel as? event{Mixlabel.text =Event. eventtitle backgroundcolor = tag? Uicolor.redcolor (): Uicolor.whitecolor ()}Else if  LetFestival = Datemodel as? festival{Mixlabel.text = Festival.festivalname backgroundcolor =!tag? Uicolor.redcolor (): Uicolor.whitecolor ()}}

This is another magical thing about protocol extensions: it doesn't introduce redundant states, avoids the advent of the "God Class", and if you have other model and view bindings in your project, it won't be affected. As a final step, modify the data bindings in the controller:

 override  func TableView ( Tableview:uitableview, Cellforrowatindexpath Indexpath:nsindexpath), UITableViewCell {let  cell = Tableview.dequeuereusablecellwithidentifier (Cellreusedid, Forindexpath:indexpath) as ! Showedtableviewcell //calls the overloaded method  Datalist[indexpath.row].givedata (cell,tag:true ) return  cell}  

Now try passing the tag true and false to see the effect:

Tag passed in false

The value of the tag depends on the controller, as shown in the above example, it is perfectly fine to switch between the view and model binding logic in the controller. Before the Givedata method is to avoid the appearance of box type in heterogeneous data sources, improve the efficiency of operation, for the homogeneous data source, we only need to overload the GetData and directly in the controller using GetData to bind the data.
So, I said in the original article "Phantom Architecture" as MV, actually does not weaken the controller's responsibilities, but the controller has about the model and view logic binding code moved to the view, and concentrated in a GetData method, easy to maintain, for the controller decompression, so in fact, this is a " Pseudo schema ". As you can see from the example above, MVC and MVVM can do the same as "ghost architecture", and they are much better maintained than the controller code in MVC, and write a lot less code than MVVM. The future development of "phantom architecture" needs to undergo a time-tested.

Summary of "ghost architecture": Applicable scenarios and method overloads