Presenter base class

Topics: CAB & Smart Client Software Factory
Mar 5, 2006 at 2:04 PM
originally posted by: nidgir

just a question - wouldn't it be better to have a presenter base class which encapsulates IDisposable and the view setter/getter
something like that:

public class Presenter<TView> : IDisposable
{
private TView _view;
private WorkItem _workItem;

public TView View
{
set
{
_view = value;
}

protected get
{
return _view;
}
}

public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}

protected virtual void Dispose(bool disposing)
{
if (disposing)
{
if (_workItem != null)
_workItem.Items.Remove(this);
}
}

ServiceDependency
public WorkItem WorkItem
{
set
{
_workItem = value;
}
}
}

I tried to insert this into the AppraiserWorkbench and it worked
Apr 4, 2006 at 9:12 AM
originally posted by: sagi44

My thoughts too.
First thing i realized about the BAT that there was no reusabilty approach to the presenters.
Isnt that something thats been talked about all along?
The Qs samples in the Composite Block all had their Presenters inherit from Controller or someother class, so why the downgrade here ?
I can come up with plenty of functions to implement on a base Presenter class.
Anyone?
Apr 8, 2006 at 3:16 AM
originally posted by: turmelma

In my approach I've been using base Presenter classes also. Saves a lot a plumbing code down the path. In this RI however I believe the people from p&p might have focused on recipes and automation of some parts of building a CAB application, and with respect to this the Disposal code might have been generated by scripts.

Nonetheless, to my opinion this kind of code should still be factored to a base class. Inheritance is a crucial element in providing extensibility to your end users. And they might not use the recipes you could have.

Marc