问个很低级的问题，业务层的作用是什么，可不可以不用

modishizhe 2013-02-20 03:42:56

百度上看了下，结合自己的了解，感觉完全可以通过表现层直接调用数据层代码来完成增删改查，望大神简单解释下。。。谢谢

...全文

811 22 打赏收藏转发到动态举报

写回复

用AI写文章

22 条回复

切换为时间正序

请发表友善的回复…

发表回复

showjim 2013-02-26

打赏
举报

有业务模型吗？没有的话，哪来的什么业务层？

modishizhe 2013-02-26

打赏
举报

非常感谢，我需要好好消化一下，

风吹腚腚凉 2013-02-21

打赏
举报

前一阵子我在某公司工作的时候，就发生类似的事情，我很腼腆的辞职了，太糟糕了，他们使用的方式就是楼主你的理解，并且在同一个业务中处理大量的增删改不使用事务，这是多么的可怕～

风吹腚腚凉 2013-02-21

打赏
举报

引用 7 楼 modishizhe 的回复:

好的，感觉对编码的认识又有点变化，谢谢楼上的！！！

哥给你最简单的理解前台调用业务逻辑层，那么业务逻辑层到底是干嘛的？ OK我举个例子你需要做一个删除的操作，你需要删除一个用户，并且同时删除他的一些交易信息，这个时候就涉及到了2个SQL语句，你在业务逻辑层创建一个事务，并且把这2个对数据库的操作都放进去，说白了就是调用2个数据访问层的方法。这样就能接触你方法与方法之间的耦合，或许我举的例子并不是很恰当，因为一旦删除用户就必须要删除他的一些交易记录也是有可能的，一旦牵扯到必须你完全可以把2个删除放在一个数据访问层的方法里处理，我说的情况就是，不是必须的情况下。你的代码应该如何去写。就是在数据访问层写2个方法，一个删用户，一个删用户交易的方法在业务逻辑层用事务控制，并且调用，不要把SqlConn对象创建在数据访问层，而应该是业务逻辑层。

我自横刀香甜笑 2013-02-21

打赏
举报

分层就是为了理解起来简单。增加可读性。。。你要不分开那也可以啊。那么结构就不清楚。理解起来就难点。

theillusion 2013-02-21

打赏
举报

画人像一定要画五官，如果因此理解为画人像就是拼凑五官，那么画出来的很可能是比例失调的怪胎。业务层是刻画业务的地方，如果没有业务层： 1，UI上有很多繁重的编程工作，如果同时实现业务规则，则 UI 编程工作难以进行 2，对于 bs 或 cs，业务逻辑驻留在UI里是不可靠的 3，UI和业务的变化速度是不同的，实践当中会经常遇到调整UI而业务层不变的情况 4，业务层与UI混合不利于理解，不利于自动化测试 5，UI里的业务是散落各处的，很快就会重复

threenewbee 2013-02-21

打赏
举报

引用 1 楼 wddw1986 的回复:

任何东西，如果你觉得没用，那就可以没有，因为事情是你来做。

这个回答就是我想说的。用一句格言来说就是，“若无必要，勿增实体”。

qldsrx 2013-02-21

打赏
举报

大项目必须分层，但是分几层得看有多少人，就好比CPU有多少核心就开多少线程，线程开多了，核心数不够多的话，反而会增加切换CPU时间的开销，降低效率，分层也是，分了层就必须每个层交给不同的人去做，如果是小单位，或者就一个人编码，那就别分层了，反正从头到尾都是你在写，没别人。

风吹腚腚凉 2013-02-21

打赏
举报

引用 19 楼 chenandczh 的回复:

又一个被MVC迫害的孩子...

三层跟MVC还不是一个东西吧？

绿领巾童鞋 2013-02-21

打赏
举报

又一个被MVC迫害的孩子...

以专业开发人员为伍 2013-02-21

打赏
举报

不管你使用一个产品的实际中前端程序中的哪一个 --> 不管你使用一个产品的十几种前端程序中的哪一个

专注or全面 2013-02-21

打赏
举报

引用 16 楼 wjfwd2010 的回复:

引用 7 楼 modishizhe 的回复:好的，感觉对编码的认识又有点变化，谢谢楼上的！！！哥给你最简单的理解前台调用业务逻辑层，那么业务逻辑层到底是干嘛的？ OK我举个例子你需要做一个删除的操作，你需要删除一个用户，并且同时删除他的一些交易信息，这个时候就涉及到了2个SQL语句，你在业务逻辑层创建一个事务，并且把这2个对数据库的操作都放进去，……

这种理解个人感觉是没问题的，现实是还有N多人就为了三层而三层，BLL纯粹摆设全部调用DAL，也不知道三层的啥?

以专业开发人员为伍 2013-02-21

打赏
举报

引用 3 楼 modishizhe 的回复:

看的是单位的项目，比较大，而且需要后期维护等工作

这是很基本的概念。设计有多种视角，一个产品必须从多个角度、层面实现其设计，最终才能“立体”起来。而业务层设计是很基础的一种。比如说“会计凭证过账到总分类帐中”这个业务逻辑处理，不管你使用一个产品的实际中前端程序中的哪一个、数据库的那一种等等，都要调用同一个核心服务，因此就出现了一个独立的业务服务层。因此一个系统可能除了先要独立地设计好十几个交互界面，还要设计好几十个核心业务服务，才敢看是动手开发。而这两层其实是并行开发、交替深入地。业务层需要专人设计和开发。而不是“把界面简单分工一下就扔给个人去编写”。比如说你去当小工给人家用砖头砌墙，人家要给每一层砖先拉一根准绳然后你就比较容易把墙砌直了。你却说“我是新手，请让我随便起砖头吧，等我把墙砌歪了您再来教我吧”，那么你的工头肯定说“好吧，你从哪来回哪去吧，我们要保证整个工程的进度和质量啊”。工头之所以采取最基本、最初步的三层次架构，就是这个目的。

zhoujk 2013-02-20

打赏
举报

刚开始时什么都别用，就简单地写自己的代码就行了。直到有一天，代码的修改、复用让你头大的时候，再来考虑如果归纳这些代码。这时才需要考虑你说的问题

modishizhe 2013-02-20

打赏
举报

好的，感觉对编码的认识又有点变化，谢谢楼上的！！！

stonespace 2013-02-20

打赏
举报

如果你的业务逻辑不算复杂，那么让业务逻辑在界面实现也是可以的，但通常业务逻辑代码太多的话，会把界面弄得太乱，最好独立出来作为一些类，

catchdream 2013-02-20

打赏
举报

引用楼主 modishizhe 的回复:

百度上看了下，结合自己的了解，感觉完全可以通过表现层直接调用数据层代码来完成增删改查，望大神简单解释下。。。谢谢

如果你项目里只有简单的从数据库读出数据显示，或者向数据库添加记录或者修改记录，你可以暂时不设计业务，不过最好的办法是设计空的接口出来。业务层主要是为了项目扩暂或者复用。比如你修改一个人的用户信息，最开始可能就直接修改就好了；后面公司要求你还需要同时给邮箱发信息；在后面又要求你把这个过程给别人审批。。。。这些情况，你不需要修改你的显示层和数据访问层，只需要扩展业务层就可以。