iOS电商类APP的研发

前言

本文是研发一个在线超市的电商类APP过程中,对架构的整理。

功能:

  • 1、浏览商品、购买商品、切换商店;
  • 2、查看订单、订单投诉、意见反馈;
  • 3、登陆、退出、收货地址管理;
  • 4、支付、取消订单;
  • ...

箭头的指关系 代表着 直接调用,也代表着持有引用的意思。

所有的实例都可以通过监听event,达到交流的效果。

其中Model是单例,Controller 是storyBoard 上实例,view是Controller运行时加载并初始化;

Message是工厂模式,每一个协议都实例化一个对象来解决;

Event通过封装NSNotifycation实现。

网络通讯是通过Message调用AFNetworking。

设计中遇到的问题

1,网络层请求的封装

一开始的做法是定义一个server类来处理请求,头文件中定义请求的类型,所有的网络请求都走server类,server类直接调用AFNetworking. 大致的形式如下:

Server:NSObject
{
    -(void) requestLogin;
    -(void) requestLogout;
  ....
}

这样的好处是直接调用,开发方便,逻辑也比较简单。 坏处是,所有的代码都写在一起,不方便维护,同时不好做统一的逻辑处理(比如说session过期等)。

现在采用的做法: 定义一个BaseMessage,封装AFNetworking的调用,还有统一的逻辑处理。 同时定义OrderMessage,CartMessage,GoodsMessage,ShopMessage等继承BaseMessage,来具体实现特定的逻辑。 这样做的好处,把逻辑分类,代码按照模块分散到每个SubMessage,方便维护。

还可以优化的地方: 现在的请求是一个Message就是一个网络请求(http),处理完之后要在Message抛出事件,来通知其他模块的信息。并且,每个Message都是相互独立的,并没有统一调度的过程。 可以新建一个MessageQueue类,来存放所有的Message请求,通过MessageQueue来调度http请求。 这样的涉及到的问题是:结果回来后,如何通知其他对象? 做法1: 当请求Message的时候,self实现一个接口,并且传入self;回调的时候,直接通过接口调用; 做法2: 请求的时候,带一个闭包参数,回调的时候直接调用闭包; 做法3: 请求之后监听事件;回调时通过事件响应;

比较理想的做法: 有controller 、 message 、msgCenter三个实例。 controller监听事件,发送message; message实现接口,自己把自己添加进msgCenter队列; msgcenter对BaseMessage进行处理,通过接口来查询message 里ID等详细信息;回调后,通过调用message的接口。 controller 和 message 用的是监听者模式; msgCenter 和 message 之间用的是代理模式; msgCenter 可以实现异步的与服务器交互,和对message 的统一处理。

2,MVC框架的实现

iOS的设计,本身就含有很多MVC的思想,比如说要实现一个自定义UITableView,就要继承UITableView,自定义delegate,与Controller的交流 是通过delegate实现。同时,一个页面就是一个controller,也要继承UIViewController。 自然而然地,在写代码的时候就会M(model)、V(View)、C(controller)的区分。 但在实际的需求中,遇到一些正常的需求的时候,如果没有设计好,也会很棘手。 比如说:首页下方的购物车模块、商品展示的模块,这些都是需要重复出现的模块,也就是需要重用的模块。如何设计购物车模块,使得购物车模块 和 持有购物车的模块(首页、子类目等)之间没有耦合,也是一个麻烦的事情。 具体的需求有几个: 1、购物车点开的时候,页面除购物车的背景要灰掉,同时购车要有上滑的动画; 2、点击购物车或者点击背景的时候,购物车弹下,同时灰色背景去除; 3、购物车中点击商品的增减,要实时反馈到页面上(首页、子类目等); 4、购物车点开之后的大小,由购物车内的物品决定,有最大高度; 5、购物车的物品减到0的时候,不消除; ....

controller与view之间的交互,controller持有view,可以 直接调用view;view要调用controller或者其他view,可以通过事件、委托等方式; 不管是事件还是委托,为的是解耦,让view与controller之间不耦合,所以切记不可在view定义一个controller的属性,然后传递controller进来。 解决方案: view 与 controller 之间用委托(记得@property(weak),否则循环引用,内存无法释放); view 与 view 之间用事件机制;

在interface builder可以用outlet 来做委托机制,非常方便,具体的流程和UITableView类似;

3,事件机制

没有用第三方的事件机制,用的是NSNotifycation来实现; 一开始的做法是:

