EKON 24 just finished. "The conference for Delphi & more" was fully online this year, due to the viral context... But this was a great event, and I am very happy to have been part of it. Please find the slides on my two sessions: mORMot 2 Performance: from Delphi to AVX2 Of course, […]
Tag - SOLID
2020-10-26
mORMot2 Renaming
2020-10-26. Open Source › mORMot Framework
Last weeks, we introduced REST, ORM and SOA process in the mORMot2 repository.
During this phase, we split the huge mORMot.pas
unit into several mormot.rest.*.pas
, mormot.orm.*.pas
and mormot.soa.*.pas
units, to follow SOLID principles.
But we also renamed the base types into something more consistent and easier to work with.
Forget about TSQLRecord
or TSQLRest
, discover TORM
and TRest
!
2017-10-24
EKON 21 Slides
2017-10-24. Open Source › mORMot Framework
After having enjoyed EKON 21 conferences in Köln, some quick post to share material about my presentations. MicroServices: SOLID Meets SOA MicroServices: Event-Driven Design Practical Domain-Driven Design I also included the "Practical DDD" source code in a new sample folder of the mORMot […]
2016-11-10
EKON20 mORMot Conferences
2016-11-10. Open Source › mORMot Framework
EKON20 is now over, and there was a lot of people, great speakers, beautiful T-Shirt, and fresh beer! I've published the slides of my mORMot conferences on SlideShare... EKON20 From RAD to SOA with mORMot EKON20 mORMot Legacy Code Technical Debt Delphi Conference EKON20 Ride a mORMot EKON20 2016 […]
2015-11-17
Benefits of interface callbacks instead of class messages
2015-11-17. Open Source › mORMot Framework
If you compare with existing client/server SOA solutions (in Delphi, Java,
C# or even in Go or other frameworks), mORMot's
interface
-based
callback mechanism sounds pretty unique and easy to work with.
Most Events Oriented solutions do use a set of dedicated
messages to propagate the events, with a centralized Message
Bus (like MSMQ or
JMS), or a
P2P/decentralized approach (see e.g. ZeroMQ or NanoMsg). In practice, you are expected to
define one class
per message, the class
fields being
the message values. You would define e.g. one class
to notify a
successful process, and another class
to notify an error. SOA
services would eventually tend to be defined by a huge number of individual
classes, with the temptation of re-using existing classes in several
contexts.
Our interface
-based approach allows to gather all events:
- In a single
interface
type per notification, i.e. probably per service operation; - With one method per event;
- Using method parameters defining the event values.
Since asynchronous notifications are needed most of the time, method
parameters would be one-way, i.e. defined only
as const
- in such case, an evolved algorithm would
transparently gather those outgoing messages, to enhance scalability when
processing such asynchronous events. Blocking request may also be defined
as var/out
, as we will see below, inWorkflow
adaptation.
Behind the scene, the framework would still transmit raw messages over IP
sockets (currently over a
WebSockets connection), like other systems, but events notification would
benefit from using interfaces, on both server and client sides.
We will now see how...
2015-06-01
Updated Slides about ORM SOA MVC SOLID DDD
2015-06-01. Open Source › mORMot Framework
One year ago, we published a set of slides about the main concepts implemented by our framework. Mainly about ORM (and ODM), NoSQL, JSON, SOA, MVC (and MVVM), SOLID, DDD, CQRS and some patterns like Stubs, Mocks, Factory, Repository, Unit-Of-Work. Worth a look, if you want to find out the benefits […]
2015-05-03
SOLID Design Principles
2015-05-03. Pascal Programming
I've just updated the documentation part about the SOLID Design
Principles.
The former blog article
(almost 4 years old!) sounds like a bit deprecated now...
This is why I would extract here an updated version of this material.
Ensure you checked the corresponding part of the mORMot documentation, which is the updated reference, and probably the easiest to read - including links to all the other documentation.
The acronym SOLID is derived from the following OOP principles (quoted from the corresponding Wikipedia article):
- Single responsibility principle: the notion that an object should have only a single responsibility;
- Open/closed principle: the notion that "software entities ... should be open for extension, but closed for modification";
- Liskov substitution principle: the notion that "objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program” - also named as "design by contract";
- Interface segregation principle: the notion that "many client specific interfaces are better than one general purpose interface.";
- Dependency inversion principle: the notion that one should "Depend upon Abstractions. Do not depend upon concretions.". Dependency injection is one method of following this principle, which is also called Inversion Of Control (aka IoC).
If you have some programming skills, those principles are general statements you may already found out by yourself. If you start doing serious object-oriented coding, those principles are best-practice guidelines you would gain following.
They certainly help to fight the three main code weaknesses:
- Rigidity: Hard to change something because every change affects too many other parts of the system;
- Fragility: When you make a change, unexpected parts of the system break;
- Immobility: Hard to reuse in another application because it cannot be disentangled from the current application.
2015-04-12
Why Transmitting Exceptions in SOA services is not a good idea
2015-04-12. Open Source › mORMot Framework
Usually, in Delphi application (like in most high-level languages), errors
are handled via exceptions. By default, any Exception
raised on the server side, within an interface
-based service
method, will be intercepted, and transmitted as an error to the client side,
then a safe but somewhat obfuscated EInterfaceFactoryException
will be raised on the client side, containing additional information serialized
as JSON.
You may wonder why exceptions are not transmitted and raised directly on the client side, with our mORMot framework interface-based services, as if they were executed locally.
We will now detail some arguments, and patterns to be followed.
2015-04-06
Asynchronous Service - WebSockets, Callbacks and Publish-Subscribe
2015-04-06. Open Source › mORMot Framework
When publishing SOA services, most of them are defined as
stateless, in a typical query/answer pattern - see
Service-Oriented Architecture (SOA).
This fits exactly with the RESTful approach of Client-Server
services via interfaces, as proposed by the framework.
But it may happen that a client application (or service) needs to know the state of a given service. In a pure stateless implementation, it will have to query the server for any state change, i.e. for any pending notification - this is called polling.
Polling may take place for instance:
- When a time consuming work is to be processed on the server side. In this case, the client could not wait for it to be finished, without raising a timeout on the HTTP connection: as a workaround, the client may start the work, then ask for its progress status regularly using a timer and a dedicated method call;
- When an unpredictable event is to be notified from the server side. In this case, the client should ask regularly (using a timer, e.g. every second), for any pending event, then react on purpose.
It may therefore sounds preferred, and in some case necessary, to have the ability to let the server notify one or several clients without any prior query, nor having the requirement of a client-side timer:
- Polling may be pretty resource consuming on both client and server sides, and add some unwanted latency;
- If immediate notification is needed, some kind of "long polling" algorithm may take place, i.e. the server will wait for a long time before returning the notification state if no event did happen: in this case, a dedicated connection is required, in addition to the REST one;
- In an event-driven systems, a lot of messages are sent to the clients: a proper publish/subscribe mechanism is preferred, otherwise the complexity of polling methods may increase and become inefficient and unmaintainable;
- Explicit push notifications may be necessary, e.g. when a lot of potential events, associated with a complex set of parameters, are likely to be sent by the client.
Our mORMot framework is therefore able to easily implement
asynchronous callbacks over WebSockets,
defining the callbacks as interface
parameters in service method
definitions - see
Available types for methods parameters.
Real-Time ORM Master/Slave Replication via WebSockets
2015-04-06. Open Source › mORMot Framework
In a previous
article, we presented how Master/Slave replication may be easily
implemented in mORMot's RESTful ORM.
Do not forget to
visit the corresponding paragraphs of our online documentation, which has
been updated, and is more accurate!
Sometimes, the on-demand synchronization is not enough.
So we have just introduced real-time replication via WebSockets.
For instance, you may need to:
- Synchronize a short list of always evolving items which should be reflected as soon as possible;
- Involve some kind of ACID-like behavior (e.g. handle money!) in your replicated data;
- Replicate not from a GUI application, but from a service, so use of a
TTimer
is not an option; - Combine REST requests (for ORM or services) and master/slave ORM replication on the same wire, e.g. in a multi-threaded application.
In this case, the framework is able to use WebSockets and
asynchronous callbacks to let the master/slave replication - see
Asynchronous callbacks - take place without the need to ask explicitly
for pending data.
You would need to use
TSQLRestServer.RecordVersionSynchronizeMasterStart
,
TSQLRestServer.RecordVersionSynchronizeSlaveStart
and
TSQLRestServer.RecordVersionSynchronizeSlaveStop
methods over the
proper kind of bidirectional connection.
2014-07-12
Static class variables are just global variables in disguise
2014-07-12. Pascal Programming
Cape Cod Gunny just wrote a blog article about how to replace a global variable by a static class instance.
But I had to react!
Using such static declaration is just another way of creating a global
variable.
This is just a global variable in disguise.
In fact, the generated asm will be just like a global variable!
It encapsulates the global declaration within a class name space, but it is
still IMHO a very wrong design.
I've seen so many C# or Java code which used such a pattern (there is no global
variable in those languages), and it has the same disadvantages as global
variables.
Just like the singleton
syndrome,
Code is just not re-entrant nor thread-safe.
Nightmare to debug and let evolve.
2014-05-30
Software Design, Brook, mORMot, RAD, SOLID and OOP
2014-05-30. Open Source › mORMot Framework
We got a very instructive
discussion in our forums, with Silvio, the maintainer of the
Brook Framework.
Brook is a nice framework for writing web applications using Free
Pascal.
It comes to my mind what mORMot can offer.
We did not want to compare the features or say that one framework is better
than the other, but it appeared to me that a lot of object pascal programmers
are tied to 20th century programming model.
In fact, to embrace the potentials of mORMot, you need to switch your mind, and enhanced your RAD and OOP background, into 21th century SOLID model.