关于三层方式，逻辑层所有东西都要写在BLL里边？

比如提交过来

public ActionResult Test(FormCollection form)
{
 BLL.AddItem(form);
 return View();
}

#BLL project

public class BLL
{
public bool AddItem(FormCollection form)
{
              if( form["xxx"] == "")
              {
                   .......
                    return false;
              }
}

}

在ACTION连 if else 这些基本判断都不可以有吗？

一定要全部交给BLL吗？

连判断个表单域中某个数据也是这样？

14 个解决方案

#1

对asp.net MVC懒得说它了。

我告诉你一个原则，通常所谓三层中的BLL，丝毫也不针对UI中才私有的东西进行操作。

#2

从你的代码可以看出，这个程序员除了这个什么asp.net mcv啥也不会了。他设计的所谓BLL，就是他个人用的BLL。

#3

引用 2 楼 sp1234 的回复:

从你的代码可以看出，这个程序员除了这个什么asp.net mcv啥也不会了。他设计的所谓BLL，就是他个人用的BLL。

那怎么设计呢？

#4

引用 1 楼 sp1234 的回复:

对asp.net MVC懒得说它了。

我告诉你一个原则，通常所谓三层中的BLL，丝毫也不针对UI中才私有的东西进行操作。

这个怎么说呢，UI私有的东西。

表单提交的数据是UI私有么？

#5

上面说过了，这根本不需要技术。用心看。

#6

还“表单提交的东西”！你的BLL依赖什么UI组件不知道么？

#7

引用 6 楼 sp1234 的回复:

还“表单提交的东西”！你的BLL依赖什么UI组件不知道么？

UI放过来的数据呀。表单不是数据？

#8

啥是三层？BLL是什么层？

啥是面向对象？

表单是数据，只是你传的方面有点~~~

#9

引用 8 楼 bidisty 的回复:

啥是三层？BLL是什么层？

啥是面向对象？

表单是数据，只是你传的方面有点~~~

呀，那该如何，不太懂

指点一下

#10

我没有书上说的好，只回答问题，不搞教学。

#11

引用 10 楼 bidisty 的回复:

我没有书上说的好，只回答问题，不搞教学。

业务逻辑层

那不是要有逻辑了？  提交过来的空或者不合规格不是在BLL中，整个表单都给逻辑层那边处理不是吗

#12

三层架构就个那个数据库范式一样，照着做只能保证不出什么大问题，
但是实际生产中，没人关心你是什么架构。
买家只关心这个东西是不是和提出的需求一样，是不是安全，高效。
你需要关心是是不是能满足买家的需求，如何才能快速的完成开发，如何在买家提出变化的时候快速调整。

#13

这样说吧，业务逻辑层处理的事务是和客户端无关的。
比如：你这里用的是asp.net的表单，也可能有个web service接口调用它！

#14

其他不管你分几层，业务逻辑都是需要的，但一些人为了分层而分层就没有什么意义了，我看到过一些代码生成器或者一些人的项目就是分层而分层，类似如下：

 1、UI层:
    class page
     {        
          emp empInfo = new empInfo();
        //取得表单数据
          empBLL bll= new empBLL();
        bll.Add(empInfo);        
     } 
 2、BLl层:
    class empBLL
     {
        public void Add(emp empInfo)
         {
           empDAL dal=new empDAL();
           dal.Add(empInfo);
         }

     }
 3、DAL层：
    class empDAL
     {
         public void Add(emp empInfo)
         {
           string  sql = "INSERT ......";
           ......
         }
      }  

也就是说只是一层调用一层，没有任何实际的业务意义，可能有一些人说好维护，好扩展；而整个项目都是如此，这样的逻辑层有何意义？如果是这样，何不在UI直接调用DAL或者写一个强大一些的DbHelp，就连数据层都不需要。

实际上分层是把不同处理功能或处理方式分工，让程序有清楚的工作。
1、UI层，就是数据收集和展示，但为了有更好的用户体验，通常在收集的时候就需要向用户即时提示相关验证信息或权限信息（如不能为空、已重复、没有权限等，权限有的在用户登陆后就直接不显示无权操作的相关按钮或动作），而不是让用户在搞了半天，提交时才提示不能操作或无权操作。

2、BLL层：业务逻辑的处理与验证，相关性的登记处理，启动相关流程，最后才调用数据层进行存储；
   （1）、即使UI的数据有无验证，在逻辑都必须处理这些验证；如数据关联性验证、引用验证、有效性验证、权限验证等，总而言之，即使跳过UI，也能确保数据的有效性。
   （2）、强制处量：有一些表单需要制单人、制单时间等信息，不会用UI提交的数据，而是必须强制从当前会话用户中获取并强制引用或覆盖；
   （3）、强制关系：如销售单的金额，必须是由单价与数量两者相乘，而非从表单中获取。
   （4）、制约关系：处理一些关系单据，如生成凭证，与之对应的单据必须审核才能提取，提取后对应的单据不能反审核。
   （5）、锁：对一些单据或表单在数据中处理，一个期间只能处理一次，必须避免并发的情况，否则可能导致非意想的结果（锁的处理方式也是根据项目或需要而定）。
   （6）、数据查询权限：有一些需求根据不同的人数据的查询范围不一样，如张三只能查A部门数据，而李四则不限制等，这样的话你可能需要一个Sql代码生成器，动态生成不同的查询语句。
    (7）、........
   （8）至于该进行什么逻辑处理，只能根据项目或者业务而定。
   （9)、这样无论你今天高兴就搞一个ASP.NET页面，明天搞一个Silverlight，后天搞一个手机UI，这些UI开发人员无论是否懂得这些逻辑，均不会影响到你的数据结果。即使你的项目将一些接口(API)对第三方开放也不用担心别人是否提交合法的数据。

3、数据层：只负责数据存储和查询，换句话说只负责执行SQL代码并返回结果，有的用ORM，就可以直接不用数据层了，当然当前的ORM对于处理大型项目还是力不从心，仍然需要你自己额外的处理。

以上仅代表个人看法，希望对你有所帮助。