Clear separation of components

berocoder · 2017-07-04 06:07:35

Hi, I working in a small team. First we use Indy. Then ICS and now mormot.

The reason we not realize mormot is good for networking is that we saw it as a ORM framework. We use Bold for Delphi for that part. So I suggest to make a clear separation in documentation of this. Code quality is excellent.

ab · 2017-07-04 06:55:43

Historically, it started as a RESTful ORM.
So it was a client-server ORM since the beginning.
Then it evolved into a full-featured SOA, MVC then DDD framework.
And its ORM is not the most complete of all - it focuses on CRUD operation over REST/JSON.

You are right, this networking ability is not obvious...
We have observed how a lot of users discovered mORMot in a brasilan performance test against DataSnap.
When TMS introduced their network layer, they followed our technical choices when they introduced sparkle (about http.sys, but not how in the main design of their stack, in which the ORM is above the network layer, whereas in mORMot the ORM is RESTful from the ground up, which makes a huge architectural difference - and benefit from our experiment).

We tried to present the feature set everytime the project is introduced as "Synopse mORMot is a Client-Server ORM/ODM and SOA MVC framework".
See for instance the main framework presentation in the documentation and even the presentation in the forum index.

The misunderstanding about mORMot comes certainly from the fact that most technologies are split into several frameworks: for instance, you need to join WCF, EF and ASP.NET under DotNet or J2EE, Hibernate and JSF under Java.
The deep integration of the mORMot framework components is one of its great advantages (in terms of performance and efficiency), but it is so unusual that it seems unbelievable.
The closest well-known project to mORMot may be the Java Spring Framework. In fact Spring4D tends to add new features (like an ORM), but it historically mimics Java/DotNet generic-based libraries, and is mostly used for that purpose.
It is worth writing that using ALL mORMot bricks is not mandatory. You could use only its SOA, not its ORM, or its MVC feature set, not its other parts...

May we have to change the framework name, which include the "ORM" letters ?
Do we have to present mORMot as a set of components, finding a name for the ORM, another for SOA, another for MVC, another for PDF, another for Logging, another for Cryptography, etc... ?
Why not? Especially since we need a new official release, and general source some code refactoring.

Perhaps anyone may propose here some naming patterns, to make components names appear as a family.

edwinsn · 2017-07-04 07:17:38

@ab,

I believe changing the name mORMot will take a lot of work and might introduce confusion since the name's been in use for so many years.

Maybe what we need is a simplified overview and getting started document written from a different perspective, or a lightweight wrapper around mORMot

cybexr · 2017-07-05 02:06:40

Good idea ! Like apple reinvent phone, mORMot is a great framework, we can say ab reinvent Delphi :-)

As ab said, The deep integration of the mORMot framework makes it unusual and it seems unbelievable. The Java Spring project divied into sring MVC, spring Cloud, spring Data, spring Security ... and each of them can be used alone. Well refactoring will make mORMot more developer friendly and more persuasively.

maybe such subprojects could be introduced:
mORMot RTL - rawutf8 dynarray docvariant ... from SynCommons.pas
mORMot JSON- fast Json enc-dec from SynCommons.pas
mORMot REST- core C/S ORM, TSQLRest client server storage .. from mormot.pas
mORMot SOA- interface based service from mormot.pas
mORMot SQL- remote db ... from syndb.pas
mORMot noSQL- mongo db
mORMot NET- core http-communication, http.sys, iocp epoll ...
mORMot security- AES HMAC SHA JWT... from SynCrypto.pas
mORMot C- sqlite3 openssl ecc .. some C project, like FPC said write once compile anywhere, C&Pascal are best friend.
mORMot Report - pdf based report generation
mORMot MVC- mustache based MVC

ab · 2017-07-05 07:10:41

+
mORMot TDD - SynLog and SynTest
mORMot Daemons - mORMotService.pas
mORMot DDD - mORMotDDD.pas

