Just say that if you want to implement a known design pattern like Domain Driven Design, you will have all needed bricks available with mORMot to focus on modeling, and you will have to write much more code with Brook.

"Convention over configuration" means that web services, HTTP and REST are means, not goals.
The conventions available in mORMot allow to write some code without any knowledge of what a GET/POST/PUT is, or how routing is handled.
And if you need to tune the default behavior, you still can.

Silvio get it right: most of the complexity of the mORMot internal core comes from the "conventional" approach and "abstraction to technical details".
And, to be honest, the other main feature which included complexity in the implementation was our goal to performance and multithread friendliness.

What Silvio called "bureaucracy" in his post is that modern serious coding (e.g. DDD) is to uncouple your logic from the technical details by which it is implemented.
It is not "bureaucracy", it is 21th century software design.
For instance, your business logic code should be uncoupled from implementation details like transport, security, persistence, marshaling.

This is all about the SOLID principles, and rely on abstraction.
IMHO interface support, dependency injection, and  are mandatory for modern business project.
So that you can stub/mock any part of your application (DB, transport...) and maintain/test it.
It is mandatory for test-driven approach, and serious modern programming.

In short, you have several level of quality coding:

  • RAD approach, which mixes UI and logic/persistence with components;
  • OOP approach, which try to uncouple the tiers with classes;
  • SOLID approach, which rely on abstraction and uncoupling at all levels, with interfaces.

Brook is a clean OOP solution, but not SOLID.

SOLID design may be something new, as it is for most pascal developers.
If you was involved in serious software development in C# (or Java), as I was, you are perhaps already familiar with this set of design principles.
You may think SOLID is not worth it, and call it "bureaucracy" or "marketing stuff".
BTW, this is the reason why there is some mandatory design principles chapters in the mORMot documentation - take a look at the SAD 1.18 pdf.

And what Nick Hodges tried to introduce Delphi programmers in his latest book, "Coding in Delphi".
I still do not need generics or attributes as implemented in modern Delphi (which IMHO pollute the code), and find in FPC and Delphi 7/2007 syntax all that I need to write SOLID code.
But Nick advocates the same principles that drove mORMot's architecture, mainly DI and TDD.

I can assure you that SOLID is much more "practical" than regular OOP design.
My point of view is that mORMot SOLID design let you be much more productive than a regular OOP design, as offered by Brook.
Just try to write e.g. 10 small SOA services and consume them with clients in both frameworks, unit test them, and you will find out what I mean...
Thanks to Delphi interface features, you can write real SOLID code, and still benefit of object pascal strengths.

Brook, and even the current state of the FCL, or even the Delphi RTL, are just not able to follow the SOLID patterns, out of the box.
They only offer sets of classes, gathered by units, to do amazing thinks.
But you need external tools (like Spring4D or mORMot) to directly implement SOLID patterns, i.e. use interfaces with ease (dependency injection) and safety (weak reference pointers).
If I make mORMot compatible with Free Pascal, I guess it will even add a lot of features to the FCL, e.g. stubbing/mocking and such.
It could benefit to the community!

Ensure you took a look at the slides we shared about all those design principles.
By the way, thanks Bill for the review!

Feedback is welcome in our forum, as usual!
Any help for porting mORMot to FPC, and gives us some motivation is welcome.