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.
interfaces can be seen as "classes with
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
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
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
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
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
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
Just compare with mORMot's
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.