Synopse Open Source

On the mORMot roadmap, we added a new upcoming feature, to implement one-way callbacks from the server.
That is, add transparent "push" mode to our Service Oriented Architecture framework.

Aim is to implement notification events triggered from the server side, very easily from Delphi code, even over a single HTTP connection - for instance, WCF does not allow this: it will need a dual binding, so will need to open a firewall port and such.

It will be the ground of an Event Collaboration stack included within mORMot, in a KISS way.
Event Collaboration is really a very interesting pattern, and even if not all your application domain should be written using it, some part may definitively benefit from it.
The publish / subscribe pattern provides greater network scalability and a more dynamic SOA implementation: for instance, you can add listeners to your main system events (even third-party developed), without touching your main server.
Or it could be the root of the Event Sourcing part of your business domain: since callbacks can also be executed on the server side (without communication), they can be used to easily add nice features like: complete rebuild, data consolidation (and CQRS), temporal query, event replay, logging, audit, backup, replication.

If you discovered the mORMot framework, you may have found out that its implementation may sound restricted, in comparison to other ORMs, due to its design. It would be easy to answer that "it is not a bug, it is a feature", but I suspect it is worth a dedicated article.

Some common (and founded) criticisms are the following (quoting from our forum - see e.g. this question):
- "One of the things I don't like so much about your approach to the ORM is the mis-use of existing Delphi constructs like "index n" attribute for the maximum length of a string-property. Other ORMs solve this i.e. with official Class-attributes";
- "You have to inherit from TSQLRecord, and can't persist any plain class";
- "There is no way to easily map an existing complex database".

I understand very well those concerns.
Our mORMot framework is not meant to fit any purpose, but it is worth understanding why it has been implemented as such, and why it may be quite unique within the family of ORMs - which almost all are following the Hibernate way of doing.

With a previous article, we introduced the concept of "Domain-Driven design" into our framework presentation.

It's now time to detail a bit more this very nice software architecture design, and how mORMot is able to achieve such an implementation pattern.