Web项目架构设计-商业逻辑层

文章写的比较简单，主题是交流。

1.1       商业逻辑层

该层我更喜欢把她称之为业务逻辑层。

商业逻辑层是整个系统最核心的一层，它最关注的是业务规则的制定、实现、系统设计。是整个业务系统的最重要的支撑部分。它的职责更多的是关注业务规则的定义。所以该层的具体实现需要有业务专家参与。当然系统设计人员具有较高的业务专业知识也能够达到相同的效果。

在本文档中，因为不涉及具体系统的业务逻辑，我只能够把我的一些经验和教训写出来。但这样也使得系统的业务逻辑层具体设计就失去了很多意义。在后续系列文章中将会结合实际项目对系统架构进行详细分析。

最大可能的遵循分层设计原则

Ø         别混淆了层之间调用关系

Ø         搞清楚各层的职责

Ø         别轻易去掉逻辑层

在使用分层设计的系统中，下层不应使用上层提供的功能服务，下层也不应该引用上层。这一点不用去怀疑，除非你愿意让你的设计在后期出现更加混乱的局面。

业务层需要引用数据访问层，把业务层需要与数据进行交互时，把该任务交给数据访问层去完成。不要在业务层中出现SQL语句，哪怕是标准的SQL语句，更不要让SQL语句四处蔓延！业务层中如果逻辑很简单，将会出现业务层只是直接调用了数据层的简单接口，而没有什么逻辑，看上去业务层就只是一个”传话筒”。这时我们可能会认为完全可以取消该层，让UI直接去调用数据层接口。这时，我们应该要非常注意，这样做其实是非常危险的做法。

业务层与数据层之间通信，两层之间的依赖一定要弱依赖关系。在业务层引用数据层的接口集，不依赖它的具体实现。不需要关心数据层具体是使用哪种数据库及其数据访问方式。只要他们的接口没有发生改变就不影响业务逻辑层的工作。依赖接口也是弱依赖的一种有效途径。详见架构设计图。商业逻辑层引用关系图

在本图说明业务逻辑层的调用关系。只有对User的处理。

代码如下：

 

using System;

using DesignDemo.IDataAccessLay;

using DesignDemo.Model;

using DesignDemo.DataAccessFactory;

namespace DesignDemo.BusinessLogicLayer

{

    public class User

    {

        public void Insert(UserInfor UserInfor)

        {

            //其他逻辑关系

            //……

            IUser oIUser = (IUser) ServiceLocator.LocateDALObject("UserInfor");

            oIUser.Insert(UserInfor);

            //其他逻辑关系

            //……

        }

    }

}

通过这里面的代码，我们可以很清楚的看到

Ø         业务逻辑层中是依赖于数据层接口，而没有依赖于数据层的具体实现。

Ø         通过数据层提供的一个工厂来创建具体的对象。

Ø         在业务层中处理他的具体业务逻辑。

但是，我们现在看见的只是业务层中最简单的一些设计。其实，在业务层中还会遇到很多的问题。比如：业务之间调用时事务的处理、业务对象包含子数据时，他们怎么加载，在什么时候加载等问题。将在后续文章中贴出我的思考。

相关文章
Web项目架构设计-概述