初学者，三层架构的简单问题 请大家帮忙解答
我对三层架构的 BLL 层理解有些模糊,我想问一下：

BLL 主要是业务处理，他所谓的业务是指针对数据库查询出来的东西吗？

比如：要做一个登陆，登陆前，会判断用户输入是否有误，那么这个判断是属于业务吗？这个判断应该写在UI 还是 BLL层？

在一个比如当项目需要用到复杂的SOCKET，这个时候我们需要将SOCKET的方法其提取到一个类中，SOCKET类的方法主要是对一些命令的处理和进行相应的操作，请问，这个SOCKET类的方法属于业务吗？应该放在BLL 还是 UI 还是？


再比如，有时候我们可以 需要创建一些临时用的实体，这些临时用的实体有时候只是UI层用，并不需要连接数据库的，请问这些不连接数据库的实体也要放到实体层吗 ？

在一个，项目中用到了复杂的API函数，提取了一个类，这些复杂的API是对UI进行相应的判断和处理的，请问这个类是属于业务还是UI？

我的主要问题是 三层架构中，所谓的层，这些是不是只是针对数据库？如果不是针对数据库的东西放到common或者UI 吗？我上面举得例子都是不走数据库的。 BLL所谓的业务处理是指对数据库查出来的数据做相应的业务处理吗 ？ 麻烦大家帮我解个这个误区 谢谢。
[解决办法]
bll不是只跟数据库打交道，这不是必要的，它是处理 业务层面的需求的，socket是通信的，这个要看你具体需求了，放在哪并没有什么固定
[解决办法]
业务层主要处理业务上的逻辑判断。
针对数据库的有DAL层，DAL才是主要跟数据库之间进行交互的。
[解决办法]
不要太过找太过明确的划分。只把他理解成需要逻辑处理的层就行了
[解决办法]

引用:

那临时的实体呢 是不是放到要用的那个层下面最好？

实体类不必放在某一层下，他可以单独放在三层之外……
[解决办法]
放哪都行，据情况而定。

一般登录验证方法放BLL层，与数据库的操作放DAL层。
[解决办法]
SOCKET类 就放在 xxxx.Net下就行了他跟业务没关系
[解决办法]
DAL 数据访问层 一般写SQL语句操作数据库
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是不用变的。
[解决办法]
不必强求，这玩意的划分标准从来就没统一过，哪怕是已经貌似统一的java们，在各种O之间也同样存在争议

不必固定死了，基本素材在那里。你怎么组合都可以。

这东西取决与你怎么去看问题的方式。如果你是整体建模，那么可能就是充血模型，如果分散建模，那么他就是贫血模型，如果你专注与对外接口提供那么可能就是sop

但是我个人说木必要弄清楚，因为他们都是可以互相转换滴。谁说充血模型的东西，不能在外面套一个sop对外提供？又谁说分散的mvc贫血方式，不能根据需要合并出一个充血的对象？？

对于你的具体问题：
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：区别方式其实很简单，属于抽象逻辑的是一层，属于具体场景的又是一层




[解决办法]
层的概念只是帮助你更好的理解和维护，不要太过于纠结它所代表的含义了，BLL只是我们一种业务逻辑处理的统称而已，它还是可以包含多各子层，如果你确定需要的情况下