摘要：但是站在抽象层次和接口的复用率角度应该第四种才是最合理的场景二有两个接口和现在在组合层需要同时调用和来组装成一个新的实体。
场景 场景一
用户基本信息的展示.产品需要有3个页面,分别面向的是消费者,运营,商家。所以3个页面的内容不是完全一样的,并且有些内容是敏感的,但是他们的数据源是一致的。现在一共有四种解决方案:
分别写三个DAO,根据页面需求返回不同的数据
分别写三个service,调用的是同一个DAO,在service中根据页面需求进行裁剪
分别写三个组合层的接口,组合层调用的是同一个service,然后在组合层根据页面需求进行裁剪
根据页面需求在controller层对字段进行裁剪,调用的是同一个组合层
处理方式:在这个场景中,我一开始选择的处理方式是第三种,当时是基于公有转换代码的重复利用。但是站在抽象层次和接口的复用率角度应该第四种才是最合理的
场景二有两个接口ServiceA.methodA()和ServiceA.methodB(),现在在组合层需要同时调用methodA()和methodB()来组装成一个新的实体。有两种方案可以解决:
在ServiceA中重新写一个方法methodC()给组合层使用
在组合层自己写私有方法或者Utils方法去组装实体
场景三电商系统商品详情页,有放入购物车和直接购买两个选项,直接购买选项也会放入购物车,但是和实际上的购物车是分离的。实现方式有三种:
前台通过传递一个时间戳t来标示是放入购物车还是直接购买,如果t=0就是放入购物车,如果是t!=0就是直接购买。购物车相对应也有两个接口Service.MethodA(),Service.MethodB(long t),分别对应放入购物车和直接购买(这里的t对购物车模块有特殊作用)
购物车值提供一个接口Service.Method(long t),在购物车模块中根据t自己去判断是直接购买还是放入购物车
前台传一个标示flag表示是否直接购买,购物车提供两个接口Service.MethodA(),Service.MethodB()(这里去除了购物车模块对时间戳t的依赖)
场景四一个Service.Method()返回了一个A实体.现在有新的需求发现A实体返回的字段太少了,得多加一个字段。这个时候有两种处理方式:
直接在A实体中添加
重新写一个接口返回的是实体B,B比A要多一些字段
总结场景一和场景四代表的是各个层次如何定义自己的接口,以及是否需要定义一些特殊的接口,目前感觉:在开发之前需要评估一下每个接口的调用频率,是否需要定义一些多带带的返回接口(除非明显感觉有性能问题,一些接口可能返回一些大字段,而这个大字段在很多场景下是用不到的,或者因为接口需要返回一个字段而需要做很多消耗性能的工作,或者接口返回50个字段,而我只需要一个字段,并且这种场景很多。这些可以多带带定义一些特殊接口),而其它的可以共用的接口尽量共用,当后期在线上运行的时候发现某个调用确实因为接口太粗而导致了性能问题,那么可以重新拎出一个接口。
场景二代表的是,一开始定义的接口粒度很小,但是后期需求发现上层调用需要用到一个粒度更加大的接口,这个时候需要分析这种场景是否很多,如果发现很多,就可以多带带为其开一个新的接口，新的接口调用内部的粒度小的接口来组合成一个新的返回实体(假设这些实体分属不同的表),这种相当于在原来的层次中间加了一层层次更加高的抽象,如果以后这种越来场景越多(小粒度组成大粒度),这层就会变得越来越明显。
场景三,表示的是模块需要给上层提供什么样子的接口,一些模块内部的信息或者其它东西就不要暴露给上层调用者,比如方法一合方法三的不同之处就是是否需要知道内部的Key是要用时间戳来表示的,所以在设计接口的时候需要同时站在使用者的角度和设计者的角度考虑,尽量不要把内部的实现细节暴露给使用者(比如上述的例子,如果以后不是以时间戳来当key的话,那么这个接口传入的时间戳就显得毫无意义的)，当然也不是一定要遵循这个原则,当接口由于你传入一个参数而导致性能出现了质的飞跃,那么这些反设计的接口还是允许存在的
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/65368.html
摘要：本书概括以软件系统为例，重点讲解了应用架构中的物理设计问题，即如何将软件系统拆分为模块化系统。容器独立模块不依赖于具体容器，采用轻量级容器，如独立部署模块可独立部署可用性模式发布接口暴露外部配置使用独立的配置文件用于不同的上下文。 本文为读书笔记，对书中内容进行重点概括，并将书中的模块化结合微服务、Java9 Jigsaw谈谈理解。 本书概括 以Java软件系统为例，重点讲解了应用架构...
摘要：一个复杂的应用都是由简单的应用发展而来的随着越来越多的功能加入项目代码就会变得越来越难以控制本文章主要探讨在大型项目中如何对组件进行组织让项目具备可维护性系列目录类型检查组件的组织样式的管理组件的思维状态管理目录组件设计的基本原则基本原则高 一个复杂的应用都是由简单的应用发展而来的, 随着越来越多的功能加入项目, 代码就会变得越来越难以控制. 本文章主要探讨在大型项目中如何对组件进行组...
摘要：上一篇，讲到了，最近，在做的设计对于设计，一方面是对于后端框架的设计，另一方面呢，是对于整个体系的设计在这里呢，我们来理理思路，先来大致分一下块风格就不用说了，我们就用风格，接下来，也就是我们所说的接口描述语言框架，整个服务的核心驱动版本控 上一篇，讲到了，最近，在做 api 的设计 对于设计，一方面是对于后端 server 框架的设计，另一方面呢，是对于整个 api 体系的设计 在这...
摘要：前言关于设计模式，想必大家的第一感觉就是过于高深，有点虚吧。为什么要学习设计模式因为要装逼啊咳咳，大家请忽略前面那句话。处处都是设计模式的体现，所以若想攻下，设计模式是必学的。下节预告单例模式 前言 关于设计模式，想必大家的第一感觉就是过于高深，有点虚吧。相对来说，我们还是更熟悉ssh或者ssm之类的开发框架，一个工具用久了就会熟能生巧，就像刷漆工，时间长了也知道如何刷的一手漂亮的好墙...
阅读 835·2021-09-09 09:32
阅读 2738·2021-09-02 10:20
阅读 2614·2021-07-23 11:24
阅读 788·2019-08-30 15:54
阅读 3595·2019-08-30 15:54
阅读 1299·2019-08-30 11:02
阅读 2795·2019-08-26 17:40
阅读 1083·2019-08-26 13:55
