【问题标题】:Purpose of BAL in 3 tier architectureBAL 在 3 层架构中的用途
【发布时间】:2012-08-02 14:27:24
【问题描述】:

我是 3 层架构的新手,因为它由 UI、BAL 和 DAL 层组成。所以我在 DAL 中编写所有数据库代码,我已经在 BAL 中声明了变量,我已经将方法调用到 UI 中,但这是正确的编码方式吗?我的 BAL 在做什么?业务层的主要目的是什么?谁能解释一下,谢谢。

 //In my BAL



public class ProfileMasterBLL
{
    public int UserId { get; set; }
    public string FormFiledBy { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }

}

//在我的用户界面中

 ProfileMasterBLL pmBLL = new ProfileMasterBLL();
        pmBLL.FirstName = TextBox1.Text;
        pmBLL.LastName = TextBox2.Text;



//In my DAL 

insert() 方法

那么我该如何调用 ProfileMasterBLL.insert() ?正如我在 DAL 中所写的那样。

【问题讨论】:

  • 一个系统必须包含多少逻辑,它包含在哪里,自然取决于系统做了什么。如果您能给我们简要描述您正在创建的内容,那么对此发表评论会更容易一些。这样我们就可以提供更符合您感兴趣的上下文的答案。
  • 您的编辑不是三层架构的示例。您拥有似乎是 ADT(一种抽象数据类型)的东西,您应该为这些类型的包创建一个单独的类。然后,您可以使用该 ADT 在您的 BL 和 DAL 中传递。业务逻辑层的属性实际上不应该存在,最多应该只是调用 DAL 的简单方法。
  • 当我在谷歌搜索时,我得到了 3 层架构的不同类型的结果,每个人都有自己的实现方式,所以我真的有点困惑。如果你发现任何好的例子,请在这里发布:)

标签: c# asp.net


【解决方案1】:

业务层用作 UI 和 DAL 之间的中间人。 它用于您的应用程序将包含的任何或所有业务逻辑。例如,在会计应用程序中,您可能希望在将数据发送到数据库层之前对数据执行一些计算和检查,您可以在业务层中执行此操作。

您的 UI 可以执行以下操作:

//establish person object
//pass in some salary with it to BL
BL.CalcPay(somePerson, someSalary);

然后在你的 BL 中:

//inside of BL
//if its a CEO they are lucky, they get paid twice as much
 decimal toGive = someSalary;
if(somePerson.IsCEO)
 toGive = toGive * 2; //CEO gets paid more :(

//now call DAL
DAL.CalcPay(somePerson, toGive)

然后在你的 DAL 中:

//inside of DAL
//perform some update by calling for instance a sproc
using(SQL....)
{
}

不是最好的例子,但它应该能说明问题,很多时候你的 BL 什么都不做,只是将方法调用交给 DAL。仅仅因为它是 BL 并不意味着它必须有某种与之相关的检查。所以你最终可能会做这样的事情:

//inside UI
string s = BL.GetSomeString();

//inside BL
return DAL.GetSomeSomeString();

//inside DAL
return someString;

【讨论】:

  • 直接从 DAL 调用一个方法到 UI 合适吗?那么业务逻辑是什么意思?在那里编码是什么?
  • 不,你的用户界面不应该知道数据访问层,事实上你的用户界面不应该包含任何类型的 sql 引用,例如 sql 数据阅读器。阅读我所做的编辑,您的 UI 会向 BL 发送一些信息,BL 可能会对数据执行逻辑,然后只有在逻辑正常的情况下才会将其发送到 DAL。 DAL 对数据执行操作并将某种状态或结果提交回 BL。 BL 从 DAL 获取信息并将其传递给 UI。
  • //在我的 BAL 公共类 ProfileMasterBLL { public int UserId { get;放; } 公共字符串 FormFiledBy { 获取;放; } 公共字符串名字 { 获取;放; } 公共字符串姓氏 { 获取;放; } } //在我的 UI ProfileMasterBLL pmBLL = new ProfileMasterBLL(); pmBLL.FirstName = TextBox1.Text; pmBLL.LastName =TextBox2.Text; //在我的插入()的DAL方法中,这是正确的做法吗?
  • 我不明白你在做什么,你真的不需要实例化你的 BL 类,它是一个调用数据访问层的单一存储库,因此它应该是静态的,它会像这样调用//from ui BL.InsertUser(myUser); 不需要做 BusinessLayer bl = new BusinessLayer(); //unnecessary 它只是一个静态类。编辑您的问题并添加您的代码并使用标记,以便我们了解您的要求。
  • 当然这是三层架构的重点,每一层都是它自己的类。 UI由多个类组成,BLL是一个类(静态),DAL是一个类(也是静态的)。 ui 调用 BLL,而 BLL 又调用 DAL。 DAL 处理信息并将结果返回给 BL,BL 将其呈现给 UI。它看起来像这个 UI->BL->DAL 然后变成 DAL->BL->UI。这是一个相当简单的架构,我建议使用谷歌搜索它。
【解决方案2】:

业务层的作用是执行业务规则,例如验证您的实体,在实体上执行业务规则,在实体上执行业务功能。

通常你有两个选择。

在存储过程中实现业务逻辑

或

在业务层实现业务逻辑

【讨论】:

  • 在存储过程中实现业务逻辑是一种反模式,绝对应该避免。
  • 不,我不认为,因为在功能上下文中非常困难,即使使用延迟加载也不可能加载上下文中的所有实体
  • 你不能告诉专家数据库存储过程是一种反模式
  • 我没有说存储过程是一种反模式。我说过存储过程中的业务逻辑是一种反模式。
【解决方案3】:

业务层的存在是为了提供一个放置业务逻辑的地方。数据访问逻辑应该只对数据库进行创建、检索、更新和删除 (CRUD) 操作。表示层应该只有决定用户如何与系统交互的逻辑。

例如,如果您在 UI 中单击“添加用户”,这可能会调用业务层中的 BAL.AddUser() 方法,然后该方法会调用多个数据层方法,例如 DAL.AddUser() 以插入用户,然后 DAL.AddUserToGroup() 将新用户放入默认组中。

【讨论】:

  • 该示例可能不是最好的,因为您的 BOL 实际上可以调用 DAL.AddUser 并且您的 DAL 可以执行IF EXISTS(SELECT * FROM MyTable WHERE Login = @Login) RETURN -1 ELSE BEGIN INSERT INTO Users...RETURN @SCOPE_IDENTITY END 的效果并处理用户是否存在的检查。状态以整数的形式发回。该整数从 DAL 传递到 BOL,然后 BOL 将其返回给 UI,然后 UI 可以抛出一条消息。
  • @rs_atl 是的,但是我的 BAL 在做什么?直接从 DAL 调用一个方法到 UI 好不好?我有些困惑......
  • @Chandrasekhar - 不,您不从 DAL 调用 UI,它们彼此不关心,从 DAL 调用 UI 没有意义。
  • @JonH 当然可以。我只是想说明一个业务层调用可能会调用多个数据层方法——甚至是其他业务层方法。您的陈述还对底层数据库进行了很多假设。
  • @rs_atl - 数据库供应商无关紧要,他们都有我发布的某种形式。
猜你喜欢
  • 2012-08-26
  • 2011-07-30
  • 2011-09-30
  • 2010-12-09
  • 2012-11-13
  • 1970-01-01
  • 2012-07-21
  • 2011-02-06
  • 2019-03-07
相关资源
最近更新 更多