三层架构中,层与层之间返回消息,怎么实现比较好?
举个例子:
比如UI层调用业务逻辑层,业务逻辑层会告诉UI层:操作成功、或者用户没有该操作权限、内部报错啊等等之类的消息。
请教一下各位有经验的朋友们,这种层与层之间的信息通信怎么设计和实现比较好。
谢谢!

解决方案 »

  1.   

    执行结果之类的 直接用INT就可以  再标准点  就用ENUM但是要是返回一张表  最好自定义类来实现比较好
      

  2.   

    或者用户没有该操作权限、内部报错啊
    ===
    这些可以添加TRY..CATCH 捕获到异常 直接在BLL 抛出
    WEB写个基类 让所有页面继承  捕获异常 提醒用户
      

  3.   

    现在的开放平台接口,每一个http接口的返回状态code都有好多种。
    如果我的业务逻辑层有一共有10个接口,一个接口里有10个方法,那就是100个方法,那这样就要设计100种信息集合了。
    我感觉是这样的。错了请指正!谢谢!
      

  4.   

    我把消息分成三类:成功、没有权限、内部错报,然后再加上一个具体的内容。
    不知道这样设计肿么样?
    /// <summary>
        /// 提示消息
        /// </summary>
        public class Message
        {
            /// <summary>
            /// 消息类型
            /// </summary>
            public MessageType Type
            {
                get;
                set;
            }        /// <summary>
            /// 消息内容
            /// </summary>
            public string Content
            {
                get;
                set;
            }
        /// <summary>
        /// 提示消息类型
        /// </summary>
        public enum MessageType
        {
            /// <summary>
            /// 
            /// </summary>
            OK,
            /// <summary>
            /// 没有权限
            /// </summary>
            NoPermission,
            /// <summary>
            /// 内部报错
            /// </summary>
            Error
        }
      

  5.   


    你认为.net的Exception肿么?
      

  6.   

    metadata
    [Serializable]
        public class MessageEntity : IMessage, ITag, IReset
        {
            public MessageEntity();        public IGlobalization Globalization { get; set; }
            public string MsgCode { get; set; }
            public string MsgDetail { get; set; }
            public bool MsgFlag { get; set; }
            public string MsgMessage { get; set; }
            public object MsgValue { get; set; }
            public object Tag { get; set; }        public void Reset();
        }
      

  7.   

    throw一个异常可以专门定制一个事件也可以
      

  8.   

    使用FluentValidation作为模型的验证
    也可以添加自定义验证消息,包括明细的错误。然后在业务层返回结果中包含ValidationResult这个类的实例FluentValidation的地址: http://fluentvalidation.codeplex.com/
      

  9.   

    Enum比较好,提前定义好,弄的简单,用的安心。
      

  10.   

    返回bool 类型,参数 out message或者直接throw Exception
      

  11.   

    比如UI层调用业务逻辑层,业务逻辑层会告诉UI层
    =============================================================
    唉,你把UI滴东西带到了业务层了。所谓的逻辑层是跟着逻辑跑滴,而不是跟着UI跑滴逻辑层才不会管啥有没有操作权限,内部错误,还是操作成功。对逻辑层来说,只有正确执行和异常退出同样权限判定 有自己的逻辑,他在真正的进入逻辑层之前就应该被处理了。
      

  12.   

    UI层才是执行输入清理,输出反馈的地方,而不是逻辑层。逻辑层是执行业务的地方,不是啥IO转运中心。
      

  13.   

    定义一组接口, 并由UI层实现,业务逻辑层的操作结果通过接口调用方式回传给UI。
    这种方式的好处是保特了UI层和逻辑层的松散性,低耦合。缺点是需要多维护一组接口。不建议靠异常来改变程序的流程,
    1. 如果调用层上没有作异常处理是不是程序就挂了? (假定上层的调用不是你自己写的哈,自己写可能不会有这样的问题^_^)
    2. 可能会导致资源的泄漏。
    2. 用异常本身会增加额外的开销, 虽然现在的计算机性能上提高了不少,但也要省着点用啊。
     
      

  14.   

    异常是报告错误的标准机制。应用程序和库不应使用返回代码来传递错误信息。异常的采用增进了框架设计的一致性,允许无返回类型的成员(如构造函数)报告错误。msdn上这样说
      

  15.   

    不要混淆了错误这个概念,我的理解楼主说的错误只是逻辑上的一个状态,不是程序上的错误导致程序运行不下去了。往往出现逻辑上的错误时,只是改变了程序的执行流程,并不是程序执行不下去了。如很多windows API函数, 执行不成功后,我们都可以通过GetLastError来取得错误代码,而不是选择抛出异常。 
      

  16.   

    Why not using Exception?
      

  17.   

    设计业务层异常属于设计阶段一个非常重要的步骤
    比如你说登录,
    try {
      LoginService.Login(username, pwd);
    } catch(LoginException ex){
      ...
    }
    ex中包括出错代码,出错原因和配套信息,指出是因为没有用户名,还是密码错误、又或者没有权限等具体原因
    如果权限会产生对于业务不同的地方,可以考虑设计2个Exception,LoginException,AuthrizeException
    这都是return value所不具备的,而且如果采用Message机制,这种非强制手段,1来每次需要取返回值,简单来说就是占着XX不XX
      

  18.   

    比如UI层调用业务逻辑层,业务逻辑层会告诉UI层:操作成功、或者用户没有该操作权限、内部报错啊等等之类的消息。内部报错操作权限可以全部继承基类,由基类去解决至于操作是否成功的问题。。你丫方法可以设置返回值啊