Downcast on POCO classes

Question

I have a group of POCO classes:

class ReportBase
{
    public string Name { get; set; }
    public int CustomerID { get; set; }
}

class PurchaseReport : ReportBase
{
    public int NumberOfPurchases { get; set; }
    public double TotalPurchases { get; set; }
    public bool IsVip { get; set; }
}

class SaleReport : ReportBase
{
    public int NumberOfSales { get; set; }
    public double TotalSales { get; set; }
}

I have a web method to return ReportBase. The caller uses the return value to update UI(WPF) based on the actually type by downcasting and checking the type (one grid for sale and one for purchase). Someone suggested to use three web methods and each return the specific type.

I understand that downcast is in general against design principle by introducing if/else. Instead we should use virtual functions. But in POCO class, we don't really have virtual behaviors (only extra fields).

Are you for or against downcast in this case, why?

I think you missunderstand POCO: it's not that poco's should be stupid structs without behaviour - they should not depend on external dependencies like attributes, interfaces, base-classes. So don't trade POCO with imperative design — Random Dev, Mar 16 '12 at 06:05
SOAP supports inheritance. You should be able to get the correct object if the WSDL is defined properly. http://www.ibm.com/developerworks/websphere/techjournal/0401_brown/brown.html — jgauffin, Mar 16 '12 at 06:12
@Carsten, not hang on the term, what about the downcasting usage here? — Icerman, Mar 16 '12 at 06:53

score 1 · Accepted Answer · answered Mar 16 '12 at 12:52

IMO it's all about intention. Returning just the base class doesn't say anything, especially as you return it only to save some key strokes. As a developer what do you prefer?

ReportBase GetReport() // if type==x downcast.
//or
PurchaseReport GetPurchaseReport()
SaleReport GetSalesReport()

What approach would you want to use to make the code more maintainable? Checking type and downcasting is an implementation detail after all and you probably have a method like this

public void AssignReport(ReportBase report)
{
    //check, cast and dispatch to the suitable UI
}

What's wrong with this? It's lacking transparency, and this method should always know about what reports are needed by what UI elements. Any time you add/remove an element you have to modify this method too.

I think is much clear and maintainable something like this

salesGrid.DataSource=repository.GetSalesReport();
purchaseGrid.DataSource=repository.GetPurchaseReport();

than this

var report=repository.GetReport();
AssignReport(report); //all UI elements have their data assigned here or only 2 grids?

So I think that, POCO or not, I will favour the three web methods approach.

+1, what if there are many more types (besides sale/purchase), would you still favor multiple web methods? — Icerman, Mar 16 '12 at 23:54
Even more. You can have a single web method (on the web service) acting like a controller of some sort, but inside you have to do a switch (type) and then get a specific report , so in way you still have multiple methods but they are private. So you just make them public and deal with them transparently. I repeat, IMO it's all about intention and clarity. — MikeSW, Mar 17 '12 at 07:04

Downcast on POCO classes

1 Answers1