业务逻辑:写一个公共拦截类,过滤传进Controller的参数 为了调用接口安全起见,每个需要调用的接口有一个参数accessToken,用于安全验证 注:先进入过滤器Filter,再进入aop,最后进入Controller,我们做的事在aop过滤Controller参数 package com.xgt.config; import com.xgt.common.BaseController; import com.xgt.common.PcsResult; import com.xgt.uti

作为一个写业务逻辑的boy,我需要专注的就是把业务逻辑写好.写业务逻辑并不复杂,就是把编程最基础的东西使用好,有变量.循环.流程控制.函数.数据库等. 但是写出的逻辑要通俗易懂.易于理解,避免炫技.晦涩.在目前团队中待了一段时间了,根据 code review 和自己的理解整理出一些基本原则. 业务代码思想原则 第一:代码要足够容易阅读. 代码是给程序员阅读的,首先要做到的就是逻辑清晰,易于阅读.所以要避免毫无意义的变量名.嵌套过多的逻辑判断.过于复杂的流程控制.在易读性和性能两者之间,首先要保

上次搭建好了项目框架,但还是觉得不太对劲,后来才想起来没有对开发目标进行定位,这个小demo虽然不用做需求分析,但是要实现什么效果还得明确.后来想了一下就做个最简单的网站,目标定为小公司进行展示用的网站.功能有显示用的文章功能(新闻.产品展示.公司介绍等),咨询留言,评论等,另外还包括用户管理,网站设置这两个部分,算是个极简的网站吧. 目录: ASP.NET MVC5 网站开发实践 - 概述 ASP.NET MVC5 网站开发实践(一) - 项目框架     前面项目的层次和调用关系都说明了,关

本篇文章讨论并不是:不要使用存储过程,因为有些事情还是要存储过程来完成,不可能不用.而是关于:"业务逻辑是不是要封装在存储过程中实现,这样子php.java等就是调用存储过程". 业务逻辑,通俗说就是:比如要取数据的操作,取出会员编号为x的数据,原来我们一般是封装成函数,或者直接编写sql语句查询.现在是交给数据库的存储过程去完成. +------------------------------------------------------------ 写这篇文章的缘由 +-----

