One of supported languages in DSL Platform is PHP. What does that mean?
It means that you can model your data layer in DSL and let Platform maintain database and application layers. Model can be integrated with one of the supported client libraries. Source can be found at Github. You can also take a look at Phpdoc.
Why is that better than maintaining model classes and mapping information by hand?
Let's ignore that Platform can maintain this models for variety of languages (such as C#, Scala, Java, etc...). Let's ignore that DSL is as compact as it can be, while other solutions are much more verbose. There are several distinguishing features that are offered by Platform not available by other solutions:
- type safety - generated php classes will have type safety embedded in them. This means that when you assign some string to int property, reasonable conversion will be attempted and exception will be thrown if conversion can't be done
- specifications - while writing conditions in a single language which will be converted to other languages, functions in the database and various other formats is better than writing them in a special ORM syntax, the biggest gain comes from better understanding. Specifications should reflect meaningful business process and their should reflect that.
- api - one could argue that there is not much difference between writing "SELECT COUNT(*) FROM MyTable" and MyTable::count(). While this may be true for simple examples, more complicated examples would start to look really ugly. But the biggest gain is from API abstraction. Caching, security and other aspects can be integrated without any problems, but API will remain the same.
- server infrastructure - most ORMs try to offer one feature and usually offer it poorly. Object-relational impedance mismatch is a known problem, which doesn't exists in DSL Platform. Reimplementing features all the time is not fun. Reuse advanced features such as reports, simple olap cubes that can be easily defined in couple of lines of DSL, instead of hundreds or thousands of lines of code which can't be reused
- advanced database migrations - simple migrations can be found in variety of ORMs and similar tools. Some even have nice features such as rename detection, but still leave you with a lot of work in evolving your database model. Platform migrations sometimes look like magic since it goes a long way to try and preserve your data, even when underlying technology doesn't allow it.
How far can Platform go to remove boilerplate coding?
Actually very far. Using Invasive software composition we are integrating other frameworks and their respective languages. This means that if there exists some pattern and it is useful, Platform can provide you with boilerplate code required to use this pattern.