三层架构中的业务层

Question

三层架构中的业务层

n-tier-architecture3-tierbusiness-logic-layer

16

我去参加了一次面试，并被要求展示我的业务层架构。我对三层架构有一些概念，但真的不知道在面试官面前应该写什么。假设我的项目涉及组织中的员工，则我应该在那里写些什么。我使用的是C#框架3.5。我真的不明白这个问题还需要提到什么，所以如果需要其他信息，请告诉我。谢谢。

编辑我使用的是winforms。我知道业务层是什么，但不确定应该告诉面试官什么，因为业务层包含代码，而且我的项目比较大，所以有很多代码。那我应该在那里写些什么呢？

- Sandy

问题只是“展示你的业务层架构”吗？没有上下文吗？他是否明确要求您使用三层架构？如果在没有上下文的情况下问到这个问题，您应该回答说您有不同的架构适用于不同的场景。 - Darin Dimitrov

1

面试结束了吗？还是会有第二轮呢？ :-) - Davide Piras

@Darin：他让我展示三层架构。 - Sandy

@Davide：很遗憾，它结束了 :-( - Sandy

5个回答

1

业务逻辑被定义为与应用数据的检索、处理、转换和管理有关的任何应用程序逻辑；业务规则和政策的应用；以及确保数据一致性和有效性。为了最大化重用机会，业务逻辑组件不应包含任何特定于用例或用户故事的行为或应用程序逻辑。业务逻辑可以进一步细分为以下两个类别：

业务工作流程。在UI组件收集用户所需数据并将其传递给业务层之后，应用程序可以使用这些数据执行业务流程。许多业务流程涉及必须按正确顺序执行的多个步骤，并且可能通过编排相互交互。业务工作流程定义和协调长时间运行的多步业务流程，并可使用业务流程管理工具实现。它们与实例化并在工作流组件上执行操作的业务流程组件一起工作。
业务实体。业务实体实体或更普遍地说业务对象，封装了表示应用程序中的真实世界元素（例如客户或订单）所需的业务逻辑和数据。它们存储数据值并通过属性公开它们；包含和管理应用程序使用的业务数据；并向业务数据和相关功能提供有状态的编程访问。业务实体还验证实体中包含的数据并封装业务逻辑以确保一致性并实施业务规则和行为。

- t.khan

0

3层架构如下：

您的演示在一层中。
您的应用程序逻辑在另一层中 - 称为业务层。
您的数据访问类在第三层中 - 称为数据层。

Webforms将成为表示层，因此对于员工类，在ASP.Net代码后台文件中执行任何操作都可以被视为业务层，因为您正在使用if / else等应用业务规则。 App_Code文件夹中的数据访问类将成为数据层。

对于桌面应用程序，表单设计将成为表示层，表单代码将成为业务层，与访问数据库相关的任何内容都将成为数据层。

- Adnan Bhatti

0

业务层负责所有业务逻辑。例如，您有一个组织机构和员工集合。在员工对象中需要实现一些限制或规则。这些规则将在此层中实现。

- Gregory Nozik

我投了反对票，抱歉。我认为这个答案没有提供足够的信息。请再详细解释一下。可以给一些例子吗？ - jakubiszon

0

3层架构是一种软件架构类型，由三个逻辑计算“层”或“层次”组成。它们通常作为特定类型的客户端-服务器系统在应用程序中使用。3层架构通过模块化用户界面、业务逻辑和数据存储层为生产和开发环境提供了许多好处。

业务逻辑层：业务逻辑是管理终端用户界面和数据库之间通信的编程。业务逻辑的主要组成部分是业务规则和工作流程。

业务逻辑层（BLL）作为呈现层和DAL之间数据交换的中介。在实际应用程序中，BLL应该作为一个单独的类库项目在App_Code文件夹中实现，以简化项目结构。下面说明了呈现层、BLL和DAL之间的架构关系。

BLL将呈现层与数据访问层分离，并强制执行业务规则

- t.khan

你所描述的“业务逻辑层”似乎需要理解表示层以便管理与其之间的通信。 “业务逻辑层”应该对客户端应用程序（Web、桌面、移动）保持中立，并定义这些应用程序可以如何与其交互的方式。 - jakubiszon

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- balexandre · Accepted Answer

一个三层架构由三个主要层组成：

PL 表示层（Presentation Layer）
BLL 业务逻辑层（Business Logic Layer）
DAL 数据访问层（Data Access Layer）

每个顶层仅向下一层提出请求，从不查看在其上方的任何内容。

当有人问你如何构建你的BLL时，你可以这样写：

namespace Company.BLL
{
  // let's create an interface so it's easy to create other BLL's if needed
  public interface ICompanyBLL
  {
      public int Save(Order order, UserPermissions user);
  }

  public class Orders : ICompanyBLL
  {
    // Dependency Injection so you can use any kind of BLL 
    //   based in a workflow for example
    private Company.DAL db;
    public Orders(Company.DAL dalObject)
    {
      this.db = dalObject;
    }

    // As this is a Business Layer, here is where you check for user rights 
    //   to perform actions before you access the DAL
    public int Save(Order order, UserPermissions user)
    {
        if(user.HasPermissionSaveOrders)
            return db.Orders.Save(order);
        else
            return -1;
    }
  }
}

以下是我正在创建的项目的实时示例：

enter image description here

PL 表示所有公开的服务，我的 DAL 处理所有对数据库的访问，我有一个 Service Layer 来处理 2 个版本的服务，一个旧的 ASMX 和一个新的 WCF 服务，它们通过一个 Interface 公开，所以我可以轻松地选择用户将使用哪个服务。

public class MainController : Controller
{
    public IServiceRepository service;

    protected override void Initialize(System.Web.Routing.RequestContext requestContext)
    {
        ...

        if (thisUser.currentConnection.ws_version == 6)
            // Use old ASMX Web Service
            service = new WebServiceRepository6(url, ws_usr, ws_pwd);

        else if (thisUser.currentConnection.ws_version == 7)
            // Use the brand new WCF Service
            service = new WebServiceRepository7(url, ws_usr, ws_pwd);

        ...

    }
}

在上面的代码中，我简单地使用依赖注入来分离其他层的知识，因为在这一层（即演示层，作为MVC项目中的控制器），它不应该关心如何调用服务以及用户是否使用 ServiceA 而不是 ServiceB ... 它需要知道的是调用 IService.ListAllProjects() 将提供正确的结果。

你开始划分目的，如果服务连接出现问题，你知道这与演示层无关，而是服务层（在我的情况下）并且很容易修复，并且可以轻松部署一个新的 service.dll 而无需重新发布整个网站...

我还有一个助手，它保存了我在所有项目中使用的所有业务对象。

希望这有所帮助。