设计思路

通用数据权限的设计思路

半世苍凉 提交于 2020-01-15 10:23:56
接着上个襄阳项目的需要, 目前的项目情况是,一期已经把功能权限做完了,可以对不同用户的不同权限功能做到限制,现在需要做数据的权限,不同的用户看到不同的数据。 根据目前的调研情况,有两种数据级别权限设计思路,都可以实现对人员访问的数据权限控制,从而实现不同的人员能够看到不同的数据, 例如经理能够看到其部门下所有人的数据,而单个的员工只能看到自己的数据。用户拥有的权限越大,能看到的数据就越多。 第一种是使用先在网关进行权限的判断,此用户有这个操作的权限,再进行查询,查询时根据参数进行SQL的拼接。网关鉴定是否能访问以及转发请求,对SQL的拼接和处理在各微服务自己内部进行,服务A/B/C都需要自己写需要查询的参数。如下图所示 使用此方式存在一些弊端 ,使用SQL拼接的方式不利于统一管理权限,每个项目有自己的过滤方式,拼接SQL的方式,不利于统一管理,也不方便后期可能出现的规则修改,因为已经硬编码到代码中,需要各个服务自己修改一遍。 优点很明显,足够很简单,只需要根据相应的规则调整SQL就可以了。 第二种方式,专门抽离一个权限鉴定的服务,所有到达网关的请求后,网关去调用权限鉴定服务,进行访问的URL的权限判断,如果鉴定成功,则能够访问,网关转到请求到对应的服务,否则网关直接返回,提示用户没有权限访问。数据权限的控制依然需要各个微服务硬编码到各自的项目代码中去。如下图所示

前端模块化设计思路

北慕城南 提交于 2020-01-11 16:03:21
模块化概念 模块化就是为了减少循环依赖,减少耦合,提高设计的效率。为了做到这一点,我们需要有一个设计规则,所有的模块都在这个规则下进行设计。良好的 设计规则,会把耦合密集的设计参数进行归类作为一个模块,并以此划分工作任务。而模块之间彼此通过一个固定的接口(所谓的可见参数)进行交互,除此之外的 内部实现(所谓的隐参数)则由模块的开发团队进行自由发挥。 程序模块化的目的: 减少循环依赖 减少耦合 提高设计效率 程序模块化的实施: 把耦合密集的归为一个模块 模块间通过固定的接口交互 模块内部实现自由发挥 HTML CSS Images的模块化设计 页面模块化的实施,这里指的是针对除去JavaScript部分的页面代码进行模块化实施。通过html css 图片进行模块化。 页面模块化的实施思路是高度耦合的页面片段封装,模块布局作为公开接口,高度耦合的页面进行封装,使用独立的css文件,高度耦合的图片进行封 装,给某类相关性强的图片建立文件夹。 页面模块化的目的是,实现多人协同开发页面,提高页面研发速度和降低维护难度。研发速度的提升体现在多人协同并行开发, 维护难度体现在减少版本的混乱,根据模块区分版本降低版本间代码冲突和文件错误覆盖。 拆分页面模块,从小到大的分解 1. 拆分页面模块 一个页面有很多个小单元模块组成,他来自有原始需求文档,比如logo,导航,内容1,内容2,内容3,内容4

设计模式

一曲冷凌霜 提交于 2020-01-10 11:28:17
1.设计模式主要解决问题 a.代码的扩展性,2.代码的冗余性 2.策略模式 解决多重if判断问题 设计思路:创建一个接口---创建多个子类实现---把子类的beanID记录在数据库表里---查询表获取相应的beanID ---创建接口类型对象,通过sprig根据查询到的ID获取实现对象,并赋值给接口对象。 根据实现情况,可把beanID的信息放在缓存里 来源: CSDN 作者: hqlai1234 链接: https://blog.csdn.net/hqlai1234/article/details/103919521

mybatis 框架设计思路

