C#/Salesforce: Must Constrain Generic, Cannot Constrain Generic

Question

This question is equal parts C# and Salesforce, there are probably solutions possible from either side. Suggestions welcome!

I'm writing a generic class to read Salesforce data. The signature looks like this:

public abstract class SalesforceReader<SalesforceObjectType, RecordType>

  where SalesforceObjectType: sObject

This lets me use this code later on:

List<RecordType>  records = new List<RecordType>();

QueryResult  queryResult = service.query(query);

foreach (sObject rawRecord in queryResult.records)

  records.Add(ConvertRecord((SalesforceObjectType)rawRecord));

...

public abstract RecordType  ConvertRecord(SalesforceObjectType record);

The plan is to write implementations of this class which know how to parse, for example, a Salesforce Lead object into a RecordType, which may be a basic object[], a Dictionary<string, value>, or a fully-defined struct as I choose later on.

So far, I'm all kinds of pleased with my brilliantly elegant solution. My Codey award is as good as won. Then I try to write an implementation. This definition is no good:

class LeadReader: SalesforceReader<Lead, object[]>

The compiler result is:

The type 'SalesforceExtractor.Salesforce.Lead' cannot be used as type

parameter 'SalesforceObjectType' in the generic type or method

'SalesforceUtilities.SalesforceReader<SalesforceObjectType,RecordType>'.

There is no implicit reference conversion from

'SalesforceExtractor.Salesforce.Lead' to

'SalesforceUtilities.Salesforce.sObject'.

Bummer. I have to have the where SalesforceObjectType: sObject constraint in the abstract class so I can cast sObjects, but because the conversion is not implicit, it's not good enough for the implementing class.

Do I need to kiss my neat little solution goodbye, or is there a way to salvage this? This is my first Salesforce project, so if I need to approach things differently, please let me know.

For the bad movie/MST3K buffs out there:

Where do "must" and "cannot" meet on the graph?

Answer 1

So basically, lead does inherit from sObject, but the abstract class in a library, in a distinctive namespace and project from the implementing class, and each of them is using the Salesforce WSDL. You might be asking the compiler to cast SalesforceExtractor.Salesforce.Lead to SalesforceUtilities.Salesforce.sObject, 

which is not valid. You just need to be more explicit in my implementing class:

class LeadReader: SalesforceReader<SalesforceUtilities.Salesforce.Lead, object[]>

This compiles, and I think you should be good to go.

If you are planning to break into the Salesforce domain, and are not sure where to start, I would recommend you start by enrolling yourself in a Salesforce course from Intellipaat!