SObject vs Generic Apex Class

Question

Pardon me for asking a basic question. I have just started looking at Salesforce development guides for a project. From my understanding so far, there are objects created through an Object Mapper called SObjects and Generic classes (created in Apex) which can be instantiated to create objects.

What is the basic difference between the two? As per my understanding:

1. SObjects are mapped to a table. Generic Apex classes are not.
2. SObjects can be used "in some way" to automatically define page layouts? Not sure about this yet, but saw it somewhere.
3. If I were supposed to design a "Search" component and "Display" component through Lightning Experience while fetching data from an external application (residing on some internal server), I would need to talk via REST/SOAP and fetch data. Should this data be parsed to SObjects or Apex object instances? At the moment, I don't think the data needs to be stored in Salesforce actually.

Sorry if these are too silly. But I don't seem to be fully sure of all the functionalities and it's a little confusing still.

Also, is there something I am completely overlooking here?

Answer 1

Like other object-oriented languages, Object is the root for all other objects. Any time you have a Date, it's an Object, or if you have a Schema.Account, it's an Object, or if you have a BarBaz (custom Apex Class), it's an Object. Everything is implicitly an Object because of inheritance.

sObject is an Object, and also the root for all concrete database record objects (Account, Contact, Lead, etc). It has special methods for accessing its properties dynamically, is the only type of Object you can use to insert or update records within Apex Code, and is one of the three types of Object that can be returned by a query (the other two being AggregateResult and Integer).

Considering your intent, I think it doesn't make sense to use an sObject here, it can just be a plain old object of some sort. The automatic layout feature is nice, but that's only in select components, and is intended to help embed Salesforce records into a component or application. There is considerable (~300ms) overhead to using things like force:recordData or force:recordView, because they have to fetch additional metadata you're not even using.

Depending on the data, you don't necessary even have to write a wrapper class, you can just use built-in objects. Or, make it even less complicated; just return your data as a String back to the Lightning Component and parse it there; JavaScript has much better performance than Apex Code.