is it a bad idea to pop up a dialog in a class library?

we have some class 开发者_StackOverflow中文版library that will pop up a dialog, is this a bad idea to do so?

Class libraries are meant to consolidate business logic and to reduce code duplication. Dialogs should be displayed into your presentation layer, where it can decide better way to do so.

For instance, if you class library being used into a winform application, that dialog will be different from dialog displayed into an website.

Yes, it is a bad idea. What happens if a windows service is to use your library?

The only scenario I can think of that this would be OK in is if the class library is for visual display components and will only be used in that context (i.e. only contains dialog boxes and UI components).

When writing a class library that is to be used in many different scenarios, you don't want a blocking call that requires human intervention.

You may be able to find out if the session is interactive or not and make a choice on creating a popup, but this is a hack at best.

Your library should bind to as little other libraries as possible to achieve the intended purpose. Unless you library is some kind of gui library, don't use pop up dialogs.

If it is a class library for displaying dialogs then yes. For any other sort of class library then no.

the right thing for the library to do is to take callbacks like "getInformationFromUser" or "showError" or whatever. It is then up the the library caller to decided how that is done. Or for reporting errors it should raise an exception or return an error code.

For a library to show the dialog itself it has to make a large number of assumptions - that the library is being used in a GUI program, what GUI framework is being used, what language the user understands etc. This is wrong, wrong, wrong.

It very much depends. If this class library contains many other GUI classes, then maybe. If this library contains domain objects, then this sounds like a bad idea.

I think it's a bad idea. But in certain cases you might want to make UI logic reusable. In that case try to pull out user-interaction code in a separate library.

I'd say bad idea. For an example of a non-visual library class, take a look at QFile. When using it, it reports error status back as return values (e.g. if(!file.open(mode...))), and then keeps the last error both as an application friendly enum (http://doc.trolltech.com/4.6/qfile.html#error) and as a human readable error string (http://doc.trolltech.com/4.6/qiodevice.html#errorString) which your application can use to easily pop-up a dialog, print it to a console, or add it to a log, etc.

As you can see, this approach gives the application the power to decide how to handle the error message - instead of the library making what it feels is good for the moment.

In theory, if it's just used in one specific application that you know will be only used with a GUI, then there's no harm in it.

But the harsh reality is, libraries will have the tendency to turn more and more generic and you'll need them in all sorts of applications, not just GUI-based ones. So you might as well plan ahead and ban dialogs in the library and just handle the error reporting some other way.

Here's what I think: It depends to the main purpose of your class library if it's a UI module that provides some UI features then there should be some dialogs and forms and etc. but if it's a library that is supposed to provide some services (business or data access) to other parts of your application there should be no UI element in your library.