前言 上一篇文章说到,参数校验,往往需要和全局的异常拦截器来配套使用,使得返回的数据结构永远是保持一致的.参数异常springboot默认的返回结构: { "timestamp": "2019-04-25T13:09:02.196+0000", "status": 400, "error": "Bad Request", "errors": [ { "codes":

前言 上一篇文章说到,参数校验,往往需要和全局的异常拦截器来配套使用,使得返回的数据结构永远是保持一致的.参数异常springboot默认的返回结构: { "timestamp": "2019-04-25T13:09:02.196+0000", "status": 400, "error": "Bad Request", "errors": [ { "codes":

专人写接口+模型,专人写业务逻辑---interface_model -- business logical 0-控制台脚本重构为“面向接口编程”:1-仓库类通过__constru方法,来实现一处实例化model,提高代码复用性:2-写通用仓库方法public function updateMainTableRow($country, $updateDbId = 0, $updateArr = array(), $whereArr = array('equal' => array(), 'gt'

更多技术分享可关注我 前言 Netty以高性能著称,但是在实际使用中,不可避免会遇到耗时的业务逻辑,那么这些耗时操作应该写在哪儿呢,有什么注意的坑吗?本篇文章将一一总结. Netty线程调度模型回顾 这部分内容前面都有总结,很简单,只要心中有一个图像就能hold住——对于Netty来说,它的每个NIO线程都对应一个转动起来的“轮盘”,即I/O事件监听+I/O事件分类处理+异步任务处理,三件事组成一个“轮盘”循环往复的转动,直到被优雅停机或者异常中断...大概结构如下: 具体细节和源码的分析参考:

概要 你是不是在为业务逻辑中出现的异常弄的焦头烂额,常常在后台报错,前端却无法提示错误内容,导致用户体验极差?比如下单失败,前端只能提示下单失败,但是却不知道为什么失败,是库存不足,还是余额不足,亦或是商品已经失效? 之前想在 service 层直接返回封装好的 Reponse(code, data,msg) 对象,这样的话我就直接在service层提示出错原因了(msg:错误提示),但是这样代码就不够美观,因为Response原本是设计为后端统一返回的对象,太臃肿,最后决定用自定义异常来完成.

首先需要说明的是这是.net framework的一个组件,而不是针对.net core的.目前工作比较忙,因此.net core的转换正在编写过程中,有了实现会第一时间贴出来. 接下来进入正题.对于大型的分层系统,会有一个应用程序层,应用程序层的主要作用是封装业务领域层的业务逻辑层,并对界面展示层提供服务.界面展示层例如有Web网站.移动应用.WPF等等,例如下图. 很多情况下,业务领域层中间的业务逻辑层方法和应用服务层的服务接口几乎是一致的.在业务逻辑方法编写完成后,编程人员,也会重复性的编

序言 前两篇讲解了UIMediator框架的使用及具体原理代码.本篇讲述MediatorManager的实现代码及展望. MediatorManager MediatorManager的作用有两点: 一是解除前端对Mediator子类的依赖,所有前端只需与MediatorManager交互,不需知道Mediator子类: 二是通过MediatorManager可以实现其他前端控件的扩展. 以下为MediatorManager实现代码(笔者在写作本文时,将Bind<T>更改为静态函数) publ

序言 .NET(C#)的WinForm如何简单易行地进行UI与业务逻辑分层?本系列文章介绍一个WinForm分层框架,该框架针对WinForm中的TextBox,CheckBox,RadioButton三种UI控件进行简单粗暴的UI与业务逻辑分层实现. 背景 软件行业发展至今,分层的思想可谓是深入人心.企业应用架构模式中三层架构的思想早以众人皆知,MVC的框架正在引领着WEB开发的潮流.但在MES系统开发这块,虽然众多厂商均标榜自身产品皆采用分层架构,但细究下也只是框架上做到了分层,在粗粒度上还

前言      从上篇30岁找份程序员的工作(伪程序员的独白),文章开始,我说过我要用我自学的技术,来搭建一个博客系统,也希望大家给点意见,另外我很感谢博客园的各位朋友们,对我那篇算是自我阶段总结文章的评论,在里面能看出有很多种声音,有支持的我的朋友给我加油打气,有分享自己工作经历的朋友,有提出忠肯意见的朋友,有对记事本写代码吐槽的朋友,也有希望让我换个行业的,觉得我可能不适合这个行业朋友,不管怎样,我都接受,都是大家同行的一些忠告,谢谢大家. 首先我要在这里感谢很多博客园里面的大牛,写了很多系

一.问题背景 现在的移动刚一通话就可以在网站上看自己的通话记录,以前是本月只能看上一个月.不过流量仍然是只能看上一月的. 目的就是找到用户在一段时间内的上网流量. 本文并没有对时间分组.下一节进行分区,有兴趣的参看下一篇. 二.数据集分析 可以看出实际数据集并不是每个字段都有值,但是还好,完整地以tab隔开了,数据格式还是不错的,我们需要的上行下行数据都有,没有缺失值.其实这个需要在程序中处理,如果不在的话 该怎么办. 1363157985066 13726230503 00-FD-07-A4-

这个问题,我现在才明白该怎样描述这个已经困惑了我很久的问题,在公司做的项目中,js对于数据验证起到了很大的作用,但是这使得整个项目的业务逻辑变得零散,甚至混乱 现在公司里的项目就是这样的.现在再想想,公司项目中的service层为什么写的那么简单,为什么action很多时候做了service层做的事情 如果用纯java去做处理业务逻辑,去做数据验证,也是可以的,spring框架中也有,但是现在我还不能熟练的掌握,我还需要更多的练习 我现在的想法是,javascript,甚至很好用的jquery,

一.点击更多按钮 1.项目需求      点击更多按钮,从底部弹出一个框  2.怎么从底部弹出一个框?           两种方法:                 一种用 UIActionSheet           另一种用 UIAlertController            2.1 使用UIActionSheet           好处: 不需要控制器,直接就能使用           缺点: 方法过期了,监听按钮的点击比较麻烦        源代码: // 以后只要发现有可变

前两节讲到怎样生成一个Model和怎样将Model映射到数据库,这一节将讲到业务逻辑层,也就是Service层. 1.Prodinner架构已经构建好的,基本的增删改查. 假设,我现在想操作第二节中讲到的TB_Instype数据库表,基本的增删改查. 1)我可以不写Service层,直接继承Cruder(Controller),来继承该Controller里封装好的增删改查. 2)我们来看一下Cruder里的代码 它是继承自Crudere类. 3).我们再看一下Crudere类 可以看到Crud

产品经理们, 看看你们的交互文档, 有n个逻辑分支, 在我们的实现中至少存在2*n个逻辑分支 这样极度造成了app的不稳定性,表现就是 非必须的bug很多.还有就是维护性极差 当然你们会说,你们可以写一些高内聚和少耦合的代码 来减少依赖. 我想说的是,我去,业务逻辑的代码,你搞这么多分支, 对应这么多业务情况,还要加上异常情况,完全没有 使代码高内聚. 客户端比较常用的模式MVC,MVVM,MVP 业务逻辑的复杂直接导致V,VM,P很复杂 甚至最后这3种模式发展成为四不像.

接下来,我们就要到业务逻辑层了,简单的说,业务逻辑层就是调用Repository(可以看做是DAL数据库访问层) 先来看看项目的架构 我们现在就开始来做BLL层.  同样,先编写  UserInfoService ,这个就是调用 UserInfoRepository 先添加对项目的引用,Model层,IRepository(数据库访问层的接口),Repository(数据库访问层),由于我们的Model是使用EF的,那么还需要引用System.Data.Entity 我们先来编写 UserInf

不能说所有的bug都是纸老虎,但往往那种看似很奇葩的bug,导致的原因确实很简单,烦了你一段时间,找到真相又让你忍不住一笑.什么是奇葩的bug呢.我的定义是:代码逻辑都一样,但在A处是好的,到了B处就不行或者同类的ABC都是好的,D却不行了的bug.而最终,问题确实不在代码逻辑上面,往往是配置.权限或者业务逻辑之外的地方. 本地都是ok的,服务器还是不行,怪我咯 case1:本地工程改好,推倒服务器上,但一会儿,测试妹妹又叫了,“还是不行,你再看看”.顿时眉头一皱,怎么可能,自己又run一遍,妥