为什么要有业务逻辑层？？我直接调用数据访问层不就得了吗？

Question

从两个方面考虑：性能和安全会不会受影响？
感觉业务逻辑层很麻烦，觉得没必要，我向来做项目都是只写数据访问层。虽然老师让我们写它，但他有时候也不写业务逻辑层
如果不写 性能 和 安全 受什么样的影响？安全性能三层业务逻辑层

Answer 1

分层的目的是就是松耦合高内聚，维护起来也方便。
你们现在做的没多少业务逻辑要处理，所以你觉得没用，但是在你工作了以后遇到的有些大项目必须得有业务逻辑层，因为有好多业务方面的算法等等要处理，比如说我业务逻辑层的算法有问题了，我就没必要去动表现层和数据访问层，我只需要把业务逻辑层修改好了打包替换以前的dll就可以了，这样就不影响以前发布的。
你如果只写两层（表现层，数据访问层）也可以，有些项目的业务逻辑没多少所以就直接两层，比如我们现在做的ERP，它把业务逻辑处理都放到了存储过程里，我当时也做过一个大型的电子商务网站，它的业务逻辑层里面几乎没啥东西就起了个桥梁作用。我做的大项目不是很多，所以道行浅，不能给你说出一些实质性的问题，所以我觉得需不需要就要根据项目的实际情况了。

Answer 2

我不太清楚你所谓的业务逻辑层具体是指什么样的设计思想。但是有很多所谓的BLL是对DAL简单的封装，那个东西根本没有必要写。这个时候，等于根本没有搞清楚如何设计业务逻辑层，此时就算是有个叫做BLL的一大堆代码那么其实也没有分层所带来的那种灵活性。

Answer 3

我不太清楚你所谓的业务逻辑层具体是指什么样的设计思想。但是有很多所谓的BLL是对DAL简单的封装，那个东西根本没有必要写。这个时候，等于根本没有搞清楚如何设计业务逻辑层，此时就算是有个叫做BLL的一大堆代码那么其实也没有分层所带来的那种灵活性。
对啊，我看他们写的代码，业务逻辑层里的代码就是调用了一下数据访问层，在就什么都没有，感觉毫无意义

Answer 4

yaoxi，我要做项目也不大，既然安全和性能没问题那就不写了吧

Answer 5

public static class HomeSearchManager
    {
        /// <summary>
        /// 根据姓名查询员工信息
        /// </summary>
        /// <param name="name"></param>
        /// <returns></returns>
        public static List<InCommunication> GetInCommunicationByName(string name)
        {
            return HomeSearchService.GetInCommunicationByName(name);
        }        /// <summary>
        /// 根据部门查询员工信息
        /// </summary>
        /// <param name="department"></param>
        /// <returns></returns>
        public static List<InCommunication> GetInCommunicationByDepartment(string department)
        {
            return HomeSearchService.GetInCommunicationByDepartment(department);
        }        /// <summary>
        /// 根据职务查询员工信息
        /// </summary>
        /// <param name="department"></param>
        /// <returns></returns>
        public static List<InCommunication> GetInCommunicationByDuty(string duty)
        {
            return HomeSearchService.GetInCommunicationByDuty(duty);
        }
    }
就是这种东西bLL