折月煮酒 提交于 2020-01-10 11:20:02
1. 编写自定义的配置文件和映射文件。 2. 使用Classloader加载全局配置文件,返回InputStream对象 3. 配置文件加载 全局配置文件加载,将XML信息存储到Configuration对象 使用sax Reader去读取InputStream对象,创建Document对象 使用dom4j+xpath语法去解析Document对象 解析environments标签 封装DataSource对象,放入Configuration对象中 解析mappers标签 映射文件加载,将XML信息封装到MappedStatement对象并放入Map集合 中,key为statement的id,value为MappedStatement对象 使用Classloader加载全局配置文件,返回InputStream对象 使用sax Reader去读取InputStream对象,创建Document对象 使用dom4j+xpath语法去解析Document对象 解析根标签中的namespace属性和select标签 解析id属性 解析parameterType属性,并处理成Class类型 解析resultType属性,并处理成Class类型 解析statementType属性(便于执行时,是选择Statement还是 preparedStatement) 解析SQL语句(#{}和${})

orm的设计思路

痞子三分冷 提交于 2019-12-12 00:34:44
一,我们先搞懂什么是orm? ORM:对象关系映射(Object Relational Mapping,简称ORM),目的是想像操作对象一样操作数据库.因为数据库不是面向对象的,所以需要编程进行映射. 二,那为什么需要ORM呢? 1,个人理解,在以前的时候,几乎大家都接触过SqlHepler,百度上也有很多博客分享SqlHeple帮助类,而这个就是为了很多不想操作数据库的开发者提供帮助,然而数据库帮助类的进阶就是ORM,原理就是想像操作对象一样操作数据库,达到方便开发者开发业务 三,那开发一个属于自己的ORM需要懂得什么技术呢? 1,ORM的开发到对象的映射最根本的就是微软提供的 反射, 是这个 System.Reflection 命名空间 2,熟悉程序操作数据库,属于 system.Data.Common 命名空间 3,属性 Attribute 的使用 四,那一个完整的ORM该怎么设计呢?分哪几个模块呢? 1,数据库语句的拼装(包含增删查改语句) 2,数据库查询条件的拼装 3,查询结果实体的映射 4,以上是核心部分,如多库支持,缓存语句等等都是对核心的扩展 五, 那我介绍自己开发的一个ORM的设计思路和设计结构(NlData) 来源: https://www.cnblogs.com/May-day/p/12026443.html

Redis设计思路学习与总结

你。 提交于 2019-12-11 08:49:46
【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 版权声明:本文由宋增宽原创文章,转载请注明出处: 文章原文链接: https://www.qcloud.com/community/article/222 来源:腾云阁 https://www.qcloud.com/community 宋增宽,腾讯工程师,16年毕业加入腾讯,从事海量服务后台设计与研发工作,现在负责QQ群后台等项目,喜欢研究技术,并思考技术演变,专注于高并发业务架构的设计与性能优化。 下半年利用空余时间研究和分析了部分Redis源码,本文从网络模型、数据结构和内存管理、持久化和多机协作四个角度对redis的设计思路进行了分析,若有不正确之处,希望各路大神指出。 Redis是业界普遍应用的缓存组件,研究一个组件框架,最直观的办法就是从应用方的角度出发,将每个步骤的考虑一番,从这些步骤入手去研究往往能够最快的体会到一个组件框架的设计哲学。以Redis为例,每当发起一条请求时,redis是如何管理管理网络请求,收到请求后又是通过什么样的数据结构进行组织并操作内存,这些数据又是如何dump到磁盘实现持久化,再到多机环境下如何同步和保证一致性……本文就是从网络模型、数据结构设计与内存管理、持久化方法和多机四个角度简要描述了redis的设计和自己的一点体会。 一.网络模型

App 自动化框架设计思路

时间秒杀一切 提交于 2019-12-05 07:26:15
最近在整理和学习Appium+Java 自动化框架,对APP自动化框架的部分设想参考了一些文章,先进行整理下: 框架的思路一: 思考文章来源: https://www.cnblogs.com/yunfeioliver/p/9285904.html 作者提供的框架图,思路不错,可以参考 该架构设计思路总结: 1、PM模型设计:在operation层,使用了业界通用的Page-Object模式,即针对页面或模块封装操作方式,在case层调用operation提供的接口。 2、Operation实现可扩展:用例Case层调用统一Operation接口进行操作,这样不同端的Operation 实现可以在具体实现类中实现 框架的思路二: 思考文章来源: https://yq.aliyun.com/articles/33677?spm=a2c4e.11155435.0.0.556e1219viVgzQ 1、提供的框用例执行流程图 2、数据配置定制:前端根据用户选择配置自动设置配置文件,理想中的配置中心 3、检查中心实现思路: 1,用户自定义检查 2,网络传输层检查(自动化时实时抓包) 3,logcat实时抓取异常log(区粉设备) 4,截图录制、系统抛错,图片解析对比等 4 、元素数据处理逻辑 5 、执行流 框架的思路三: 思考文章来源: https://blog.csdn.net

关于大型web服务器的设计思路

微笑、不失礼 提交于 2019-12-05 01:55:07
大型网站,比如门户网站,在海量用户访问、高并发请求方面,基本的解决方案是以下几点: 1、高性能的数据库(oracle/db2/mysql...) 2、高性能的Web容器(weblogic/apache...) 3、高效率的编程语言(java/C#) 4、使用高性能的服务器(小型机、PC服务器) 5、集群分布式运行(比如上百台小型机器在线运行) 但是在在线用户上百万,日点击量超亿,而数据达几十T,甚至日数据量就达到T级别这种情况下还是难以解决 大型网站面临的高负载和高并发问题。 本人也经常关注这方面的解决方案,结合自己的经验。总结了一部分常用的设计,希望各位多多指点。 一、设计上有足够弹性 这是在前期架构设计师要足够考虑到的。最终目的是通过物理设备的线性投入来应付业务量的增长,而不止于受到技术框架应用部署的限制,甚至推到重来,这样的结构设计就是弹性的设计,当然这里还包括业务上的弹性设计(目前的开发模式、架构设计在很大程度上也是为了解决这个问题)。 一般企业也是极力避免这种情况的发生,否则失去的不仅是成本投入还包括了客户资源。 二、页面静态化 即静态html格式,这样避免了对数据资源的访问,同时也大大降低了应用的CPU消耗。如果能静态页面的信息尽量静态化。 三 、无状态 这里说的无状态是服务器尽量设计成无状态的与客户端通讯,避免了占用大量内存的情况,但这也不是绝对的

多项式求导--设计思路

匿名 (未验证) 提交于 2019-12-02 23:47:01
需要完成的任务为包含简单幂函数和简单正余弦函数的导函数的求解。 本次多项式求导具体包括以下 因子 : 常数因子:包含一个带符号整数,-002; 幂函数因子: x 、 x^-3; 表达式因子: (表达式); 三角函数因子:sin(因子) 、cos(因子) ^2. 因子组合成 项 :因子[*因子]; 项组合成为 表达式 :项[±项]; 要对输入的表达式进行解析,输出对应的导函数。 采用递归下降进行语法分析的思路,按照“表达式――>项――>因子”的顺序,将表达式分解到可以直接求得导数的因子,再逐层将因子的导数返回并组合成项和表达式的导数。 流程图如下: 将输入作为第一个表达式: 并输出该表达式的导函数作为最终结果。 表达式类进行解析拆分出项,项拆分出因子: 因子对象中进行语法分析,提取出第一个因子并返回解析进度给项对象。 特别地,在 表达式因子 解析时会新建一个表达式对象以分析括号内的内容: 与之相似,解析 三角函数因子 时括号内的因子部分也会新建一个因子对象进行解析: 当一个项对其下的因子解析完成时,会得到该项的导函数: 运用该求导公式结合各因子的内容和导函数即可: 当一个表达式中的项都解析完成,表达式的导函数也将可求得: 将各项的导函数与其前面的'+'或'-'号连接即可。

木马上线方式的前前后后

白昼怎懂夜的黑 提交于 2019-12-02 03:51:54
0×00 前言 在讲文章主题之前,我们还是习惯性地聊(che)一(che)聊(dan)。 远程控制木马大家都不陌生,尤其是早期接触黑客技术的人,应该可以发现早在2007-2009年,这段时间内,国内的“黑客技术”正是蓬勃发展的时期,那个时候,可谓是“战乱纷争,万马奔腾”的年代,当时流行各种黑客技术,其中就包括远程控制技术。 各种远程控制木马满天飞,无论是最早葛军编写的“灰鸽子”,还是各种后起之秀的RAT,简直不胜枚举,各种被阉割的xxx专用版,各种新出的xxxRAT。如各类国产远控木马、上兴、PCShare、黑防的ByShell、黑洞、冰河、SRAT、暗组的DRAT、XRAT、维度等等,包括国外的一些C/S,B/S型的远控木马也传入了国内,各家似乎都在比拼谁的功能多,谁的免杀好,谁的反杀软技术强。于是,各种HOOK SSDT,Rootkit级别的木马比比皆是。可是,后来因为国家的管控,各种黑客论坛,黑客网站,黑客杂志相继关闭或消失。远控木马编写技术和木马免杀技术也不再那么流行,当初写木马做免杀的“高手”,如今早已从网络中销声匿迹。 引用王家卫导演的《一代宗师》里边的一句话—— “有的成了里子,有的成了面子,都是时势使然。” 当然,客观的讲,造成这种形势的原因也是国内安全行业的进一步发展所致。不过,我相信依旧有一帮人还在这个领域埋头探索,在努力,木马依旧可以绕过各种杀软。毕竟,