You are not logged in.
- Topics: Active | Unanswered
Pages: 1
#1 2014-10-27 11:43:10
First impressions on mORMot - from EMB forums
Maxim Shiryaev did post a nice question in the EMB forums.
See https://forums.embarcadero.com/thread.j … 225#676225
Here are my answer, which may help others:
Your remarks do make a lot of sense, and reflect a lot of thinking when you come from RAD background in Delphi, and only used mainstream Java or C# frameworks.
Is it your case?
mORMot took a diverse path. Not perfect, but we had our reasons, and we are always trying to make it a better framework.Maxim Shiryaev wrote:The main problem, IMHO, is that a perfect tool should work with PODO (plain delphi objects) not requiring to descent from some library-defined class.
The fact that it requires its persisted objects to inherit from TSQLRecord allows to rely on the strong "typeclass= class of type" syntax, and offers a lot of common methods at class, model or REST instance level.
It follows the "layered super type" paradigm of DDD, for the persistence layer. See http://martinfowler.com/eaaCatalog/layerSupertype.htmlI really like the "typeclass= class of type" syntax, which allows to write "typeclass.Create" and indeed create one instance of the expected class.
C# or Java have to use generics for such patterns, whereas the Delphi syntax is IMHO much cleaner.But directly persisting your business PODO is not a better option.
Sounds easier to work with, at the beginning, but your PODO starts being polluted by attributes, so you are mixing persistence information and business logic.
Not a clean design, for sure!Furthermore, it is a good common practice to have your persistence objects not being your business objects.
In DDD, you persist only the aggregate objects, for instance. Which may be perfectly be TSQLRecord instance, since it is part of the framework.In fact, our ORM is more a micro-ORM (like in RoR Active Record) than a fully featured (and complex) ORM like Hibernate.
And it supports NoSQL backends, so is not tied to SQL.Maxim Shiryaev wrote:And a requirement of a very specific string type is a problem as well.
About string type, there is NO requirement.
You can use plain string.
It is just that the RawUTF8 type would be more optimized for the business layer, since it would avoid UTF-16 conversion.
And it will help to ensure that you won't "leak your domain" - see http://msdn.microsoft.com/en-us/magazine/dd419654.aspxFor DDD patterns, see http://blog.synopse.info/post/2014/01/0 … %3A-part-1
Maxim Shiryaev wrote:So, a system designed for mORMot will be over-vendor-locked.
In a layered architecture, especially in DDD, you may benefit from not reinventing the wheel.
On the contrary to be "vendor-locked", Open Source projects are much more open to modification.
You would be much more likely to include your own needs to an Open Source framework.
We are no "vendor"!
You can fork our project in one click on GitHub!
Our tri-license terms are very permissive.AFAIR we never reject any new feature, well designed and tested, submitted by users.
On the contrary, you can find in mORMot some awesome features, coming from the outside (e.g. JavaScript/SpiderMonkey inclusion, Linux support...) and a lot of fixes!Maxim Shiryaev wrote:If this vendor is the main tool vendor (Embarcadero in this case) it's OK, but heavy (really heavy) dependence on third-party is not as good, IMHO.
Depending on an Open Source project is IMHO much better.
Do you remember Bold? Embarcadero owns it, and stopped the support.
And Open Source projects are not polluted by (short term) benefit needs: you are not forced to buy every new version of the compiler and third party to get the hotfixes for instance, and mORMot works and is tested from Delphi 6 up to XE7.
Of course, if you have a newer version of Delphi, you benefit from it, in mORMot (you have methods using generics, or use of the enhanced RTTI, if available).Maxim Shiryaev wrote:So I expect from a 3-5K USD priced product to provide all the neccessary frameworks in a box and with normal performance.
If the product is a compiler + IDE, frameworks should better NOT be part of it, in my opinion.
Even in .Net, some is part of the runtime (like WCF), but some is not (like EF) - and you can use alternatives.Maxim Shiryaev wrote:Or at least to publish some frameworks as specifications for the third-party to implement. So that third-party libraries could pluged and changed with minimal efforts.
Welcome back J2EE!
But if mORMot did have followed EMB specifications, we would have used webbroker, DB.pas, RTL and would have written much more complex code, and also resulted in much lower performance.
We would have to follow the awful JSON format generated by DataSnap.Honestly, I doubt EMB would be able to define any specification, since even their their products are (almost) undocumented, with varying specifications...
I can assure you that we are fighting sometimes low level RTL bugs for hours, especially since we support a wide range of Delphi versions.
By-passing the RTL, with our own set of regression tests, saved us a lot of time!And if you want to support new targets (like MongoDB), it may be so difficult if the specification was designed for SQL.
Specifications are outdated as soon as they are published...
Even in Java (or C#), you have mico-frameworks alternatives, which get rid of J2EE, which has its own issues.Maxim Shiryaev wrote:And thanks for the PDF lib! It's great too, epsecially to export FastReport reports with rich text that FR exports as images.
This is another part where a lot of external contributions were given.
We can thank all contributors!
Offline
#2 2014-11-15 07:43:47
Re: First impressions on mORMot - from EMB forums
Hi Ab,
I have been looking at mORMot for a bit, studied the SAD document and looked at the Code Samples, and I have some code structure questions:
1. I get the TSQLRecord is effectively your storage layer, so my business objects should be using TSQLRecord descendants to manipulate and query persistent objects, correct? What is the mechanism then, to use the same Business Object Model on both Client and Server, as implemented in mORMot?
2. How transparent can one make this to be able to scale from single to n-tiers, with no code changes?
3. Even though you discuss it in the SAD I do not see any implementation of dependence injection in the framework. Is this by design?
I am missing a sample to show how to properly structure a potentially huge project.
Kind regards,
Willo vd Merwe
Offline
#3 2014-11-15 09:13:04
Re: First impressions on mORMot - from EMB forums
1. You just define a shared data model - TSQLModel between client and server, then use the abstract TSQLRest operation on each side.
2. Since almost everything could be used from an abstract TSQLRest class, you can use the same code in a stand-alone, server-side or client-side application.
The only code change is which class you create for your TSQLRest: TSQLHTTPClient or TSQLRestServer.
3. There is of course dependency injection built-in in the framework, by using interface based services.
4. Sample https://github.com/synopse/mORMot/tree/ … M%20Server is a good way of understanding how to use the framework.
Then sample https://github.com/synopse/mORMot/tree/ … 20services and https://github.com/synopse/mORMot/tree/ … %20service show how to use interface based services (and DI).
Yes, the documentation is huge, but all your questions were answered there, I suspect.
See http://synopse.info/files/html/Synopse% … 01.18.html - especially the FAQ and the search the table of content (you can search on the web page, or use the Keywords entry).
Thanks for your feedback!
Offline
Pages: 1