May 2012 (5)

2012-05-28

Synopse mORMot Framework 1.16

Our Open Source mORMot framework is now available in revision 1.16.

The main new features are the following:

Thanks to its features, mORMot is now able to provide a stand-alone Domain-Driven Design framework for Delphi.

Quite a long and nice road for a little mORMot, and more to come!

Continue reading

Is marketing the new native?

In a very nice (like always) blog post, trolling comments were dispatched about the "native" concept:

From the technical point of view, both assertions are false.

The article was subtitled: "Say a Lie Often Enough and You’ll Start Believing it Yourself".
At least, it is a trolling subject.

It remembered me about some of my past studies, i.e. five years of university studies in Medieval Theology in Italy and France (yes, I know, this is strange background for a Delphi programmer):

"Stat Roma pristina nomine, nomina nuda tenemus"

Our modern world is not thinking any more, it is sinking into nominalism, whereas IMHO the scientific approach is more compatible with a realistic approach of universals.

Today, marketing is everything.
Is it a necessary evil?

Continue reading

2012-05-25

Domain-Driven design

With a previous article, we introduced the concept of "Domain-Driven design" into our framework presentation.

It's now time to detail a bit more this very nice software architecture design, and how mORMot is able to achieve such an implementation pattern.

Continue reading

2012-05-20

Recursive calls and private objects

In a Stack Overflow question, someone asked about some nested procedure call he found out. That is, a procedure inside another procedure.

He found out this coding style to be messy, which sounds like a reasonable opinion. But his alternative proposal of putting the internal procedure outside the main one, i.e. making it global, is IMHO even worse.

In some case, a private class, or even record or object with methods is an handy and maintainable implementation pattern.

Continue reading

2012-05-03

Custom JSON serialization of records

By default, during interface-based service call, any record parameter or function result will be serialized with our proprietary binary (and optimized layout) - i.e. RecordLoad and RecordSave functions - then encoded in Base-64, to be stored as plain text within the JSON stream.

But custom record JSON serialization can be defined, as with any class - see this article - or dynamic array - see this article.

Continue reading