首页 > 编程知识 正文

烧脑的逻辑难题,通俗的理解什么叫逻辑

时间:2023-05-06 06:28:28 阅读:134389 作者:869

1“一个人知道的商业逻辑越多,他就是更好的需求分析师。 ”

挑战:什么是业务逻辑?

业务是一个实体单元为另一个实体单元提供的服务。

逻辑是指根据现有信息得出合理结论的规律。

业务逻辑是一个实体单元为另一个实体单元提供服务所需的规则和流程。

就像你家的规矩一样,“吃饭前必须洗手”、“有客人起立”、“睡觉前各自说晚安”——是业务逻辑生活化的例证。

在软件系统体系结构中,软件一般分为表示层、业务逻辑层和数据访问层三个层次。

表示层:负责界面和交互

业务逻辑层)定义业务逻辑(规则、工作流、数据完整性等),接收表示层的数据请求,逻辑判断后,向数据访问层提出请求,传递数据访问结果。 业务逻辑层实际上是中间件,起到了承担自上而下启发的重要作用。

数据访问层:负责数据的读取。

业务逻辑的内容由以下四个部分组成。

域实体:定义业务中具有属性和行为的对象;

业务规则-定义为完成操作必须满足的条件。

数据完整性:某些数据是必不可少的。

工作流:定义域实体之间的相互关系。

以cqdsl网购裤子为例

领域实体: cqdsl、资金账户、订单、裤子、发货单

业务规则: cqdsl在单击“购买”时会生成订单,但必须付钱才能发货,系统会生成发货单。

数据完整性:淘宝网下单必须登录账号,没有账号是无法成功购买的。

工作流程(裤子搜索-找到达成一致的裤子-订单购买-支付-接收。

商业逻辑:搜索“裤子”-找到达成一致的裤子-下单-必须登录账户-结算-支付-领取。

其实只有登录账号才能下单成功,但不需要亚马逊。 今天发现淘宝也不用登录账号就能买到商品,所以每个网站规则的不同,形成了不同的商业逻辑。 业务逻辑不仅包括规则,还包括实体、数据完整性和工作流。 图:

商业逻辑图

商业逻辑图

业务逻辑也需要画图。 叫做商业逻辑图。 与业务流程图有什么不同?

业务流(工作流)是业务逻辑的一部分,它定义对象之间的相互关系,但与规则的创建或数据完整性无关。

其实,我们平时画的业务流程图大多是业务逻辑图。

所谓三层开发,就是将系统的整个业务APP应用分为表示层、业务逻辑层和数据访问层,有利于系统的开发、维护、部署、扩展。

分层是为了实现“高凝聚、低耦合”。 采用“分而治之”的思想,把问题分而解,容易控制,容易扩展

分配资源。

三层开发是将系统的整个业务APP分为表示层、业务逻辑层和数据访问层,有助于系统的开发、维护、部署和扩展。

分层是为了实现“高凝聚、低耦合”。 采用“分而治之”的思想,把问题分门别类地解决,便于控制,拓展和分配资源。

业务逻辑层负责处理系统领域的业务,负责逻辑数据的生成、处理及转换。 它负责输入的逻辑数据的准确性和有效性,但不负责输出的逻辑数据和用户数据的准确性,也不负责数据的表示方式。

JavaEE三层体系结构MVC,分离视图控制器模型

那么这里的商业逻辑是m。

但是,什么是商业逻辑呢? 例如,上传文件和上传代码是商业逻辑吗?

需要在数据库操作增加时进行判断,还有其他业务逻辑吗? (我想我会计算的)

但是,hibernate提供了另一个离线查询对象(DetachedCriter ),我认为提供这个接口的意义是在外面处理业务逻辑。

但是三层体系结构不是独立的吗? 互相不干涉吗? 在服务层出现了sql、hql、criter,不是又连接了dao和服务吗?

DTO(VO )、POJO、BO这些是什么? POJO对应于数据库,BO对应于业务逻辑,DTO对应于页面的转发和显示。

业务逻辑是处理数据的逻辑。 常见的背景代码也是三层操作(controller service Dao ) )这里的三层不是MVC。

例如,我得到了用户名,但保存到数据库中时,用户名字段必须是前台用户名和当前日期的字符串

操作或控制器层是第一层,通常用于接收数据并验证数据的非空或格式是否正确

用户名是否为空、是否为安全字符串等

服务层一般用于实现业务逻辑

此时,userName=userName new Date (;

DAO层是与数据库的交互层

这意味着读写数据库会将逻辑层中的新userName插入数据库中

MVC和三层体系结构无法比拟的三层体系结构是指将程序分为数据访问、业务处理、接口三个层次,而作为软甲整体体系结构的MVC只是接口体系结构, 也就是说,它实际上是三层架构的接口部分,m不是域模型,而是物理模型或者物理模型的一个代理,c是控制器,只能转向而不应该包含业务逻辑。 v是视图。 对于那些任何o,都是实体在不同层的映射。 另外值得一提的是,MVC即使是几个小程序也多被作为软件整体的体系结构来处理,那时m多是实体模型,但那样的时候,v就直接变成了m

接引用,也就是界面对实体产生依赖,这是很不好的(但小程序问题不大),此时可以尝试使用MVP模式解耦。至于业务,看你怎么定义领域模型了,一般像上传文件这种操作并不会牵扯企业的业务,那就不应该当做一个业务,但如果这个上传是在工作流或者一些特殊处理中,则有可能上升到业务。怎么做,要看具体问题。

版权声明:该文观点仅代表作者本人。处理文章:请发送邮件至 三1五14八八95#扣扣.com 举报,一经查实,本站将立刻删除。