Introduction
This is my second post in a series of related posts about Drupal entities
the first is here.
If Drupal was predominately a framework as opposed to a customisable CMS then you would expect that a skilled PHP programmer with a good understanding of appropriate design patterns from other frameworks (MVC etc.) could reasonably quickly start from scratch with Drupal to build a moderately complex and well designed website.
Unfortunately this is not the case at the moment, the learning curve for Drupal is still too steep for most people to pull this off. One aspect of the "Drupal way" is to not re-invent the the wheel and to use from the massive selection of community contributed modules to implement your required functionality, and this works well for relatively simple sites.
Of course you could point out that Drupal is essentially a CMS, but it is increasingly being used for functionality that goes far beyond a traditional CMS and in those cases it is fair to ask how does it stack up as a framework. Sometimes software like Drupal will also be described as a content management framework (CMF), it may put things in perspective to see
a list of software that could be considered in a similar space.
Where Entities step in to raise the bar for Drupal is in the role of modelling data.
Sometimes you have to write code, maybe your requirements are not mainstream enough to have a custom module or you have to integrate with a bespoke API or your clients are using Newsweaver rather than MailChimp or you have to integrate a bunch of contrib. modules in a way that was never envisaged. Of course all those wonderful custom modules required development and Drupal core requires a continual injection of developers that can work on the next generation of Drupal required for the ever involving web.
Not surprisingly the higher paid developer roles expect you to write quite a lot of code...