#define NOTIFY_SERVER_USER_LOGIN     @"NOTIFY_SERVER_USER_LOGIN"
#define NOTIFY_UI_REQUEST_PHONE_CALL  @"NOTIFY_UI_REQUEST_PHONE_CALL"

直接define具体的协议,如果带有数据,就存到notify的userInfo; 这样在代码写了比较多时候,当改动一个notify的userInfo的时候,经常会忘记改其他的某处,而且往往记不得userInfo里面的数据格式,不便于维护;

于是在NSNotify的基础上做了一层封装: 定义一个BaseEvent,负责把event的类型转成nsnotify(类型名字@"",属性转成dict),同时把nsnotify转成event; 同时Event分成几类ErrorEvent ServerEvent UIEvent DataEvent等。 比如:

@interface UIMessageConfirmEvent : BaseEvent
 @property (nonatomic , copy) NSString* message;
@end

发送事件的时候,可以直接在event类型里面给message赋值;

开发中的原则

  • 1,不要有很大的文件,除非很少改动;(大文件,不方便维护和开发)
  • 2,一个函数尽量只做一个功能,如果有多个地方调用,要保证调用的意义是相同的;(尽量不要在调用参数中带默认参数,或者在复杂调用中带flag来标示这次调用的含义)
  • 3,调用时的参数检查,一般由被调用的函数检查参数;如果涉及到参数不对时,需要有相应的逻辑操作,比如弹出提示框等的,尽量由调用者来检查参数;

开发中的问题

问题1:model要不要监听事件?

目前,Model需要被改变的时候是: 1、viewController请求数据时候; 2、message发生变化的时候;(比如说登陆、注销、商店切换)

坏处:message处有各个model的代码。 比如说切换商店后,就有这些变换;

       [self lyPostNotification:NOTIFY_INDEX_DATA];
       [[CartModel instance] onShopChange];        [[CategoryDetailModel instance] onShopChange];
       [[ServiceModel instance] onShopChange];

登出后,需要把这些Model清空;

   [self lyPostNotification:NOTIFY_USER_LOGOUT];
   [[CartModel instance] clearCache];    [[AddressModel instance] clearCache];    [[UserModel instance] clearCache];
   [[OrderModel instance] clearCache];

如果新增model比如说新添加的serviceModel,需要在message处添加相应的逻辑代码;

还有的问题是,Model的clearCache等函数被message调用,耦合性特别强;相当于做了事情A(登出),接着马上做事情B(清空数据),而且是直接调用,以后修改起来很容易犯错误。

设想: 如果model监听事件的话; 那么model只需监听各个事件,然后再写处理函数; model的逻辑都聚合在自身;

带来的后果是,model稍微变大。多个事件,和多个处理函数。 不过这个如果是message处来调用,处理函数还是一样要写,只是多了事件处理监听的代码。 model的逻辑是聚合了,但是注销的逻辑分散了,看不出来注销完干了什么事情。这个问题好像也不是问题,因为可以查看事件的监听者,看到监听了注销事件的model。 有一处代码,集合了所有的model instance。所有的model都必须先初始化。否则无法监听事件。

问题2:调用message的时候,message从各个model获取了数据,那么,谁来做参数检查?

1,谁调用(不同层次之间),谁负责检查参数;比如orderMessage需要用户登录,那么调用orderMessage的时候,就必须保证已经登录。(因为message和model不在同一层次) 2,如果是检查的内容是自身内容,那么由自己负责。

问题3:从页面A (ControllerA) 跳到 页面B(ControllerB),用户的操作数据(比如说留言),怎么合适地从A传到B?

这个是1.5版本架构具体的实现,参考两个概念MVP MVVM。 让显示逻辑和业务逻辑有所分开,是比较重要的。 待完成微信端的开发,再来写一版详细的改动日志。 (然而不可能)

附录

蘑菇街的IM 网络层:

API center 负责管理、注册所有的API;接受服务器数据(可以分离连接代买,仅提供接受数据的接口),调用解析接口,回调API;超时处理;有自己的线程。 有一个SuperAPI 还有一个 APIProtocal superAPI 是所有API的基类,负责注册request和respone、timeout、保存返回闭包、打包数据(调用protocal)、发送数据。 APIProtocal封装了协议的解析、打包。 controller调用实现了Protocal的superAPI子类(childAPI),并且把回调函数的闭包传递进去,放在superAPI。 childAPI实现了APIProtocal 从而对服务器返回的数据解析,并且返回cmd、msgID。

