Object-relational mapping tools receive a lot of hate and praise at the same time.
Most of the hate is related to poor abstraction over SQL. Pragmatics argue that there is a lot of value when most of your mapping can be taken care of by some tool. Dropping down to raw SQL through the abstraction has become a norm to solve most complicated queries.
Still, conversion from objects to relations and back is a hard problem also known as Object-relational impedance mismatch.
Since it's relatively easy to set up basic mapping, many teams implement it using their own simple, but sufficient micro-ORM. They still suffer from OR impedance mismatch, but at least don't carry a lot of unnecessary baggage around.
This helps when performance becomes an issue since it's more transparent to fix problems in a simple code, than to learn how to solve this problem using complicated ORM. Knowing whether the problem can be even solved by using the ORM requires deep knowledge of the ORM.
Because it's a way to avoid Object-relational impedance mismatch, it is also very popular.
Hierarchical structures are easily expressed in JSON, but a lot of wheels must be reinvented to match the ease of use and performance relational databases offer for querying. Schema changes and deep insights are often discouraged, since model is embedded with the data.
"title": "Fairy tale",
"content": "Once upon a time...",
"footnotes": ["in a far away kingdom", ...]
While XML is commonly available in popular databases as hierarchical structure and often used for all kind of purposes, JSON is not so widely available but it's slowly spreading.
<content>Once upon a time...</content>
<string>in a far away kingdom</string>
Little known fact is that some of the most popular databases are object-relational. As such they can be used in a way to avoid Object-relational impedance mismatch. But there is a lot of pain in using them in such a way and this is mostly advanced and unportable way to use a database.
While it should be recommended to use database features to the fullest, this goes against database agnosticism where ORM tools try to help. While many of advanced features can be consumed through ORMs, because they will not work on other databases, they are rarely utilized.
Most hierarchical structures can be expressed in object relational databases and often can be optimized to fit the domain model requirements much better than JSON databases.
ORM tools helped spread the myth that Object-relational impedance mismatch is something you have to live with, but they get hate for other, less important reasons.
CREATE TYPE Page AS (
CREATE TABLE Book (
title VARCHAR PRIMARY KEY,
.NET SQL-like language for querying is way ahead of custom languages ORM tools and even JSON databases offer. Fortunately it's spreading to other languages, and even if most of the benefits are lost, the syntax stays familiar.
Unfortunately for relational-only databases, it's hard to reason how LINQ query will be translated to SQL query. Also, implementing LINQ provider is no small task.
So while LINQ improved the situations, it didn't really solved ORM issues, although it did give a safer way to query data.
Why does DSL Platform has its own LINQ provider?
Prototype version was built using NHibernate but its LINQ provided wasn't very useful. Since that was the only interesting feature ORM provided, it was soon replaced with primitive, but functional LINQ provider which evolved to fully featured as it is today.
DSL Platform approach
With all that in mind, how does DSL Platform fits in?
- only object-relational databases are first class citizens
- type safety is preferred way of modeling, but automated migrations remove the friction of schema changes
- not everything is an entity/table. Appropriate database features are utilized, so that the same DSL model is propagated to the database and to the code
- aggregate boundaries are same in objects and in database views. This makes it easier to reason about performance and use more suitable concepts such as snowflakes, reports, domain events to interact with the system
- it is much easier to understand queries which will be generated by DSL Platform LINQ provider since 1:1 mapping is maintained
- appropriate concepts and patterns are utilized to query the data which makes dropping down to raw SQL very rare. SQL is used mostly for interacting with legacy tables
- compilers build OR mapping parts of the code as experienced developers would write it by hand. This makes it as performant as possible
- set based API to the database is the norm, not the exception
- various database storage optimizations are utilized to ensure maximum performance
Can't we just improve ORM tools? What's so special about DSL approach that can't be done using code first modeling with ORM tools?
ORM tools are working on different abstraction level and thus have much less knowledge about actual domain model. While many problems with the tooling could be fixed, it would still remain just an OR mapper and not an DDD tool. DDD provides building blocks and terminology for building applications. DSL Platform builds upon the basic building blocks and provides infrastructure for transforming model to the optimized boilerplate developers would have to write.
Also, same model can be used to maintain persistence layer, serialization layer and many other application layers.