业务逻辑就是处理数据的逻辑啦。一般后台代码也分三层 action(controller) service DAO (这里的三层不是MVC)
比如 我得到用户名 但是在存入数据库的时候 用户名字段应该是前台的用户名加上当前日期拼成的字符串
action或者controller层是第一层 一般是用来及接受数据并且做数据的非空啊 格式是否正确的验证
如用户名是否为空 是不是安全字符串之类的
service层一般是用来做一个业务逻辑的实现
这时候 userName = userName + new Date()
DAO层 就是与数据库交互层啦
也就是读写数据库 将逻辑层得到的新的userName插入到数据库
什么叫业务逻辑
不同的项目有不同的功能,不同的功能需要不同的实现,实现这些核心功能的代码就叫业务逻辑
比如让你实现一个功能,给你两个数,让你获取它的和,你所写的如何才能鸡得任意给定的两个数的和,这个程序实现过程即可成为业务逻辑处理。
经常有人提到业务逻辑,到底什么是业务逻辑
你爸爸
真管的严
说实话吧
要是说假话容易上瘾的
程序的业务逻辑
业务逻辑从名称上来看,首先是业务,这个业务一般是指软件要实现的功能,即客户的业务,要实现这些业务就有一个流程,流程是按某种关系形成的一个链,链之间的关系具有一定的逻辑性,综合起来就构成了业务逻辑。在需求分析中,一般可以用要做什么,怎么做来理解!
业务逻辑层的作用
业务逻辑层(Business Logic Layer)无疑是系统架构中体现核心价值的部分。它的关注点主要集中在业务规则的制定、业务流程的实现等与业务需求有关的系统设计,也即是说它是与系统所应对的领域(Domain)逻辑有关,很多时候,也将业务逻辑层称为领域层。例如Martin Fowler在《Patterns of Enterprise Application Architecture》一书中,将整个架构分为三个主要的层:表示层、领域层和数据源层。作为领域驱动设计的先驱Eric Evans,对业务逻辑层作了更细致地划分,细分为应用层与领域层,通过分层进一步将领域逻辑与领域逻辑的解决方案分离。业务逻辑层在体系架构中的位置很关键,它处于数据访问层与表示层中间,起到了数据交换中承上启下的作用。由于层是一种弱耦合结构,层与层之间的依赖是向下的,底层对于上层而言是“无知”的,改变上层的设计对于其调用的底层而言没有任何影响。如果在分层设计时,遵循了面向接口设计的思想,那么这种向下的依赖也应该是一种弱依赖关系。因而在不改变接口定义的前提下,理想的分层式架构,应该是一个支持可抽取、可替换的“抽屉”式架构。正因为如此,业务逻辑层的设计对于一个支持可扩展的架构尤为关键,因为它扮演了两个不同的角色。对于数据访问层而言,它是调用者;对于表示层而言,它却是被调用者。依赖与被依赖的关系都纠结在业务逻辑层上,如何实现依赖关系的解耦,则是除了实现业务逻辑之外留给设计师的任务。
业务逻辑层的主要功能是什么?
业务,就是business,就是一个单元(个人,组织等)给另一个单元提供的服务。逻辑(logic)就是指人们思考问题,从某些已知条件出发推出合理的结论的规律。所以逻辑不可能离开业务,这个逻辑也就是常说的业务逻辑(business logic),它是用来管理业务功能的一系列guildlines。你看到的
里的业务应该是如richard所说的业务实体(business entities),是一种简化的说法;逻辑也是业务逻辑的简化。
*业务逻辑是你在分析阶段对你的软件的应用领域进行分析总结出来的,它存在不依赖于你的软件的存在,相反,它先于你的软件存在并限制了你的软件应有的行为。
凡是业务逻辑都应该放到中间层,不能让客户端去决定。有时为了减少网络访问次数,在客户端会有一此与业务逻辑有关的检验,但在中间层这一检验同样不能省略。比如上面说的日期的判断,客户端可以有也可以没有判断,但中间层一定要有这一判断。
* 举个例子讲 日期字段 在数据库逻辑或者说是数据层仅仅需要判断他是不是日期类型的
但对于业务逻辑来讲仅仅输入一个日期是不够的,比如销售订单的执行日期就不能比销售订单的制定日期早;所以判断用户输入是否正确实际上 就是两方面:首先看他是否符合数据规范其次是是否符合业务规范
*
逻辑就是人类思考的过程
业务逻辑就是模仿人类思考的过程
(这种方式最好理解,也最好修改)
页面逻辑,
数据库结构,
都是电脑想问题的方式
如果想要作逻辑层
那么就要先写好业务逻辑
之后把页面逻辑与数据库语句
向这个方向凑
而不是定好数据库之后把业务向数据结构上凑
这是个想法骇题作的时间长了就知道其中的区别了
平时区别不是很大的....
*举一个订单的例子,可能有点文不对题,希望能从另一个侧面加深大家对这个概念的理解:
业务逻辑是企业的行业特性、企业文化、能力结构和资源状况所形成的个性特质下对核心业务处理的基本路径和方式。那么我们的业务逻辑到底是什么呢?就是将订单信息快速全息广播到有关岗位,并行配置资源,动态调度岗位任务,让订单有序地在各个岗位间流动,最终在客户的包装物仓库形成物为载体的闭环。这个逻辑是基于流水生产、离散加工、快速交货、规格不一、需求复杂的基本事实和东经人恪守本职的基本属性作出的。
在这个业务逻辑下,订单应该是什么样的呢?订单除了基本的客户基本信息、产品基本数据和技术要求之外,还必须有工艺路线、运输方案、信用控制等方面的选择与控制,以锁定需求满足的基本路径,这样订单信息才算是丰满的,它全息了订单在公司内部流动的基本行为模式,充分表达了东经的个性。只有这样的订单才算有了基因
业务逻辑层的介绍
所谓的三层开发就是将系统的整个业务应用划分为表示层,业务逻辑层和数据访问层,这样有利于系统的开发、维护、部署和扩展。分层是为了实现“高内聚,低耦合”。采用“分而治之”的思想,把问题划分开来各个解决,易于控制,延展和分配资源。业务逻辑层
在java开发中什么是业务逻辑?
业务逻辑就是处理数据的逻辑啦。一般后台代码也分三层 action(controller) service DAO (这里的三层不是MVC)
比如 我得到用户名 但是在存入数据库的时候 用户名字段应该是前台的用户名加上当前日期拼成的字符串
action或者controller层是第一层 一般是用来及接受数据并且做数据的非空啊 格式是否正确的验证
如用户名是否为空 是不是安全字符串之类的
service层一般是用来做一个业务逻辑的实现
这时候 userName = userName + new Date()
DAO层 就是与数据库交互层啦
也就是读写数据库 将逻辑层得到的新的userName插入到数据库
ecshop的业务逻辑是什么样的
$remember 值为1时,记住此次登录信息,用cookie把用户名和密码保存在客户端,下次打开网站时,先判断session是否存在,如果不存在,查找cookie是否
存在,如果存在,用cookie登录。
什么是业务逻辑????
和以前不同的是,这次我更多的参与了业务逻辑分析的过程。和客户面谈,了解他们的需求,常常是在做程序的时候才发礌又忽略了什么问题,然后再拿起电话。这个反复的过程让人觉得烦琐而又无趣。放下电话的刹那,我明白很多代码其实是白写了,然后就是修改。以前自己好象更看重的是所谓的技术能力,spring,struts,hibenate,webwork,报表,邮件,设计模式等等。现在觉得好象并不是这么一回事,客户并不会管你具体是用了hibenate或是JDBC,他们关心的是他们的业务流程能否实现。从这种意义上说,好的沟通能力和分析能力也许显得更加珍贵。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)