We will end-up with such a huge list!
Perhaps make a project hierarchy:
mORMot RTL
mORMot Data
mORMot C/S
mORMot MVC
???

hnb · 2017-07-05 07:49:30

ab, did you forgot about our initial list of packages?

mORMot_Commons, mORMot_SQLite3 (+ mORMot_SQLite3Static), mORMot_DB, mORMot_REST, mORMot_DDD, mORMot_MVC, mORMot_PDF, mORMot_UI, mORMot_CrossPlatform, mORMot_ZEOS

https://github.com/maciej-izak/mORMot/t … s/Packages

ab · 2017-07-05 08:06:15

@hnb
Yes, it did make sense!

What about finding nice names for them?
Or just define some high-level names for the feature sets (at marketing level), and let the source code remain stable?

hnb · 2017-07-05 08:19:24

Generally ORM systems are known as slow solutions but mORMot is fast so... maybe new namespace FastORM for ORM related stuff? I like dotted namespaces. So for me for example FastORM.Commons would be best . Anyway most important for me is separation to packages whatever the name is.

cybexr · 2017-07-05 14:15:51

mORMot framework is definitely productive framework and highly optimized ,to build an enterprise software with compiling programming tools (C C++ Pascal Java .net ) , maybe mORMot is the best. But somehow, it is not friendly to newbie (lacks of production-demo; SAD is comprehensive but feels like a well-builded churh, grandness but scaffold is disassembled, we can't figure out how it was builded).
eg: the mormot.pas is so complicatd , there are cornerstone class(TSQLRest, TSQLRecord),and also lots of aided classes(TSQLRestServerMonitor, TSQLRecordServiceLog). from my personal perspective, make some separation between the core and the assistant maybe seems like more reader-friendly and more maintainable.

leus · 2017-07-06 14:28:32

I'm loving this thread!

edwinsn · 2017-07-07 08:44:21

That must involve a great amount of refactoring work, if ab go for it.

berocoder · 2017-07-07 19:11:35

Think the perspective of a team or developer that are not aware of mormot.
They maybe only need json, ORM or network functionality.
Make it clear in the documentation with a quick start how to get progress.

Then I don't bother if internal changes in mormot is needed.
Hopefully you get my point.

sevo · 2017-07-14 14:27:32

I'm fine with the internal structure / modules!

Imho we need documentation of the url schema, like for example here: https://postgrest.com/en/latest/api.html.

And someone should finish the openapi/swagger integration.

afarias · 2017-07-14 18:56:46

edwinsn wrote:

@ab,
Maybe what we need is a simplified overview and getting started document written from a different perspective, or a lightweight wrapper around mORMot

I second that.

For instance, trying to use only SOA part of Mormot it's exausting (at start) for a newbee as there are so many things mixed up.

Regards,

ab · 2017-07-15 08:13:49

Is the SOA sample not simple enough?

mORMot Open Source

#1 2017-07-04 06:07:35

Clear separation of components

#2 2017-07-04 06:55:43

Re: Clear separation of components

#3 2017-07-04 07:17:38

Re: Clear separation of components

#4 2017-07-05 02:06:40

Re: Clear separation of components

#5 2017-07-05 07:10:41

Re: Clear separation of components

#6 2017-07-05 07:49:30

Re: Clear separation of components

#7 2017-07-05 08:06:15

Re: Clear separation of components

#8 2017-07-05 08:19:24

Re: Clear separation of components

#9 2017-07-05 14:15:51

Re: Clear separation of components

#10 2017-07-06 14:28:32

Re: Clear separation of components

#11 2017-07-07 08:44:21

Re: Clear separation of components

#12 2017-07-07 19:11:35

Re: Clear separation of components

#13 2017-07-14 14:27:32

Re: Clear separation of components

#14 2017-07-14 18:56:46

Re: Clear separation of components

#15 2017-07-15 08:13:49

Re: Clear separation of components

Board footer