locked
MVP passive view. Presenters sharing a common LogView RRS feed

  • Question

  • I am trying to rewrite an application from a bloated Form1.cs into model-view-presenter passive view. So far it has been quite successful. However, in the original Form1 I had a LogView (a RichTextBox) which I could write stuff to during execution.
    In my new MVP design, what would be the best way of having the presenters/models/view write to a similar LogView?
    I have come up with two possibilities.

    1. Make a static Log class that could be used. Problem with this is that the implementing methods might loose generic purpose and should be modified when used in another application.
    2. Pass a reference to the Log class to every single class that would implement the Log class methods. This sounds error prone! Also there would be a high degree of coupling which sort of defeats the MVP paradigm.

    Can you help me in the right direction? The problem must be quite common as logging stuff (to a file or a view) must be quite a used way of generating information to the user.
    • Moved by OmegaMan Tuesday, June 30, 2009 6:05 PM (From:Visual C# General)
    • Moved by Kira Qian Thursday, July 2, 2009 2:51 AM (From:Windows Forms General)
    Tuesday, June 30, 2009 9:13 AM

Answers

  • Hmm...  Good question.

    I'd say that you have a couple of options. 
    Probably expose a property of the messages in your presentation model.  The presenter can then call through to your business logic for whatever it currently does, as well as a logging subsystem.

    I would personally have some sort of object broker / ui process class to create the instances for each subsystem facade, and inject them into the other facades that require them, to call the logging functionality through the interface.

    The logging subsystem can be queries to return whatever number of log messages are required to be shown to the model.  The view can then be bound to, or the presenter logic call call methods on the view to push the data from the model into the view, depending upon how you implement.

    Hope that helps?

    Martin.

    MCSD, MCTS, MCPD. Please mark my post as helpful if you find the information good!
    • Marked as answer by Hobz Monday, January 11, 2010 10:09 AM
    Thursday, July 2, 2009 3:18 AM

All replies

  • Hi Hobz,

    The question seems to be better served on Architecture forums.

    Sincerely,
    Kira Qian
    Please mark the replies as answers if they help and unmark if they don't.
    Thursday, July 2, 2009 2:51 AM
  • Hmm...  Good question.

    I'd say that you have a couple of options. 
    Probably expose a property of the messages in your presentation model.  The presenter can then call through to your business logic for whatever it currently does, as well as a logging subsystem.

    I would personally have some sort of object broker / ui process class to create the instances for each subsystem facade, and inject them into the other facades that require them, to call the logging functionality through the interface.

    The logging subsystem can be queries to return whatever number of log messages are required to be shown to the model.  The view can then be bound to, or the presenter logic call call methods on the view to push the data from the model into the view, depending upon how you implement.

    Hope that helps?

    Martin.

    MCSD, MCTS, MCPD. Please mark my post as helpful if you find the information good!
    • Marked as answer by Hobz Monday, January 11, 2010 10:09 AM
    Thursday, July 2, 2009 3:18 AM
  • Kira, thanks for moving the post.

    Martin, I vaguely grasp your idea.
    I guess I was thinking more in the lines of a Console like view, which opts for the static solution. In the LogView.WriteLine I will have a static variable which indicates which view (i.e. TextBox or similar) to log info to.
    Thursday, July 2, 2009 11:02 AM
  • On second thought, there might be sense in pushing the log-messages on a queue instead that is then emptied by a backgroundworker or a timer.
    Thursday, July 2, 2009 12:19 PM
  • When it comes to logging, it might be a good idea to take a look at some logging library, like log4net. I can't remember other such libraries currently but there are some available. They normally have a good ammount of useful functionality embedded and they are extendable.

    Hope this helps.
    Thursday, July 2, 2009 12:31 PM
  • Thanks. I will have a look.
    Monday, July 6, 2009 6:42 AM