我对三层架构的 BLL 层理解有些模糊,我想问一下:BLL 主要是业务处理,他所谓的业务是指针对数据库查询出来的东西吗?比如:要做一个登陆,登陆前,会判断用户输入是否有误,那么这个判断是属于业务吗?这个判断应该写在UI 还是 BLL层?在一个比如当项目需要用到复杂的SOCKET,这个时候我们需要将SOCKET的方法其提取到一个类中,SOCKET类的方法主要是对一些命令的处理和进行相应的操作,请问,这个SOCKET类的方法属于业务吗?应该放在BLL 还是 UI 还是?
再比如,有时候我们可以 需要创建一些临时用的实体,这些临时用的实体有时候只是UI层用,并不需要连接数据库的,请问这些不连接数据库的实体也要放到实体层吗 ?在一个,项目中用到了复杂的API函数,提取了一个类,这些复杂的API是对UI进行相应的判断和处理的,请问这个类是属于业务还是UI?我的主要问题是 三层架构中,所谓的层,这些是不是只是针对数据库?如果不是针对数据库的东西放到common或者UI 吗?我上面举得例子都是不走数据库的。 BLL所谓的业务处理是指对数据库查出来的数据做相应的业务处理吗 ? 麻烦大家帮我解个这个误区 谢谢。
再比如,有时候我们可以 需要创建一些临时用的实体,这些临时用的实体有时候只是UI层用,并不需要连接数据库的,请问这些不连接数据库的实体也要放到实体层吗 ?在一个,项目中用到了复杂的API函数,提取了一个类,这些复杂的API是对UI进行相应的判断和处理的,请问这个类是属于业务还是UI?我的主要问题是 三层架构中,所谓的层,这些是不是只是针对数据库?如果不是针对数据库的东西放到common或者UI 吗?我上面举得例子都是不走数据库的。 BLL所谓的业务处理是指对数据库查出来的数据做相应的业务处理吗 ? 麻烦大家帮我解个这个误区 谢谢。
针对数据库的有DAL层,DAL才是主要跟数据库之间进行交互的。
BLL 业务层,不需要考虑SQL语句应该怎么写,一般作为DAL的扩展。
DAL 代码Demo
/// <summary>
/// 获得数据列表
/// </summary>
public DataSet GetList(string strWhere)
{
StringBuilder strSql = new StringBuilder();
strSql.Append("SELECT * FROM [TB_NOTE]");
if (strWhere.Trim() != "")
{
strSql.Append(" where " + strWhere);
}
strSql.Append(" order by [TB_NOTE_ROW_NUM]");
return DbHelperSQL.Query(strSql.ToString());
}BLL 代码Demo /// <summary>
/// 获得数据列表
/// </summary>
public DataSet GetID1(string strWhere)
{
return dal.GetList(" [_ID]='1'");
}
/// <summary>
/// 获得数据列表
/// </summary>
public DataSet GetID2(string strWhere)
{
return dal.GetList(" [_ID]='2'");
} /// <summary>
/// 获得数据列表
/// </summary>
public DataSet GetAllList()
{
return GetList("");
}
在比如说用户想要更换数据库SQL Server->Mysql
只需要重写DAL就OK了,BLL是不用变的。
1.要做一个登陆,登陆前,会判断用户输入是否有误,那么这个判断是属于业务吗?这个判断应该写在UI 还是 BLL层?
回答:这个是UI层的东西,但是不表示业务层就不检查。UI层很可能混入其他判定,比如验证吗,所以他的判定本来就不在bll里,但是如果你ui的验证通过,传入bil的方法,根据防御性编码规则,bil也是同样要检查输入项滴,这里检查输入项的目的不是为了UI上的规则,这里的目的是保证输入项边界不引起异常2.在一个比如当项目需要用到复杂的SOCKET,这个时候我们需要将SOCKET的方法其提取到一个类中,SOCKET类的方法主要是对一些命令的处理和进行相应的操作,请问,这个SOCKET类的方法属于业务吗?应该放在BLL 还是 UI 还是?回答:这属于UI,也不是属于BIL。他属于提供provide。因为真正的设计者其实不关心用什么传输,用什么保存。对于这个设计者只会设计成接口方式,至于你用什么东西传输俺们不关心,你提供什么样的provide,俺们就用什么样的方式传输3 有时候我们可以 需要创建一些临时用的实体,这些临时用的实体有时候只是UI层用,并不需要连接数据库的,请问这些不连接数据库的实体也要放到实体层吗 ?回答:不需要放入实体层。已经是和具体情况关联的东西,已经属于具体事物,他当然是具体问题具体对待,比如微软mvvm里的viewmodel,他就是一个和UI关联的对象,他自然只和使用他的UI关联,而不是和什么实体关联
ps:区别方式其实很简单,属于抽象逻辑的是一层,属于具体场景的又是一层
10#的 说得很大白话,dal也是处理逻辑的,只要不涉及到数据库操作的,都放到bll层.
相当于是对dal一个扩展.