业务逻辑实现方式选择

简介:

   当业务逻辑相对复杂的时候,我的大脑中总会浮现出这样或者那样的解决方式,这些解决方式中有以前使用过的和未使用过的。当面对这种选择的时候,我的大脑是比較混乱的。总是想要去在開始还没有去做就抽象出一层,或者通通的放到一条sql中来完毕。总感觉这种方式是快捷的。

 

   而实际中,我们在做这个页面的时候,前面已经有类似的页面,这个要做的页面也仅仅是在上一个页面的基础上进行了些许的修改。那我为什么不把已经做好的页面直接拿过来,修改一些须要变化的部分,而不是自己去创造一套新的解决方式,或者实现方案。这种每一步都须要我去验证。

   这可能就是思维方式的不同吧。

 

   数学家和物理学家的故事我还须要再复习一遍。由于有时候这样的思维确实是在code时须要的。

故事例如以下所看到的。

希望给我启示的时候也能给别人一些启示吧。

 

   数学家问物理学家一个问题:如今有水龙头、水壶、煤气灶。想烧开一壶水,请问怎么办?物理学家说拿水壶到水龙头灌满一壶。放到煤气灶上。再点着火即可了。数学家说:对,人们都这么做。如今条件一样,任务也一样,不同的是水壶里面已经灌满水了,请问你怎么做。

物理学家说:把盛满水的水壶放到煤气灶上,直接点着火即可了。数学家说。这是你们物理学家的做法,我们数学家可不这么做。物理学便问怎么做,数学家说:把水壶里的水倒掉。---。事实上,数学家是通过这个例如告诉人们:数学中一个很重要的方法--转化,即把眼前的问题转化为已经解决的问题。

 

   这样的思维方式会让我们不断的把新问题变成已经解决的旧问题,近期在弄CAS单点登录,急功近利的想要完毕一件事情。反而欲速则不达,当我们依据文档操作出问题的时候。我们能够返回到不出问题的配置步骤。然后定位问题所在,然后依据自己加入的測试,进一步的来缩小问题的范围。终于找到问题所在,分析问题,推測答案,尝试,推測再次尝试。。。直到能兴奋的看到自己想要的答案。





本文转自mfrbuaa博客园博客,原文链接:http://www.cnblogs.com/mfrbuaa/p/5100282.html,如需转载请自行联系原作者

相关文章
|
1月前
|
测试技术
封装并集中处理业务逻辑
封装并集中处理业务逻辑
11 1
|
1月前
|
设计模式 数据可视化 测试技术
使业务逻辑更加清晰,便于理解和维护
使业务逻辑更加清晰,便于理解和维护
20 2
|
11月前
|
SQL 监控 Kubernetes
业务逻辑复杂如何解决性能问题
上节针对生成订单信息这个接口做了三个阶段的分析定位和优化动作,让TPS变得正常。不过,系统资源并没有完全用起来,这个接口显然还有优化空间。性能优化的过程中,要把资源都用起来。
128 0
|
开发者
业务层设计与开发(定义业务层标准) | 学习笔记
简介:快速学习业务层设计与开发(定义业务层标准)
108 0
业务层设计与开发(定义业务层标准) | 学习笔记
|
数据库 开发者
业务层设计与开发(业务层标准实现类) | 学习笔记
简介:快速学习业务层设计与开发(业务层标准实现类)
100 0
|
开发者
待业务层设计与开发(业务层工厂类) | 学习笔记
简介:快速学习待业务层设计与开发(业务层工厂类)
51 0
|
项目管理
业务逻辑?
业务逻辑?
133 0
业务逻辑?
|
消息中间件 前端开发
使用Pull模型来实现前端的业务逻辑
使用Pull模型来实现前端的业务逻辑
112 0
使用Pull模型来实现前端的业务逻辑
|
XML Java 数据格式
你写的代码扩展性高吗?快试试用Spring注入方式来解耦代码!
你写的代码扩展性高吗?快试试用Spring注入方式来解耦代码!
你写的代码扩展性高吗?快试试用Spring注入方式来解耦代码!
|
存储 消息中间件 监控
复杂任务中,流程的解耦设计
在系统开发的过程中,必然存在耗时极高的动作,是基于请求响应模式无法解决的问题,通常会采用解耦的思维,并基于异步或者事件驱动的方式去调度整个流程的完整执行。
371 0
复杂任务中,流程的解耦设计

热门文章

最新文章