The mORMot attitude
In a discussion with Henrick Hellström, in Embarcadero forums, I wrote some high-level information about mORMot.
It was clear to me that our little mORMot is now far away from a simple Client-Server solution.
The Henrick point was that with Real Thin Client (RTC), you are able to write any Client-Server solution, even a RESTful / JSON based one.
He is of course right, but it made clear to me all the work done in
mORMot since its beginning.
From a Client-Server ORM, it is now a complete SOA framework, ready to serve Domain-Driven-Design solutions.
In mORMot, you can also have complete control over all of the
aspects. Even routing can be customized, the same for data access (you are not
stuck to SQLite3 for instance), or JSON serialization. mORMot
can serve directly web content, dynamic or static, if needed. So you are not
stucked to one implementation pattern, from a black box. It is worth
mentioning. This is the same for RTC: both provide source code and try to
follow the Open/Close
About openness, the fact that mORMot is true Open Source (with 3 licenses), allows it to be modified, even forked if needed - whereas you can't be sure it would be possible with RTC more conventional proprietary approach (remember the great Bold project?).
My remark was not about "philosophy" of both projects, it is about scope.
RTC is about the communication layer, whereas mORMot is now a
framework (DDD) - i.e. it proposes a proven (and adaptive) model embracing
communication, application, domain, persistence layers, with all cross-layers
features (like security, cache, session, data marshaling, logging,
i18n, business rules, reporting).
I'll add some information about DDD in the framework documentation, in the next days.
RTC-based projects are, AFAIK procedural-oriented (i.e. by "function"),
whereas mORMot has a true OOP model, involving classes and
It is one drawback of the RAD approach: when you use components and events, you are tied to this procedural orientation in your project architecture, even if the RTC implementation itself uses classes. Of course, you can map the RTC events within your own classes, but you'll have to write a lot of code by hand, and you'll soon reach the limits of RAD.
My point was that you will have to reinvent the wheel if you start from a scratch RTC code - and this is not what the OP wanted in the original forum thread: "I love not writing code. especially json streaming code".
IMHO, if we may compare to the Micro$oft product line, RTC is some kind of light-weight and powerful ISS in managed code (including nice features like scripting).
Whereas mORMot is now a
whole SOA framework, containing features from ISS, WCF, WPF, WSA, Entity
Framework and DB access.
Of course, it is less complete than .Net based products, but it offers most of the needed SOA features.
And it is much lighter, also faster, with all the source code provided, with no runtime to install, no marketing or commercial patterns to follow.
There is a gap between providing a Client-Server communication layer (like IIS or any RESTful server), and proposing all necessary bricks to build a whole Service Oriented Architecture.
Feedback and comments are welcome on our forum.