0

I'm implementing an application using mORMot with Delphi from an existing client-server app that is using a Firebird database with a lot of stored procedures dealing with updating some tables and querying very complicated data. It would take too long to reimplement and move everything from the database to the application side.

I have no idea what to do. Anyone, please help to guide me on how to use - call Firebird stored procedures on mORMot. (It would be great if there is an example.)

Pluem Saan
  • 25
  • 5
  • [Its documentation](https://synopse.info/files/html/Synopse%20mORMot%20Framework%20SAD%201.18.html) suggests it is possible (see chapter 13), but it is very light on the details. – Mark Rotteveel Sep 29 '20 at 14:56
  • Why mORMot then? If you are using traditional non-ORM dataabase design, then perhaps other libraries, traditional client-server ones, would make more sense? Unified Interbase, FireDAC, DB Express, FIB+ (commercial and seemingly dead), IBObjects, etc. `mORMot` has its own very strong view on how the system (program and database) should be designed and should be working. Using mORMot for different approach would create a huge gap you would have to bridge. So unless you gonna restructure the database itself too - i believe mORMot would be wrong choice here – Arioch 'The Oct 01 '20 at 15:09
  • 1
    @Arioch'The mORMot is not just an ORM. It has a very powerful SOA layer, based on interfaces, which is great for building strong client-server apps. You can use the SOA layer without the ORM, and existing SQL data access layer, with huge benefit. You don't need to write a full DDD project. Just define services using interfaces and classes, with minimal coding (much less than DataSnap for instance). See my answer below. And the last link in particular. – Arnaud Bouchez Oct 05 '20 at 20:04

1 Answers1

3

Stored procedures are great to access the database directly, but they are a nightmare for modern design. So there is no direct/native way of running stored procedures in mORMot, because it doesn't make sense with an ORM design, and modern SOA/Microservices/DDD architecture.

What you could do with mORMot and your existing project is for instance:

  • Create a first layer of reusable "business/model" services using several interfaces - your own "logic toolbox";

  • Let the implementation classes of those interfaces call the existing stored procedures using your existing FireBird access library;

  • Publish the "business/model" layer services using another set of public REST endpoints, using mORMot interface based services, and fined REST interfaces with simple DTOs;

  • Let the new forms of your client app switch from RAD into this n-Tier/REST design, calling this new mORMot interface based services if possible;

  • Consider writing some new client code, maybe from a JavaScript REST/JSON client (you may use a third-party company for that);

  • Take a look at the mORMot Web MVC layer - php-like feature of the framework - which may help writing some dynamic web pages from your existing "business/model" layer;

  • Consider using the mORMot ORM for new tables and new data, perhaps switching to a MicroService architecture with its own SQLite3 persistence layer (or still Firebird is you really want, but you could switch using the ORM);

  • Benefit for a lot of cross-cutting features of the framework, like logging, pdf or JSON processing.

Take a look at the documentation FAQ, and ask in the mORMot/Synopse forum.

Check for instance:

Arnaud Bouchez
  • 42,305
  • 3
  • 71
  • 159