在网上看了许多资料,JavaEE三层架构MVC，把视图控制器模型分开来。
那么在这里业务逻辑就应该是M。
但是什么样的算是业务逻辑如：上传一个文件，上传代码算是一个业务逻辑吗？
数据库操作增加时需要判断，和一些其它这算业务逻辑吗？（我觉得算）
但是hibernate又提供了一个离线查询对象（DetachedCriter），提供这个接口的意思我想是在外面处理业务逻辑。
但是三层架构不是独立的吗？互相不干涉吗？在service层出现sql，hql，criter不是又把dao与service连在一起了吗？
DTO（VO），POJO，BO这些是什么，POJO对应数据库，BO对应业务逻辑，DTO对应页面的传输与显示。
============================================================================================================
详细理解业务逻辑：http://www.uml.org.cn/zjjs/201008021.asp
============================================================================================================
业务逻辑就是处理数据的逻辑啦。一般后台代码也分三层 action(controller) service DAO （这里的三层不是MVC）
比如 我得到用户名 但是在存入数据库的时候 用户名字段应该是前台的用户名加上当前日期拼成的字符串
action或者controller层是第一层 一般是用来及接受数据并且做数据的非空啊 格式是否正确的验证
如用户名是否为空 是不是安全字符串之类的
service层一般是用来做一个业务逻辑的实现
这时候 userName = userName + new Date();
DAO层 就是与数据库交互层啦
也就是读写数据库 将逻辑层得到的新的userName插入到数据库
============================================================================================================
其实分层是很好的。
但就是 在MVC 很多的人在action中写业务代码，更有人把数据库的代码也写到了action中，这明明就不理解
分层的意思。应该做到各负其责。
以下是我在一个论坛在看到的。共大家分享。
我感觉mvc最重要的好处是在开发较大项目中，
可以让流程中各个模块各司其职。
至于
A、“很多人在Struts的Action控制器中写业务代码”，
只能归咎于2点。
1、写代码的人“修炼”不够。不能理解高内聚低耦合的OO思想主旨
2、项目负责人放任自流。导致代码混乱。
B、“控制器变得依赖信息数据中心或数据库”
现在的MVC应该大概都再用spring这样的IOC容器再对控制器进行分层，诸如service层dao层之类，
说“依赖”，也是应该service和dao之间的依赖。
而且这种依赖是和需求相关的，也就是和业务逻辑相关的，
个人感觉也是一种“合理的存在”
C、“对象将间接地通过控制器的action耦合在一起”
这个“缺点”到很客观。
不过，作为开发整个项目的人来说，
“构架师制定框架，程序员去实现业务逻辑“是“完美的结构”。
DDD对于中小项目可能更有“效率”，
但是对于大项目而言，
可能会让构架师和程序员的工作分工不明确。
构架师过多的考虑业务细节；而程序员则会接触更多，不属于自己的“细节”
这样可能会增加开发成本和带来更多的bug
而“对象和action耦合在一起”，也基本符合具体业务流程设计的思考方式
(就像一串糖葫芦，山楂的就串山楂，山药蛋的就串山药蛋)
（更不能指望需求定制和需求分析人员考虑构架/代码方面的内容）
（没有贬义，的确也不应该他们去考虑这方面的内容）
D、“重要的事情都集中在控制器中”
和B的观点一样，使用spring可以更好的“细化”责任、更好的执行“开闭原则”
好吧，既然是“only interesting”，那就让它“interesting”吧
但不要“only”
这是我对作者4点的一点个人见解，
也许是被MVC“奴役”惯了，
导致思维模式僵化，说话也比较极端。呵呵
当然作为一种技术领域新的概念，
无论有任何发展都是好的。
但是存在就是有价值，
“已死”之类的词还是有点“牵强”，
（也许有一点点点点“哗众取宠”的意思）
servlet 出现的时候，perl/php已死
jsp出现的时候，servlet已死
struts2出来的时候，struts1已死
============================================================================================================
业务逻辑包含2方面内容，验证与计算
业务逻辑就是个抽象的概念，就是数据在不同的层次进行传递过程中形成的各种关系，比如你从数据库中查出一条数据，要在页面上显示，并且要对这条数据提供增删改的的操作，而且还要考虑根据不同的用户区别显示不同的信息，对应着不同的业务操作，最终所有的重点都要落到数据这个点上，
只有把软件开发理解成一个数据不断交互的过程，才能真正理解所谓的逻辑，业务逻辑只是其中的一种，逻辑本身就是以数据为载体的，希望能帮到你！
============================================================================================================
我想说业务逻辑跟什么三层、MVC啥的一点关系都没。。。。
什么叫业务逻辑？“某优惠政策，A类顾客优惠10％，B类顾客优惠20％”，用于处理此业务规则的逻辑，就叫业务逻辑。
============================================================================================================
业务逻辑：是个抽象的概念，一两句话说不清数。
首先要理解好MVC，view是显示层，这个就不用多说了，
controller是控制层，只负责页面的跳转，不实现的复杂的逻辑。
Model是业务逻辑层，根据实际的开发需要，一般这个model层又分为DAO层，Service层，DAO是数据传输，主要对数据库进行一些操作，Service即使服务层，很明显是面向实际的功能的。
比如，一个简单的登入，前台输入username，password，DAO层写一个方法isExist(String name,String pwd)，从数据库中查询是否存在。Service这时调用了这个方法实现判断登入，isValid(String name,String pwd){ isExist(name,pwd)},当然这个逻辑不复杂，完全没有必要用Service层，直接用Dao层就可以。
只是说明，这几个层的关系，可以按四层多层理解。业务复杂时把model层又衍生了两层，DTO，数据传输对象，POJO瞬时对象等，以后练习中会慢慢理解的，我也是自己一个人看书，做项目，过来的。我的水平现在还很烂，只能给你介绍这么多，祝你早日成长为一名高手
============================================================================================================
我觉得不必把这些概念想得过于复杂
javaee既然用于企业，就是要把企业的信息电子化，那么以前可能写在本上或白板上的企业行为，一般认为是所谓的“业务”
比如员工考勤就是企业实际的业务，这个业务是有规范和流程的，就是所谓的“业务逻辑”。
程序中，我们把实际的问题抽象成java对象来承载信息，通过这些对象相互作用完成信息的处理和转换，这些java代码就被称为“业务逻辑处理”代码
业务逻辑应偏重企业真实的业务需求处理，也就是你开发的ssh与别人开放的ssh主要不同的部分
============================================================================================================
业务，就是business，就是一个单元（个人，组织等）给另一个单元提供的服务。逻辑（logic）就是指人们思考问题，从某些已知条件出发推出合理的结论的规律。所以逻辑不可能离开业务，这个逻辑也就是常说的业务逻辑（business logic），它是用来管理业务功能的一系列guildlines。你看到的
里的业务应该是如richard所说的业务实体（business entities），是一种简化的说法；逻辑也是业务逻辑的简化。
*业务逻辑是你在分析阶段对你的软件的应用领域进行分析总结出来的，它存在不依赖于你的软件的存在，相反，它先于你的软件存在并限制了你的软件应有的行为。
凡是业务逻辑都应该放到中间层，不能让客户端去决定。有时为了减少网络访问次数，在客户端会有一此与业务逻辑有关的检验，但在中间层这一检验同样不能省略。比如上面说的日期的判断，客户端可以有也可以没有判断，但中间层一定要有这一判断。
* 举个例子讲 日期字段 在数据库逻辑或者说是数据层仅仅需要判断他是不是日期类型的
但对于业务逻辑来讲仅仅输入一个日期是不够的，比如销售订单的执行日期就不能比销售订单的制定日期早；所以判断用户输入是否正确实际上 就是两方面：首先看他是否符合数据规范其次是是否符合业务规范
*
逻辑就是人类思考的过程
业务逻辑就是模仿人类思考的过程
(这种方式最好理解,也最好修改)
页面逻辑,
数据库结构,
都是电脑想问题的方式
如果想要作逻辑层
那么就要先写好业务逻辑
之后把页面逻辑与数据库语句
向这个方向凑
而不是定好数据库之后把业务向数据结构上凑
这是个想法问题作的时间长了就知道其中的区别了
平时区别不是很大的....
*举一个订单的例子，可能有点文不对题，希望能从另一个侧面加深大家对这个概念的理解：
业务逻辑是企业的行业特性、企业文化、能力结构和资源状况所形成的个性特质下对核心业务处理的基本路径和方式。那么我们的业务逻辑到底是什么呢？就是将订单信息快速全息广播到有关岗位，并行配置资源，动态调度岗位任务，让订单有序地在各个岗位间流动，最终在客户的包装物仓库形成物为载体的闭环。这个逻辑是基于流水生产、离散加工、快速交货、规格不一、需求复杂的基本事实和东经人恪守本职的基本属性作出的。
在这个业务逻辑下，订单应该是什么样的呢？订单除了基本的客户基本信息、产品基本数据和技术要求之外，还必须有工艺路线、运输方案、信用控制等方面的选择与控制，以锁定需求满足的基本路径，这样订单信息才算是丰满的，它全息了订单在公司内部流动的基本行为模式，充分表达了东经的个性。只有这样的订单才算有了基因
============================================================================================================
分层的优势是我认为在于可维护、可扩展、还有就是思路清晰。
我页面只干我显示的事情，你后面给什么我就显示什么，
你后面要什么我就显示什么
数据层只管按照指令来执行，你要我做什么就做什么，反正你要满足我的条件
哪业务层就是把数据和页面链接起来来了，具体操作权放在里面
如果在一个项目完成，用户需要添加功能或者某个功能需要修改。
我要少显示一个字段，页面调下
这个公式不对，业务层调下
这个数据来源不对，DAO调下
当然，实际比这个复杂得多
市面很多公式确实不会严格分层，他们看中的是功能实现。如果一个需求变更
哪改程序的人我觉得会一头乱嘛，这样对后期成本是很大的，什么可以说危险的
所以很多大公司一个项目都配备一个架构师呢。
============================================================================================================
我经常用于比喻MVC的例子是小时候玩的那种卡带式游戏机，
Control是主机，一般来说我买一个主机就行了，只要他不坏，他就能一直让我玩这一类的游戏。
View则是电视机和游戏手柄，电视机可以独立工作，他不管输入的是电视信号、影碟机信号还是游戏机信号，他只管显示，而且他决定了我们看到的效果是怎么样的，如果我想要个尺寸更大的或者彩色的显示效果，我只需要买个相应的电视机就行了，手柄也是可以换的，要遥杆还是带震动的。
Model则是游戏卡带，他绝定了我玩的是什么游戏，是魂斗罗还是超级玛莉，而且游戏机主机和电视机生产厂家永远也不知道在上面有可能会运行什么样的游戏。卡带中可能会有游戏代码和存储单元，都根据游戏的需要而设计。
N层结构是一种软件抽象的层次结构，是对复杂软件的一种纵向切分，每一层次中完成同一类型的操作，以便将各种代码以其完成的使命作为依据来分割，以将低软件的复杂度，提高其可维护性。一般来说，层次之间是向下依赖的，下层代码未确定其接口（契约）前，上层代码是无法开发的，下层代码接口（契约）的变化将使上层的代码一起变化。三层结构是N层结构的一种，是人产在长时间使用中得出来的一种应用场合广泛的N层结构，被当作一种典型的软件层次结构而广为流传甚至写入教科书。
============================================================================================================
首先说明，三层架构不是MVC，就我个人的了解，MVC是一种用于图形用户接口的经典设计方案，M是指模型，而非业务逻辑；
然后来解释业务逻辑，，业务逻辑层就是专门处理业务逻辑的地方，与现实中客户的具体业务有关，比如说权限验证、日志记录（这两个例子应该是所有企业级应用里都有的模块吧）。
然后再解释一下三层架构，实话实说我不认为现在书中所讲的SSH整合就是三层架构，三层架构是指要把用户接口（表示层，这一层通常使用MVC模式进行设计），业务逻辑处理以及数据库操作分离。这样做的目的主要是为了提高程序的复用性、扩展性，以及集群部署。举例来说，现在一个应用程序是为PC平台开发的，所以用户交互采用Web页面；但是今后打算应用在手持设备上，可能需要再开发一个客户端应用程序。如果采用这种分层，那么我们需要做的只是再写一个客户端应用程序就好了，而不需重写整个系统。业务逻辑层与数据库层的分离类似。
针对你说的在service里面出现HQL、SQL的情况，就我对Hibernate的理解，其实使用了Hibernate就可以认为实现了逻辑上的业务层与持久层分离，应为使用了Hibernate就意味着你的应用程序不再依赖具体的数据库，只要修改配置文件就可以适应各种数据库管理系统，Hibernate把对数据库的操作抽象成对POJO的操作。但这只是逻辑上的，因为你还不可以实现分离部署，如果要实现完全的分离，考虑将业务逻辑层与数据层加载在不同的JVM里面，使用RMI或者WebService进行交互。
============================================================================================================
MVC和业务逻辑是不同维度的问题，MVC是所有系统运行的机制的提炼，是一种模式，Controller接受请求，得到相应Model显示在View层，额，你在百科找更精确的解释，其实即使是桌面程序又何尝不需要MVC，不需要将界面和逻辑解开来？解开可以提高可维护性。
对应Javaee，就是Struts，或者更早的Model1 Model2。
MVC可以想象为人机交互的逻辑。
而业务逻辑就是具体功能对应的业务功能，因为MVC的Controller在运行时最好只起到校验、权限控制、返回数据、调用业务的作用。那下面具体逻辑做Socket编程，调用WebService，业务对象持久化、事务控制、计划调度、消息等等都需要在业务逻辑层。根据功能、依赖关系进行分层，从维护的角度，需要解耦。对应Javaee，就是Spring了。
这里就是真正的业务逻辑了。
POJO，Hibernate，这些为面向对象服务的。让针对关系数据库的面向对象编程变为现实。
ORM跟IOC、AOP、MVC糅在一起，你不糊就怪了。分开来理解，一点点进步。其实啊，过2年就无师自通了，再打开书会说什么MVC？哥不是就这么做的嘛！
编程时，你在以SSH或者其他的架构上开发为出发点，目标也是可以理解并优化架构为目标，在潜移默化中自然可以到达彼岸。
============================================================================================================
业务逻辑就是业务的规则，我觉得没必要把它想得那么神宓一样。