APIcenter 有四个map(request response notify timeout) request是请求 response是回复 timeout是超市处理 notify是服务器通知。 每一次通讯,都需要注册request、response、timeout。 消息处理完后,remove from map。(notify不需要remove)

流程如下:

1.controller 调用 childAPI的request,传入数据(object),和completion闭包。 2.childAPI->superAPI 的request统一处理流程,在center,注册request和respone、timeout、保存返回闭包、打包数据(调用protocal)、发送数据。 3.superAPI通过APIProtocol 调用childAPI的数据打包,调用center 的发送。 4.center收到tcp返回的bytes,调用protocal(在responseMap注册的API)解析。 5.解析完成清除map中的API(request、response、timeout),在主线程回调completion闭包,并且将数据传递过去。 6.controller 收到数据,存到model,显示处理。 7.如果在4过程中,timeout到了,那么直接清除request、resonse、timeout,回调timeout闭包。

总结

  • 1,一个函数尽量只做一个功能,如果有多个地方调用,要保证意义相同。(这样才能复用,不要带flag的参数,混乱)
  • 2,业务逻辑、显示逻辑的代码 集合在一起。(ReactiveCocoa)
  • 3,尽量少出现allModel、allEvent 的东西,不方便添加,多人开发会冲突;
  • 4,发现改一个东西,需要改很多处代码的时候,要考察下关系问题;

Callback block 代替delegate和event进行回调,实现业务聚合,(注意,这里不能代替某些event,比如说登出、拉取订单等,但是最好这些可以反映到model,由model发出变化事件)最合适用于只有一次event 监听,的event。 ViewController的瘦身是MVC实现的要点,用Category、业务细分然后把delegate把代码划分到对应的类。

后记

MVC、MVVM、MVP都是很不错的思想,设计模式里面更是前人经验的总结。 原本计划在做完整个APP再进行一次总结,可后来做微信端的开发,学习Angular-js花费了一大块的时间。再后来,就喜欢玩其他东西了。

培养一些兴趣,这些兴趣不是物质的享受,而是一种能让你思考,进步的兴趣。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏nnngu

通俗易懂的分析如何用Python实现一只小爬虫,爬取拉勾网的职位信息

源代码:https://github.com/nnngu/LagouSpider ---- 效果预览 ? 思路 1、首先我们打开拉勾网,并搜索“java”,显示...

3775
来自专栏IT技术精选文摘

Android内存泄漏监控和优化技巧总结

3693
来自专栏腾讯移动品质中心TMQ的专栏

测试人员代码分析5步法

前言 随着测试行业的发展,测试攻城狮也越来越关注产品的源码了。在很多团队中,读懂代码的实现是做好测试的重要一步,但是读懂代码这件事非常依赖代码能力,没有什么捷径...

27610
来自专栏nnngu

通俗易懂的分析如何用Python实现一只小爬虫,爬取拉勾网的职位信息

源代码:https://github.com/nnngu/LagouSpider

5566
来自专栏PHP在线

建立灵巧结构的PHP程序

很早就想写这篇文章了,但一直没有时间完成它。不是说我来告诉大家如何做,我更希望本文只是做为一个引子,与大家来讨论关于如何建立一个有效地、灵活的网络应用程序。 ...

3086
来自专栏用户1191492的专栏

JClouds的命令行界面

我已经使用JCloud(一种面向Java支持多种云的工具集)一年了。到目前为止,我已经在很多领域广泛地使用了JCloud,特别是在Fuse Eco...

3239
来自专栏日常学python

python使用requests+re简单入门爬虫

在学习了python基础后,一心想着快速入门爬虫,因为我就是为爬虫而学的python,所以就找了这个豆瓣电影来爬取。好了,废话不多说,进入正题 1.找到网页并分...

39411
来自专栏非典型程序猿

Elasticsearch数据更新全方位解析

前段时间在项目的crm存储部分,为了满足大量自定义的搜索功能,选择了使用了ES作为后端存储介质。

3K12
来自专栏py+selenium

py+selenium遇见IE,元素只有name属性【神奇解决】

IE8的问题:IE8不支持getElementByName,而属性中又没有ID,定位难度较大。

4081
来自专栏鸿的学习笔记

Actor模型速览

Actor的核心在于发送消息和接受消息。每一个Actor系统之间的联络都依靠消息的传递,假设现在有两个Actor系统A和B,A会向B发送了一条消息打招呼,或者是...

773

扫码关注云+社区

领取腾讯云代金券