The main difference between business logic and algorithms is hidden in what exactly you are doing as a developer - developing technical algorithms, or implementing business logic. Ok I know, you can implement business logic in .NET, just as you can develop technical algorithms in Salesforce - however, it usually is vice versa, and again, the foundation is laid by the platform.
And the dissimilarities start to appear from the very beginning: for example, usually in the .NET applications, when working with a Database you operate with tables, while in Salesforce you always work with Business Objects (even if they are exactly the same tables in the database).
"Tables" versus "Business Objects"
This difference seems to have nothing to do with the technical side of the development - and yet surprisingly it does. It starts to influence your development experience with the great turnover speed that was described before - because Salesforce does it's best to handle as many pure technical areas as possible, which does not influence the business logic itself.
Another technical result of this approach is the example I've mentioned before - the access to the database. In .NET we are configuring different ORMs like Entity or NHibernate to access the data. Just think about the performance of queries that is generated by them (have you tried to check which queries they're generating exactly, to get this simple data?) and then, finally, the performance to use it. However, in Salesforce, business objects (i.e. records in the database) are the key point of our development - as everything is built around them. That is why the ORM is built into the platform itself, and you don't need to do anything to properly work with the database. Even the performance of the ORM is great!
Sample SOQL (Salesforce Object Query Language) query in the Query Builder
One more cool aspect of this approach is that you don't need to write code for everything - you should instead use as much "declarative development" features, which this platform has, as possible. For example, for the simple triggers in the database, instead of code, you can use Workflows or Process Builders. Likewise, you can implement the same logic without writing a hundred lines of code (including unit tests, of course), with just your mouse, and with less time being spent. At this stage, you're not trying to build a beautiful and complex process from scratch - you just implement some small bricks, and then combine all of the into a smooth flow later. This means that you should know what can be done within the platform using the existing tools - this is where Trailhead, the educational platform for Salesforce, comes into play and helps a lot!
Even more, since you're not resolving the technical challenges, but instead dealing with business functionality in the scope of truly-business applications & platforms - theoretically, you should understand how your end users are working, what they see in Salesforce, and which standard approaches they use. So before starting to develop something new, it will certainly be a great useful experience to get into your user's shoes, and see how you can make their life (or at least work) happier. And again, this is where Trailhead is a great place to spend a few hours learning how "businesses" see Salesforce.
Some of the Trailhead modules to look at, in addition to the main the Development trail:
- Learn CRM Essentials
- Sell Lightning Fast with Sales Cloud (yes, I do suggest developers to learn how to sell with Salesforce
)
Adjusting your way of thinking to the described way will surely help you dive into Salesforce development much easier.
Your comment may be the first