现在越来越多App取消了密码登录

美容美发 急速飞驰 浏览

小编:App与服务器的通信接口如何设计得好,需要考虑的地方挺多的,在此根据我的一些经验做一些总结分享,旨在抛砖引玉。 现在,大部分App的接口都采用RESTful架构,RESTFul最重要的一个设

  App与服务器的通信接口如何设计得好,需要考虑的地方挺多的,在此根据我的一些经验做一些总结分享,旨在抛砖引玉。

  现在,大部分App的接口都采用RESTful架构,RESTFul最重要的一个设计原则就是,客户端与服务器的交互在请求之间是无状态的,也就是说,当涉及到用户状态时,每次请求都要带上身份验证信息。实现上,大部分都采用token的认证方式,一般流程是:

  2. 客户端将token保存在本地,发起后续的相关请求时,将token发回给服务器;

  3. 服务器检查token的有效性,有效则返回数据,若无效,分两种情况:

  然而,此种验证方式存在一个安全性问题:当登录接口被劫持时,黑客就获取到了用户密码和token,后续则可以对该用户做任何事情了。用户只有修改密码才能夺回控制权。

  HTTPS在HTTP的基础上添加了SSL安全协议,自动对数据进行了压缩加密,在一定程序可以防止监听、防止劫持、防止重发,安全性可以提高很多。不过,SSL也不是绝对安全的,也存在被劫持的可能。另外,服务器对HTTPS的配置相对有点复杂,还需要到CA申请证书,而且一般还是收费的。而且,HTTPS效率也比较低。一般,只有安全要求比较高的系统才会采用HTTPS,比如银行。而大部分对安全要求没那么高的App还是采用HTTP的方式。

  给客户端分配一个密钥,每次请求接口时,将密钥和所有参数组合成源串,根据签名算法生成签名值,发送请求时将签名一起发送给服务器验证。类似的实现可参考OAuth1.0的签名算法。这样,黑客不知道密钥,不知道签名算法,就算拦截到登录接口,后续请求也无法成功操作。不过,因为签名算法比较麻烦,而且容易出错,只适合对内的接口。如果你们的接口属于开放的API,则不太适合这种签名认证的方式了,建议还是使用OAuth2.0的认证机制。

  我们也给每个端分配一个appKey,比如Android、iOS、微信三端,每个端分别分配一个appKey和一个密钥。没有传appKey的请求将报错,传错了appKey的请求也将报错。这样,安全性方面又加多了一层防御,同时也方便对不同端做一些不同的处理策略。

  另外,现在越来越多App取消了密码登录,而采用手机号+短信验证码的登录方式,我在当前的项目中也采用了这种登录方式。这种登录方式有几种好处:

  接口的数据一般都采用JSON格式进行传输,不过,需要注意的是,JSON的值只有六种数据类型:

  它会转为类似于”2016年1月7日 09时17分42秒 GMT+08:00”这样的字符串,这在转换时会产生问题,不同的解析库解析方式可能不同,有的可能会转乱,有的可能直接异常了。要避免出错,必须做特殊处理,自己手动去做解析。为了根除这种问题,最好的解决方案是用毫秒数表示日期。

  还出现过字符串的”true”和”false”,或者字符串的数字,甚至还出现过字符串的”null”,导致解析错误,尤其是”null”,导致App奔溃

  后来查了好久才查出来是该问题导致的。这都是因为服务端对数据没处理好,导致有些数据转为了字符串。所以,在客户端,也不能完全信任服务端传回的数据都是对的,需要对所有异常情况都做相应处理。

  不同错误需要定义不同的状态码,属于客户端的错误和服务端的错误也要区分,比如1XX表示客户端的错误,2XX表示服务端的错误。这里举几个例子:

  数据类型限定为对象或数组,当请求需要的数据为单个对象时则传回对象,当请求需要的数据是列表时,则为某个对象的数组。这里需要注意的就是,不要将data传入字符串或数字,即使请求需要的数据只有一个,比如token,那返回的data应该为:

  接口不可能一成不变,在不停迭代中,总会发生变化。接口的变化一般会有几种:

  大部分情况下会采用第一种方式,当某一个接口有变动时,在这个接口上叠加版本号,并兼容旧版本。App的新版本开发传参时则将传入新版本的version。

  如果整个接口系统的根基都发生变动的话,比如微博API,从OAuth1.0升级到OAuth2.0,整个API都进行了升级。

  有时候,一个接口的变动还会影响到其他接口,但做的时候不一定能发现。因此,最好还要有一套完善的测试机制保证每次接口变更都能测试到所有相关层面。

  当你做架构设计时,必然会面临技术选型的抉择,不同的技术方案,架构也可能完全不同。有哪些技术选型需要做决策呢?比如,App是纯原生开发,还是Web App,抑或Hybrid App?iOS开发,语言上是选择Objective-C还是Swift?架构模式用MVC,还是MVP,或者MVVM?下面根据我的一些经验对某些方面做点总结分享。

  关于用原生好,还是用H5好的争论从没间断过。但我觉得,脱离了实际场景来讨论孰好孰坏意义不大。就说我们目前正在做的项目,先说明下背景:

  首先,需求上来说,大部分页面用H5实现,可以减少很多工作量。但因为不可控因素太高,而时间又短,风险太大。而我们对原生比较熟,开发效率比较高,很多东西我也控制得了,风险相对比较低。而且,我们的主推产品是App,微信属于辅助性产品,所以,微信要求也没那么高。因此,我决定以原生为主,H5为辅,App大部分页面用原生完成,小部分用WebView加载H5。

  另外,WebView加载H5也有两种模式,一种是加载服务器的H5页面,一种是加载本地的H5页面。加载服务器的H5页面比较简单,WebView只要load一下URL就可以了。加载本地的H5页面,则需要将H5文件存放在本地,包括关联的CSS和JS文件。这种方式相对比较复杂,不过,加载速度会比第一种快很多。我们当前项目基于上面考虑,只能选择第一种方案。

  如果人员和时间资源充足的话,那又如何选型呢?毫无疑问,我会以H5为主,微信和App都有的页面统一用H5,App专有的部分,比如导航栏、标题栏、登录等,才用原生实现。另外,WebView里的H5有点击事件时,也许是URL链接,也许是调用JS的,都不会让它直接在该WebView里做跳转,需要拦截下来做些原生处理后跳转到一个新的原生页面,原生页面也许嵌入另一个WebView,用来展示新的H5页面。这是简单的例子,关于Hybrid App详细的设计,以后再讲。另外,关于H5,绝对是大趋势,强烈建议所有App开发人员都去学习。

  如果你的团队里没人懂Swift,那还是乖乖用Objective-C吧;如果有一两个懂Swift的,那可以混合开发,并让不懂的人尽快学会Swift;如果都懂了,不用想了,直接上Swift吧。

  当语言上选择了Swift,相应的一些第三方库也面临着选型。比如,依赖库管理,Objective-C时代大部分用CocoaPods,Swift时代,我更喜欢Carthage。Carhage是用Swift写的,和CocoaPods相比,轻耦合,也更灵活。我个人也不太喜欢CocoaPods,使用起来比较麻烦,耦合性也较高,我使用过程中也经常出问题,而且还总是不知道该怎么解决,要移除时也是非常麻烦。

  架构模式上,我不会推崇说哪种模式好,每种模式都各有优点,也各有极限性。越高级的模式复杂性越高,实现起来也越难。最近火热的微服务架构,比起MVC,复杂度不知增加了多少倍。

  我在实际项目中思考架构时,也不会想着要用哪种模式,我只思考现阶段,以现有的人力资源和时间资源,如何才能更快更好地完成需求,适当考虑下如何为后期扩展或重构做准备。就说我前段时间分享的Android项目重构之路系列中讲的那个架构,确切地说,都不属于上面三种架构模式之一。

  技术选型,决策关键不在于每种技术方案的优劣如何,而在于你团队的水平、资源的多寡,要根据实际情况选择最适合你们当前阶段的架构方案。当团队拓展了,资源也充足了,肯定也是需要再重构的,到时再思考其他更合适更优秀的方案。

  一个App,从根本上来说,就是对数据的处理,包括数据从哪里来、数据如何组织、数据怎么展示,从职责上划分就是:数据管理、数据加工、数据展示。相对应的也就有了三层架构:数据层、业务层、展示层。本文就先讲讲数据层的设计。

  网络层主要就是对网络API的封装。关于API的设计,该系列的第一篇文章接口的设计已经讲过一些。关于如何封装,可以参考Android项目重构之路系列的架构篇实现篇,其中接口层和本文的网络层是一样的。

  首先是不同网络状态的处理。当网络不可用时,则不应该再去调用API;当网络可用,但不是WIFI时,有些比较耗流量的操作也应该禁止,比如上传和下载大文件;当网络状态不同时,还可以采用不同的网络策略,比如,当网络为WIFI时,当前API可以返回更多更全面的数据,还可以预先加载相关联的其他API。

  其次,为了节省流量,接口的设计上可以对数据进行简化。例如,对于一些列表类的接口,可以这么设计:只返回更新的部分,比如,上一次请求返回了10条按时间排序的数据,第一条数据为最新的,id为101,当发起下一次请求时,将101的id作为参数调用API,API查到该id,发现该id之后又新增了两条数据,API则只返回新增的这两条数据。

  另外,为了保证程序的健壮性,调用API时,对入参的合法性检查也是很有必要的。而且,也应该定义好本地的错误码和错误信息,保证每个错误都能正常解析。

  本地数据层主要就是做缓存处理,这需要设计好一套缓存策略。设计缓存策略时,有几个问题需要考虑清楚:

  将所有数据都缓存是不明智的,不同的数据应该有不同的缓存策略,比如一个电商App,首页的商品列表数据应该缓存,而且缓存时间应该比较长,而每个商品的详情数据就没必要缓存或缓存时间很短。对于一份数据需不需要缓存,判断标准可以是:用户查看该数据的频率高不高?首页商品列表是用户每次启动都会看到的,而每个商品的详情用户最多只看几次。

  从内存读取数据是最快的,但内存非常有限。因此,内存一般只用来缓存使用频率非常高的数据。

  数据库可以保存大量数据,主要就是用于保存商品列表、聊天记录之类的关系型数据。

  然而,不管缓存在哪里,都需要限定好缓存的容量,要定期清理,不然会越积越多。

  首先,每份缓存数据都应该设置一个缓存的有效时间,有效期的起始时间以最后一次被调用的时间为准,当该数据长时间没有再被调用到时,就应该从缓存中清理掉。

  缓存的有效时间应该设多长呢?可以短至一分钟,长至一星期甚至一个月,具体因数据而异。一般内存的缓存时间不宜太长,程序退出基本就要全部清理了。文件缓存可以设置保留一天或一个星期,可以每隔一天清理一次。数据库缓存再久一些也无所谓,但最好还是不要超过一个月。

  交付层其实就是一个向上层开放的交互接口层,是上层向数据层获取数据的入口。上层向数据层请求数据,它是不关心数据层的数据是从缓存获取还是从网络获取的,它只关心结果,数据层能给到它想要的数据结果就OK了。因此,交付层主要就是定义一堆开放的接口或协议。

  如果接口或协议非常多,那么,将接口或协议按照模块划分也是有必要的。比如微信,按模块划分有:IM、公众号、朋友圈、钱包、购物、游戏等等。模块之间应该尽量相对独立、松耦合。

  业务层其实并不复杂,但是大部分开发人员对其职责并没有理解清楚,从而使其沦落为一个数据中转站。我之前分享过的Android项目重构之路系列中提到的核心层,其实就是这里所讲的业务层。但有不少读者反映,他们在实际项目中就只是做一下参数检查,然后直接调用API,与展示层对接的接口基本也与API的接口一致的。这样,业务层无疑就已经变为了一个数据中转站。

  所以,设计业务层之前,对业务层的职责要先真正理解清楚。这里,我举两个栗子说明一下。

  注册时,界面上一般都会要求用户输入手机号、验证码、密码和确认密码。但是,API接口一般只会有三个参数:手机号、验证码和密码,不会有确认密码。因此,调用接口之前,密码和确认密码的一致性检查是必须的。同时,也要检查这些数据是否为空、手机号是否符合规范、验证码是否有效、密码有没有包含了特殊字符等。正确姿势就是当所有检查都通过了之后,才调用API接口。最后,调用注册接口成功后,可能还要再调用一次登录接口,并可能将用户登录信息缓存起来,方便用户下次启动应用时自动登录。所有这些都属于业务逻辑处理,也就是业务层的工作。

  比如,在一个电商App,当用户浏览某个商品,点击购买时,App首先会判断用户是否已经登录,如未登录,则会跳转到登录页面让用户先登录。如果已经登录,但token已经过期,那需要先去获取新的token,之后才能进行下一步的购物操作。这些逻辑处理,也是业务层的工作。

  比如上面第二个例子,可能很多人就会将用户是否已经登录的判断直接在界面上做处理,当确认登录后,token也是有效的之后,才调用业务层做购买商品的操作,这就是导致业务层沦落为API的数据中转站的直接表现。

  与数据层交互只是调用数据层的接口获取数据,而与展示层交互则需要提供接口给展示层调用。因为业务处理一般属于比较耗时的操作,主要在于底层的网络请求比较耗时,所以提供给展示层的接口数据结果应该以异步的方式提供,因此,接口上就需要提供个回调参数,返回业务处理之后的结果。我之前分享过的Android项目重构之路:实现篇有讲到一种实现方式,可参考。

  展示层是三层架构中最复杂的一层了,需要考虑的包括但不限于界面布局、屏幕适配、文字大小、颜色、图片资源、提示信息、动画等等。展示层也是变化最频繁的一个层面,每天改得最多的就是界面了。因此,展示层也是最容易变得混乱不堪的一个层面。一个良好的展示层,应该有较好的可读性、健壮性、维护性、扩展性。

  我在Android项目重构之路:界面篇中提到过三个原则,要设计好展示层,至少需要遵循好这三条基本的原则:

  保持规范性:定义好开发规范,包括书写规范、命名规范、注释规范等,太阳城娱乐城并按照规范严格执行;

  保持单一性:布局就只做布局,内容就只做内容,各自分离好,每个方法、每个类,也只做一件事情;

  保持简洁性:保持代码和结构的简洁,每个方法,每个类,每个包,每个文件,都不要塞太多代码或资源,感觉多了就应该拆分。

  关于这三个原则详细的解说,界面篇已经讲过的,我这里就不再重复。在此,我只做些补充。

  关于规范,Android方面,我已经分享过一套Android技术积累:开发规范,主要分为书写规范、命名规范、注释规范三部分。iOS方面,苹果已经有一套Coding Guidelines,主要属于命名方面的规范。当我们制定自己的开发规范时,首先就要遵守苹果的这份规范,在此基础上再加上自己的规范。

  最重要的不是开发规范的制定,而是开发规范的执行。如果没有按照开发规范去执行,那开发规范就等于形同虚设,那代码混乱的问题依然得不到解决。

  另外,Android系统本身已经对资源进行了很好的分离,字符串、颜色值、尺寸大小、图片、动画等等都用不同的xml文件定义。而iOS系统在这方面就逊色很多,只能自己实现,其中一种实现方案就是通过plist文件的方式实现和Android一样的机制。

  比如一个电商App,可能会有首页、附近、分类、我的四大模块,工程结构也根据这四大模块进行划分,Android可能就分为了四个模块包:

  之后,每个模块下相应的页面就放入相应的模块。那么,问题来了,商品详情页应该属于哪个模块呢?首页会跳转到商品详情页,附近也会跳转到商品详情页,分类也会跳转到商品详情页,用户查看订单时也能跳转到商品详情页。有些页面,并不能很明显的区分出属于哪个模块的。我接手过的,按业务划分的二手项目中(即不是由我搭建的项目),我要找一个页面时,我认为应该属于A模块的,但在A模块却找不到,问了同事才知道在B模块。类似的情况出现过很多次,而且不止出现在我身上,对业务不熟悉的开发人员都会出现这个问题。而且,对业务不熟悉的开发人员开发新的页面或功能时,如果对业务理解不深,划分出错,那也将成为问题,其他人员要找该页面时更难找到了。

  因此,我更喜欢按组件划分的工程结构,因为组件每个人都懂,不管对业务熟不熟悉,查找起来都明显方便很多。Android按组件划分大致如下:

  Android的Activity、Fragment、Adapter,iOS的ViewController,分别定义一个基类,将大部分通用的变量和方法定义和封装好,将减少很多工作量,而且有了统一的设置,也会减少代码的混乱。比如我在Android项目重构之路:实现篇中提到的KBaseActivity和KBaseAdapter的实现就是例子,当然还可以抽离出更多变量和方法。

  在基类中将这三个方法定义为抽象方法,由子类去实现,这样,子类就不需要实现onCreate()方法了,只要实现更细化的上述三个方法即可。

  自此,该系列的文章暂时就完结了,方法论比较多,很少涉及到具体的实现。因为具体实现的方案很多,而且还要结合实际项目,无法说哪个方案好哪个方案差。但方法论大部分是想通的,所以,本系列主要讲方法论。

  2015年入职新东方参与留留学iOS端的研发,至今,参与了好几个项目(留留学、掌上新东方、SL、乐听说等),最近负责乐听说iOSApp端。不同项目的经历,让我接触到了不同的项目架构和代码风格,也让我对...博文来自:Tony的分享

  移动App架构设计本文主要总结了几种常用的架构模式,基本是层层递进的转载请注名出处 良好的排版在博文来自:追梦

  APP分析过程在项目管理体系PMBOK中归属于项目范围定义(DefineScope)过程。从PMBOK的角度来看,在完成需求收集(CollectRequirements)后,需要对项目和产品的详细范围...博文来自:linco_zhang的专栏

  前言一个月前看了今日头条新的屏幕适配方案,这是传送门,对此不禁拍案叫绝,为此我想把这种方案融入到我工具类中直接一行代码即可适配,如今最新1.18.0版AndroidUtilCode已有其适配方案,其相...博文来自:小羊子的技术专栏

  1.架构设计的目的对程序进行架构设计的原因,归根到底是为了提高生产力。通过设计使程序模块化,做到模块内部的高聚合和模块之间的低耦合。这样做的好处是使得程序在开发的过程中,开发人员只需要专注于一点,提高...博文来自:weixin_30951389的博客

  本文是对我在知乎一个回答的整理,其中的内容大多是对我平时的阅读和实践的总结,希望对Android的开发者有所帮助。但毕竟是个人的一些思考,难免有疏漏,也欢迎对本文的内容提出建议。1.架构设计的目的  ...博文来自:daimengs的博客

  CSDN2016博客之星评选结果公布    【系列直播】零基础学习微信小程序!      “我的2016”主题征文活动   博客的神秘功能App后台架构设计方案设计思想与最佳实践标签:App后台架构设...博文来自:liuweihui521的专栏

  开发之初,可能会由于时间紧,任务重,人员技术技术特点,不同开发人员各种飘技术栈,人员之间代码冗余,再加上遵循公司“快速上线”原则,为完成功能而开发。后期由于业务功能迭代,出现了牵一发而动全身的问题,代...博文来自:小羊子的技术专栏

  三层架构中,数据层和业务层都已经做过了简单的分享,最后,就剩下展示层了。本篇就给各位分享下我在展示层设计方面的一些经验心得。展示层是三层架构中最复杂的一层了,需要考虑的包括但不限于界面布局、屏幕适配、...博文来自:lz0426001的专栏

  目录介绍1.关于项目架构的技术堆栈1.1该项目App整体架构1.1.1目前项目[准备中]使用的架构1.1.2市面常见的架构1.1.3MVP架构使用心得1.2主要的技术要点1.2.1视频播放技术1.2....博文来自:杨充

  前言Web的架构经过多年的发展已经非常成熟了,我们常用的SSM,SSH等等,架构都非常标准。个人认为,Web服务逻辑比较清晰,目的明确,流程也相对固定,从服务器收到请求开始,经过一系列的的,过滤...博文来自:ganyao939543405的博客

  移动App架构设计本文主要总结了几种常用的架构模式,基本是层层递进的转载请注名出处良好的排版在博文来自:Flying_in_the_world的专栏

  写了好几个应用,最近在思考Android APP架构层面的东西,主要的目的是考虑怎么样能按曾经做过的应用都融合到一个架构中;然后也看了一些开源的架构的设计,首先看包结构,基本能看明白这个框架的大概思路论坛

  本文的目的在于总结Android开发中(手机和TV端)常常会用到的一些测试相关的知识,在此梳理,不足之处,还请指出完善。先了解一下测试的基础1.功能测试(黑盒测试)大多的开发程序以功能测试就能解决开发...博文来自:小羊子的技术专栏

  简介本文是对谷歌原生文档的翻译,仅供学习参照。原文链接此文档写给希望学习最优编程实践和架构以开发健壮、高质量APP的开发者。开发者常遇到的问题传统的桌面程序大多数使用场景是有一个启动入口,作为一个独立...博文来自:读书未遍、未敢妄下雌黄

  一个App,从根本上来说,就是对数据的处理,包括数据从哪里来、数据如何组织、数据怎么展示,从职责上划分就是:数据管理、数据加工、数据展示。相对应的也就有了三层架构:数据层、业务层、展示层。本文就先讲讲...博文来自:lz0426001的专栏

  最近因为工作需要,需要招聘Android开发人员,简单聊一下面试候选人的一些想法,希望对你有帮助。1.简历篇:拉勾和51job的选择,简历大家投简历或是发布招聘信息,还是以IT类的专业招聘网为主,建议...博文来自:小羊子的技术专栏

  App架构设计经验之谈1.接口的设计1.1安全机制的设计由于App的接口大部分采用RESTful架构,而RESTFul最重要的一个设计原则-客户端与服务器的交互的无状态性,所以,当涉及到用户状态时,每...博文来自:lzq19931007的专栏

  本文主要是针对于个人的一些理解,和平时真正能用上的。如果有不妥之处,说明还是我个人技术不过关,希望大家多多指正。首先来说,一切得看需求、周期、环境。这三个方面啥意思呢1.需求,就是具体的需求文档,设计...博文来自:大漠dreamer的知识小屋

  我从事手机app服务端开发现在已经是3个年头,自己也整理出了一套相对好用的服务架构,写出来,跟大家一起分享。如有不足,还请多指教。一:基础流程图。其实有一点还需要加上,就是对json的压缩和加密...博文来自:xfxf996的博客

  策略模式在开发中也常常用到,当实现某一个功能时如支付功能时,支付功能可以有多种实现方式,比如微信支付、支付宝支付、一网通支付。再比如实现分享时也可以有多种策略,可以分享到QQ、微信、微博等社交平台。在...博文来自:小羊子的技术专栏

  本文是对我在知乎一个回答的总结和整理,其中的内容大多是对我平时的阅读和实践的总结,希望对Android的开发者有所帮助。但毕竟是个人的经验之谈,难免有疏漏,也欢迎对本文的内容提出建议。1.架构设计的目...博文来自:MAGI的专栏

  自WWDC2016苹果传递出从2017年1月起强制启用应用程序安全传输协议(AppTransportSecurity)的信号,各大厂均开始了HTTPS化的征程。虽然目前苹果将此计划延期,但HTTPS协...博文来自:CSDN的移动开发朋友们

  APP基本框架设计前言    一个良好的APP基本遵循“简单”,“易用”,“高效”,“便维护”,“可扩展”基本也是从这几个原则出发,比较符合用户体验;同时也是比较符合我们开发人员设计程序的初衷,尽量低...博文来自:zhuangzeqin的专栏

  架构因人而异,不同的架构师大多会有不同的看法;架构也因项目而异,不同的项目需求不同,相应的架构也会不同。然而,有些东西还是通用的,是所有架构师都需要考虑的,也是所有项目都会有的需求,比如API如何设计...博文来自:u014651643的博客

  #13; 这篇文章面向的是已经掌握app开发基本知识,想知道如何开发健壮app的读者。注:本指南假设读者对 AndroidFramework已经很熟悉。如果你还是app开发的新手,请查看...博文来自:wc0000000的博客

  由于最近负责一个互联网APP项目,需要重新设计架构,这边架构已经设计完成,做下详解:首先,笔者其实也未达到架构师级别,但是在一直坚信一个原则,架构一定要建立在业务的基础上,没有经过业务就设计的架构就是...博文来自:u014526891的博客

  Android目前流行开发框架中可谓是Rxjava家族如火如荼。本文重点讲解一下Rxjava的入们教程,行文通俗易懂,初学者不容错过。前言Rxjava由于其基于事件流的链式调用、逻辑简洁am...博文来自:小羊子的技术专栏

  App架构设计经验谈:技术选型App架构设计经验谈:接口的设计App架构设计经验谈:数据层的设计App架构设计经验谈:业务层的设计App架构设计经验谈:展示层的设计展示层展示层是三层架构中最复杂的一层...博文来自:专栏

  声明:本原创文章来自作者投稿,首发于CSDN,未经许可,禁止任何形式的转载。作者:王庆友,前1号店首席架构师,先后就职于eBay、腾讯、1号店等公司,精通电商业务,擅长复杂系统业务建模和架构分析,同时...博文来自:博客

  同样是笔记摘录自---极客时间李运华《从0开始学架构》。0、引言架构设计理念关键点:架构是系统的顶层结构. 架构设计的主要目的是为了解决软件系统复杂度带来的问题. 架构设计需要遵循三个主要原则:合适原...博文来自:Leonardo的博客

  转自 安全机制的设计现在,大部分App的接口都采用RESTful架构,RESTFul最重要的一个设计原则就是,客户端与服务器...博文来自:importSUC的专栏

  转载请注明出处:做App做的久了,就想研究一下与之相关的App后台,发现也是蛮有趣的。...博文来自:chenwei957的专栏

  转自: 与服务器的通信接口如何设计得好,需要考虑的地方挺多的,在此根据我的一些经验做一些总结分享,旨在...博文来自:util_c的专栏

  架构因人而异,不同的架构师大多会有不同的看法;架构也因项目而异,不同的项目需求不同,相应的架构也会不同。然而,有些东西还是通用的,是所有架构师都需要考虑的,也是所有项目都会有的需求,比如API如何设计...博文来自:luckydaxiang的专栏

  15.2.3业务逻辑层设计(Presenter)业务逻辑层包括业务处理、数据的生成、处理和转换等业务逻辑相关的类。分为两大功能模块:(1)业务逻辑层接口模块(2)业务逻辑层功能模块强化Presente...博文来自:xjbclz的专栏

  注册功能主要业务逻辑:第一步:填写手机号码,进行手机号码有效性校验,填写密码,确认密码,表单暂存;第二步:选择用户类型,若选择个体商户,则调用个体商户要填写的表单;若选择公司/企业,则调用公司企业要填...博文来自:supercolorpower的博客

  业务层其实并不复杂,但是大部分开发人员对其职责并没有理解清楚,从而使其沦落为一个数据中转站。我之前分享过的Android项目重构之路系列中提到的核心层,其实就是这里所讲的业务层。但有不少读者反映,他们...博文来自:lz0426001的专栏

  与传统的桌面应用程序不同,Android应用程序的结构要复杂得多,在大多数情况下,它们只在桌面快捷启动方式中有一个入口,并且作为单个进程运行。一个典型的Android应用程序是由多个app组件(And...博文来自:不学习傻了吧

  App架构设计实战一:初步引入MVP顺风笑嘻嘻,逆风mmp!接着上一篇,上一篇其实隐含着一个比较大的问题,那就是MainActivity中,逻辑代码太多带来的直接问题就是看起来特别臃肿,如果后面继续添...博文来自:的博客

  软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段,这些抽象组件被细化为实际的组件,比如具体某个类或者对象。在面向...博文来自:A_love_B的专栏

当前网址:http://www.builder.org.cn/tutorials/app/2019/0829/3390.html

 
你可能喜欢的: