显示来自非UI dll的对话框

时间:2019-05-13 18:33:26

标签: c# .net dialog

我正在构建一个将从wpf和其他类型的框架(Windows窗体,asp ...)中使用的dll。因此,我不想使用消息框。 Wich是从dll向应用程序发送通知的最佳方法,并且每个方法都决定向用户显示消息的方式(并等待用户的答复)?有人可以帮助我找到正确的方法吗?

2 个答案:

答案 0 :(得分:0)

您可以公开使用者可以订阅的事件。这是执行此类操作的一般模式:

您可以创建自己的类来携带有关事件的数据:

public class NotificationEventArgs : EventArgs
{
    public NotificationEventArgs(string message)
    {
        Message = message;
    }
    public string Message { get; }
}

然后您创建一个代表事件签名的委托:

public delegate void OnNotificationEventHandler(SomeClass sender, NotificationEventArgs args);

您的一个或多个类然后可以将此委托公开为事件:

public class SomeClass
{
    private OnNotificationEventHandler _notificationEventHandler;
    public event OnNotificationEventHandler OnNotification
    {
        add { _notificationEventHandler += value; }
        remove { _notificationEventHandler -= value; }
    }

    protected void RaiseNotificationEvent(NotificationEventArgs args)
    {
        _notificationEventHandler?.Invoke(this, args);
    }

    public void SomeMethod()
    {
        //Your class does something that requires consumer notification
        var args = new NotificationEventArgs("Something happened!");
        //Raise the event for the consumers who are listening (if any)
        RaiseNotificationEvent(args);
    }

}

最后,您的消费类将订阅此事件:

SomeClass obj = new SomeClass();
obj.OnNotification += Obj_OnNotification;

private static void Obj_OnNotification(SomeClass sender, NotificationEventArgs args)
{
    //Handle the notification from the class here.
    Console.WriteLine(args.Message);
}

通常的想法是,您的类的消费者只需要知道已发生的事情以及发生的事情的细节即可。 事件的使用,处理或显示方式不是组件的责任。

答案 1 :(得分:0)

除非库(.dll)仅用于特定的UI,否则库不应“决定”通知的显示方式或显示方式。这是关注点分离。如果某个库确定它应显示MessageBox,那么您将无法将该同一个库与Web应用程序或某些视线服务一起使用。

有两种方法(并非穷举)可以使我们从单独的库中获取信息,包括我们自己的库:

  1. 我们调用一个函数,并且库返回响应。例如,它可能表明操作成功或失败。该库不知道从哪个应用程序中调用它,也不知道是否有人需要查看响应。它只是返回它。然后,您的应用可以接收该结果并显示一条消息。

  2. 库中的类引发一个事件,该事件指示发生了某些事情。同样的事情-它甚至不知道正在监听什么,或者结果将是什么。它只是引发通知。我们的应用确定响应该事件,它应该显示一条消息。

当我们的库以这种方式工作时,可以更轻松地使用单元测试和集成测试等自动化测试进行测试。编写测试以验证调用方法是否返回特定结果很容易。要验证弹出的MessageBox更加困难。

并且,如上所述,这使我们更有可能在不同类型的用户界面上使用更多代码。出于这些原因,将尽可能多的代码与任何UI隔离地编写是有益的,这意味着不包括特定于一种类型的UI的输入/输出行为。