什么是业务逻辑?
在网上看了许多资料,JavaEE三层架构MVC，把视图控制器模型分开来。
那么在这里业务逻辑就应该是M。
但是什么样的算是业务逻辑如：上传一个文件，上传代码算是一个业务逻辑吗？
数据库操作增加时需要判断，和一些其它这算业务逻辑吗？（我觉得算）
但是hibernate又提供了一个离线查询对象（DetachedCriter），提供这个接口的意思我想是在外面处理业务逻辑。
但是三层架构不是独立的吗？互相不干涉吗？在service层出现sql，hql，criter不是又把dao与service连在一起了吗？
DTO（VO），POJO，BO这些是什么，POJO对应数据库，BO对应业务逻辑，DTO对应页面的传输与显示。

什么三层，什么对象，人都被搞晕了，完全一踢糊涂，忘高手能解答。

------解决方案--------------------
业务逻辑就是处理数据的逻辑啦。一般后台代码也分三层 action(controller) service DAO （这里的三层不是MVC）

比如 我得到用户名 但是在存入数据库的时候 用户名字段应该是前台的用户名加上当前日期拼成的字符串
action或者controller层是第一层 一般是用来及接受数据并且做数据的非空啊 格式是否正确的验证
如用户名是否为空 是不是安全字符串之类的
service层一般是用来做一个业务逻辑的实现
这时候 userName = userName + new Date();

DAO层 就是与数据库交互层啦
也就是读写数据库 将逻辑层得到的新的userName插入到数据库
------解决方案--------------------
首先LZ先把MVC的作用和思想理解好了

你说的那些XO、XO、XO…………以后你就会明白，现在先忽略

到业务逻辑，这个。。。。。。学学UML，你就能大概明白了，不过前提是你得把MVC搞清楚了
------解决方案--------------------
其实分层是很好的。

但就是 在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已死

用郭德纲说过的一句话形容
“现在‘黄鹤楼’、‘报菜名’还能让观众笑的前仰后合的...”，呵呵

我经验不多，欢迎大家指正

个人观点，欢迎拍砖

------解决方案--------------------
业务，就是business，就是一个单元（个人，组织等）给另一个单元提供的服务。逻辑（logic）就是指人们思考问题，从某些已知条件出发推出合理的结论的规律。所以逻辑不可能离开业务，这个逻辑也就是常说的业务逻辑（business logic），它是用来管理业务功能的一系列guildlines。你看到的
 
里的业务应该是如richard所说的业务实体（business entities），是一种简化的说法；逻辑也是业务逻辑的简化。

*业务逻辑是你在分析阶段对你的软件的应用领域进行分析总结出来的，它存在不依赖于你的软件的存在，相反，它先于你的软件存在并限制了你的软件应有的行为。

凡是业务逻辑都应该放到中间层，不能让客户端去决定。有时为了减少网络访问次数，在客户端会有一此与业务逻辑有关的检验，但在中间层这一检验同样不能省略。比如上面说的日期的判断，客户端可以有也可以没有判断，但中间层一定要有这一判断。

* 举个例子讲 日期字段 在数据库逻辑或者说是数据层仅仅需要判断他是不是日期类型的
但对于业务逻辑来讲仅仅输入一个日期是不够的，比如销售订单的执行日期就不能比销售订单的制定日期早；所以判断用户输入是否正确实际上 就是两方面：首先看他是否符合数据规范其次是是否符合业务规范

*
逻辑就是人类思考的过程

业务逻辑就是模仿人类思考的过程
(这种方式最好理解,也最好修改)

页面逻辑,
数据库结构,
都是电脑想问题的方式
如果想要作逻辑层
那么就要先写好业务逻辑
之后把页面逻辑与数据库语句
向这个方向凑

而不是定好数据库之后把业务向数据结构上凑

这是个想法问题作的时间长了就知道其中的区别了
平时区别不是很大的....

*举一个订单的例子，可能有点文不对题，希望能从另一个侧面加深大家对这个概念的理解：
业务逻辑是企业的行业特性、企业文化、能力结构和资源状况所形成的个性特质下对核心业务处理的基本路径和方式。那么我们的业务逻辑到底是什么呢？就是将订单信息快速全息广播到有关岗位，并行配置资源，动态调度岗位任务，让订单有序地在各个岗位间流动，最终在客户的包装物仓库形成物为载体的闭环。这个逻辑是基于流水生产、离散加工、快速交货、规格不一、需求复杂的基本事实和东经人恪守本职的基本属性作出的。

在这个业务逻辑下，订单应该是什么样的呢？订单除了基本的客户基本信息、产品基本数据和技术要求之外，还必须有工艺路线、运输方案、信用控制等方面的选择与控制，以锁定需求满足的基本路径，这样订单信息才算是丰满的，它全息了订单在公司内部流动的基本行为模式，充分表达了东经的个性。只有这样的订单才算有了基因