0 votes
1 view
in Salesforce by (11.9k points)

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?

1 Answer

0 votes
by (31.6k points)

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.

Related questions

+1 vote
1 answer
0 votes
1 answer
0 votes
1 answer
Welcome to Intellipaat Community. Get your technical queries answered by top developers !


Categories

...