The mORMot attitude

ab · 2012-04-25 08:32:51

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 principle.
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 Domain-Driven 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 interfaces.
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 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.

There is a gap between providing a Client-Server communication layer (like IIS), and proposing all necessary bricks to build a whole Service Oriented Architecture.

Comments from http://blog.synopse.info/post/2012/04/2 … t-attitude

andrewdynamo · 2012-04-25 11:34:42

Can you make a demo implementation with mORMot and RTC and RemObjects SDK/Data Abstract?
So I can compare mORMot against theses types?

mpv · 2012-04-25 12:13:03

I don't know about RTC, but mORMot and RO is like rocked and turtle if we spoke about speed. Especially for large numbers of clients.

ab · 2012-04-25 12:54:54

I did not make any benchmark, but I guess:

RTC and mORMot:
- Both RTC and http.sys are event-driven, so have the same architecture, better scaling than Apache or Indy, for instance;
- http.sys core is running in kernel mode, and is provided as part of the OS by Windows: so it is told to have the best possible performance, since the WinSock layer (used by RTC) is bypassed by http.sys, and will avoid most memory copy between OS kernel and user land;
- mORMot can communicate in-process (no client-server), via GDI messages (very fast on the same computer), or via http.sys;
- RTC is cross-platform, whereas mORMot is only for Delphi (the FPC port is coming);
- mORMot is free, open source.

RO and mORMOT:
- RO uses Indy or Synapse, which are not event-driven (like RTC/http.sys), so should be slower, and less scalable and light than mORMot's http.sys server - from mpv feedback (see above), which uses both, mORMot is much faster;
- Both are made to build n-Tier applications, and allow access to any DB via object;
- mORMot has some unique features against DA (like using SQLite3 virtual tables for cross-DB queries: a single select can join data from Oracle, in-memory objects and MSSQL, whereas the RA schemas are one-by-one mapping) or RO (like interface based services);
- RO is cross-technology, whereas mORMot is only for Delphi (the FPC port is coming);
- My tests with RO for communication between Delphi and .Net (some years ago) did show pretty slow response time (even locally);
- RO has a scripting engine for business rules, whereas mORMot expect all rules to be written in Delphi, in a DDD approach;
- RO / DA has more features than mORMot (like SOAP compatibility), and almost a decade of existence - its code is very proven, and told to be stable (even if RO performance is more marketing stuff than reality);
- The RO features page was down when I tried to read it - http://www.remobjects.com/da/features.aspx;
- The RO / DA online documentation is just... unavailable (their wiki is mostly void), whereas mORMot documentation is huge;
- RO is a huge number of units, difficult to follow and debug; whereas mORMot tends to be light and easy to read (with a lot of comments within the source code);
- mORMot works with any version of Delphi, even Starter, from Delphi 6 up to XE2;
- mORMot is free, open source.

I suspect RO /DA is more close to mORMot than RTC, which is just about communication.
But in its latest versions, mORMot has very nice features (like interface-based definition of services, and not from RODL).

leus · 2012-09-07 14:32:51

Hello,

Is it possible to have a good recipe or tutorial on moving a pretty standard Delphi Client-Server application to this framework? I think many Delphi developers (me included) would benefit of having a guide teaching them how to architect their code and, if possible, to port their old applications to this framework.

I know it is not an easy topic. I've been asking this to RemObjects for years (I bought a license but never got around to port my application to use DA.)

Regards,
Leonardo Herrera

ab · 2012-09-07 15:21:31

Did you take a look at the documentation pdf files?
See http://synopse.info/fossil/wiki?name=Do … umentation

The "Software Architecture Document" has precisely this kind of high-level design.
See http://synopse.info/files/pdf/Synopse%2 … 201.17.pdf

But it would definitively need to be enhanced - less theoretical, more like a "guide".
Don't miss the 2nd part of the pdf, that is, the "SynFile Main Demo" - around p. 750ss - which is some kind of tutorial.
I'm no English native, and writing pedagogical content needs a whole dedicated time.
This documentation tries to cover every aspect, from design down to the tiniest method or class, but it is far from perfect.
It will definitively need some more content and step-by-step especially about SOA design.
Perhaps with the upcoming "one-way callback" feature, we will take time to cover SOA and Event Sourcing/Collaboration more in detail.

I hope you will find in there some material to start with.

leus · 2012-12-28 19:12:31

Arnaud,

Your English is fine. While your document is frankly impressive, I'm quite sure that a "Migrate from client-server to N-tier in 10 steps" is something that would benefit this (and probably other) projects enormously.

What I envision is a document that tells me how to refactor my application without changing the underlying technology first, then switching backends. I know this is easier said than done, but it's the contention point I have to port my application (I need to have a running app at all times.)

Regards,
Leo

ab · 2012-12-29 17:41:25

Which kind of application is it?
How is the DB layered? (tables, size, relationships)
What about the UI? (clients, web, graphic, text)
Which kind of tasks is it about? (storage, reporting, searching)

To migrate an existing application, what you can do is preparing a working n-Tier / Domain Driven Design architecture, then use it from existing clients instead of direct DB access.
But you are right, this is a big task.

mORMot Open Source

#1 2012-04-25 08:32:51

The mORMot attitude

#2 2012-04-25 11:34:42

Re: The mORMot attitude

#3 2012-04-25 12:13:03

Re: The mORMot attitude

#4 2012-04-25 12:54:54

Re: The mORMot attitude

#5 2012-09-07 14:32:51

Re: The mORMot attitude

#6 2012-09-07 15:21:31

Re: The mORMot attitude

#7 2012-12-28 19:12:31

Re: The mORMot attitude

#8 2012-12-29 17:41:25

Re: The mORMot attitude

Board footer