Using interfaces is indeed a bit difficult if you want to browse the code, as mpv says.
A similar issue exists when you use virtual methods: the exact method which will be executed is defined at run time, not at coding time: Ctrl+Click on a virtual method will lead you into the same level class implementation, even if it will be overridden in the actual class, during real process.
Therefore IMHO interfaces can be seen as "classes with only-virtual-methods".

If your interfaces are defined following SOLID principles, and if you take a look at the implementation, just as usual, it is easy to work with.
And mocking/stubbing helps testing your code, especially in test-driven mode, with a clear domain-driven design for instance, where each layer has a clear responsibility.
If your interfaces are decoupled and small, with clear focus, it is no problem for them to be virtual. And this is during testing phase that you will focus on the implementation.

Mpv's remark about .NET kind of coding does make sense to me.
It is exactly what I see every day.
You can do wonders in .NET (and in Java), reaching amazing speed and efficiency.

But if you use those frameworks and write code using the "black box" approach (which is fairly common), you may start forgetting about the implementation.
I think a majority of .Net coders do suffer from it, even worse for "young" coders. As a result, the code logic is there, but the code efficiency is not. And it is even worse if you use LINQ for objects, and such patterns: you get the information you need, but may retrieve the whole database content just to get one small data.
Huge performance problems and scalability issues come directly from such blindness.

With mORMot, we tried to give at hand all means of producing fluent and efficient code:

  • Framework core was designed with performance in mind;
  • High-level patterns are included (CRUD, Batch, caching, services, routing, security, JSON serialization), and optimized, ready to be re-used;
  • You have some very efficient engines at hand (like TSQLRestServerStaticInMemory), if performance is needed;
  • Every framework aspect is decoupled: you can use some part of it (this is exactly what mpv does, AFAIR);
  • Framework makes layers, hosting and Domain-Driven-Design easy to implement and efficient to work with: you will never be afraid of decoupling your application logic, and with interfaces, it will be dead easy to maintain and make evolve your application;
  • Logging is integrated, including customer-side profiling: you will see instantly if a DB request is over-called, and find out real bottlenecks.

Within mORMot, KISS design was followed, without trying to re-implement what was done in C# or Java. Our framework just provides one mean of solving each need, in an integrated manner, and in the classic Object Pascal way - that is, all mORMot's classes have a similar syntax, documentation style, implementation pattern, and stick to the Delphi internals and computer's bare metal - you do not need to mix libraries (with potential redundant code and diverse syntax) to get your application work, and you can be sure that all your underneath hardware will be used.

Goal is to focus on business logic, not sink into implementation details.
Therefore, maximize your ROI.

I'm currently working on huge C# service design, in my day light work (are Delphi-ers the new vampires, working on Delphi projects, alone in the night?).
I found out how mORMot's KISS architecture to be less powerful than WCF/WAS/ISS - so many features at hand!

But quote often, .NET appears much more verbose and difficult to work with. It clearly suffers from the "black box" syndrome mpv talked about.
Just try to write a remote WCF service: you will have to write a proxy access code on both sides, with one endpoint per interface. So much plumbing! Search the Internet for the pattern, then copy & paste! A nightmare!
mORmot, on the other hand, favors convention over configuration, which is known to save a lot of time (if you use WCF on a daily basis, as I do, you and your support team know about the .config syndrome).
Just compare with mORMot's ServiceRegister() methods on both client and server side, and you'll be convinced.

I do not say that mORMot is easy to work with.
You need to be able to play with some abstract concepts, and probably have some knowledge of memory management and performance optimization.
But all framework source code is available, deeply commented and documented.
Some users are now proposing patches and enhancements, which is a very good sign for an Open Source project!
Thanks all for your interest!

Feedback is welcome on our forum.