.NET控制层调用商业逻辑层返回数据

Question

.net控制层跟逻辑层数据交互

Answer 1

一个函数只能有一个返回值
你想多加一个,只用return是不行的
可以多加个out int ActionFlag参数,用参数返回

Answer 2

把返回值设为object类型，你想返回什么就可以返回什么

Answer 3

改动比较少滴就是加个out参数当然我个人比较不喜欢out，ref参数，所以我个人通常返回  Tuple<T1,T2>或者干脆就啥都不返回直接抛自定义异常，根据你的代码来看，其实你那个标识的目的就是为了区分是否有逻辑上的异常（非系统异常）

Answer 4

是要问怎么返回两个数么?   object[] get(guid) 或者用 void get（guid ,out，out）

Answer 5

 按照大家的指导我把get方法改造成下面的加out参数的 
public Goods outGet(Guid? Id, out String ActionFlag)
        {
            var item = new Goods();
             ActionFlag = "0";
            if (Id.HasValue)
            {
                item = nContext.Goods.SingleOrDefault(a => a.Id.Equals(Id.Value));
                ActionFlag = "1";
            }
            return item;
        }
控制层里面的方法会出错
  public ActionResult Eidt(Guid? id)
        {                 var item = _GoodsBLL.Get(id,out value);//请问调用的时候该怎么写？
                           ViewBag.userid = item.UserId;//item的对象又该怎么调用呢？

Answer 6

string value=“”;
 var item = _GoodsBLL.Get(id,out value);使用out参数必须先声明一个对象，这也是我不喜欢out参数的原因，1是打断正常编写逻辑，2是也不符合正常程序逻辑，所以我个人更愿意直接自定义异常来表示，非正常逻辑的错误

Answer 7

   /// <summary>
    /// 内部逻辑错误，以便对外显示消息
    /// </summary>
    public class LogicException : Exception
    {
        public LogicException(string msg):base(msg)
        {        }
    }后面如果遇到业务逻辑上的错误直接写  throw new LogicException("这里业务逻辑错误");前端调用
try{}
catch(LogicException ex)
{
   //这里你可以根据情况，选择是吃掉异常，对外弹出警告显示ex 的msg
}
@红孩儿，你现在到处都出现啊，不过你不觉着out，逻辑上很别扭了，本来这个逻辑不是上面的逻辑，本来你顺手就调用了，结果写着写着，突然发现后面有n个out参数，你就把编写逻辑打断，跑上面先定义n个变量，然后在回来继续写你的调用逻辑，你要觉着习惯挺好，我反正觉着不习惯，对此种api方式一直都无爱

Answer 8

ps：单纯就你这个方法，也可以另外一种约定处理
  var item = new Goods(); 这里可以先不要new他，
在后面成功了在new，不成功就返回null这是一种约定处理方式，因为前端调用者通常也习惯于在任何对象获取以后优先判定一下null，来避免微软那个”未找到对象实例“的诅咒 var obj=xxx.getxxx()
if(obj!=null)
{
   //基本上这种代码段，已经是俺们编写的约定常态了
}

Answer 9

@wanghui0380 <script type="text/javascript">
    string ActionFlag = @{ViewBag.abc}//js调用控制层的变量正确写法？？
</script >

Answer 10

s; 我其实一直强调语义大于语法，我之所以不喜欢out，ref，是因为这两个是语法大于语义，语法大于语义的东西用起来别扭，而语义优先用起来就舒坦很多，无论是第一种异常，还是第二种约定。起码语义上异常是应该调用者处理滴，而约定则是已经调用者语义上已经形成习惯了，也没啥负担。而out，ref纯粹是语法大于语义，并且把原本该下面处理的逻辑，在语法上强行上上面执行了，这个太别扭了

Answer 11

你的“商业逻辑层”到底是什么意义呢？如果它是与UI无关的，那么它不应该引用你的“控制层”的特殊的类型，它就应该返回通用的业务领域对象。反之，如果你的所谓“商业逻辑层”想返回你的控制层才有的特殊类型，那么你就别说自己有什么“商业逻辑层”了，或者你的新的层还是要分成两部分——一部分就是现在是“商业逻辑层”，另一部分负责将Goods值转换为ActiongFlag值。但是如果你写了这个层，发现跟现在的代码还是一样，可见纯粹是脑袋疯了、想多余地弄一层出来了。

Answer 12

如果一个“商业逻辑层”方法真的需要返回一个集成的、有着Good和ActionFlag两个属性的对象，那么你定义这样一个class用于“商业逻辑层”返回值就行了。更重要的问题是，这个ActionFlag应该是表现层里边自己去处理的，表现层里边可能有许多地方根据得到的一个item(Goods)而改变状态，它就应该写在你的Edit.....这类方法的代码里边，而不是写在什么“商业逻辑层”。

Answer 13

两种方法：第一，自己定义一个实体，将你要的属性全部添加到实体里面去。第二，在方法参数增加一个。public Goods outGet(Guid? Id, out String ActionFlag)