SOA Interface-Based Services with Daemon Backend#435
Merged
synopse merged 44 commits intosynopse:masterfrom Apr 5, 2026
Merged
SOA Interface-Based Services with Daemon Backend#435synopse merged 44 commits intosynopse:masterfrom
synopse merged 44 commits intosynopse:masterfrom
Conversation
- Add SOA DTO types (TDtoInvoiceDetail, TDtoInvoiceSave, TDtoDashboardStats, TDtoCustomerSummary) and DynArray types to rgDtoTypes.pas - Move result enums (TCustomerEditResult, TInvoiceEditResult, TPaymentResult) from rgClient.pas to rgDtoTypes.pas for interface independence - Create rgServiceInterfaces.pas with 5 SOA interfaces (IRgCustomerService, IRgInvoiceService, IRgPaymentService, IRgStatisticsService, IRgReportService) - Create rgConfig.pas (TRgConfig via TSynJsonFileSettings for local/service mode) - Add HttpPort and ConfigFileName constants to rgConst.pas - Update Rechnung.lpr, RechnungDelphi.dpr, and Rechnung.lpi with new units - Add SOA implementation plan document Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Create rgServiceImplementation.pas with all 5 TInjectableObjectRest service classes (Customer, Invoice, Payment, Statistics, Report) and implement TRgPaymentService.AddPayment and GetInvoiceOpenAmount. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
ListCustomers, GetCustomer, CreateCustomer, UpdateCustomer, DeleteCustomer, and GenerateCustomerNo — ported from rgClient.pas iterator pattern to stateless SOA batch query + DTO mapping. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
InvoiceService: CRUD for invoices with item collection mapping, order number generation, and status calculation. StatisticsService: dashboard stats via combined SQL aggregations, customer summary with invoice/payment statistics. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Open items report with JOIN, date/amount filters, days overdue calc. Payment receipts report with AmountPaid > 0 filter. Customer revenue report with GROUP BY and year filter. Monthly overview with TTimeLogBits month extraction and totals row. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
B.6: Create rgServer.pas with TRgServer (TRestServerDB subclass, 5 ServiceDefine calls for all SOA services). Phase C: Implement RechnungDaemon.dpr (.dpr for Delphi 7 + FPC dual-compiler support) with TRgDaemonSettings, TRgDaemon (Start/Stop), and CommandLine entry point. Includes .lpi for Lazarus builds. Tested --console mode on Linux. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Add TRgServiceClient with local/service mode constructors and expose RgServices global. Adapt payment, customer list, and invoice list forms to use SOA interfaces (array-based API) instead of old iterator pattern. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…rms to SOA Completes remaining Phase D client adaptations: - D.3: Report forms use RgServices.ReportService with batch array pattern - D.4: Main form dashboard uses GetDashboardStats/GetCustomerSummary DTOs - D.5: Customer edit form uses GetCustomer/CreateCustomer/UpdateCustomer DTOs - D.6: Invoice edit form manages local FItems array, uses GetInvoice/CreateInvoice/UpdateInvoice Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…hitecture Document the client-server SOA architecture (local/service modes, 5 interfaces, daemon usage, config file) in both CLAUDE.md and README.md. Add rgServiceImplementation.pas and rgServer.pas to Rechnung.lpi. Mark D.7 tasks as done in SOA implementation plan. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…to-mdforms Feature/integrate mdlayout into mdforms
…to-mdforms Updated - Delphi 7 fixes
Contributor
Author
|
Now, step 3 is ready as well. |
Contributor
Author
|
If that’s too much effort and the benefit for this repo isn’t sufficient, would it be an alternative to move project number 10 into its own repo and just link to it here? |
Contributor
|
Just my 2 cents: to me this looks awesome |
synopse
approved these changes
Apr 5, 2026
Owner
|
Nice sample, and AI usage by the way! Do you have any article, maybe with screenshots to show, out of curiosity? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Step 1 was to get the sample running at all.
Step 2 (this change) is the transition to a service‑oriented client–server architecture.
Step 3 will be an improvement of the UI towards platform‑independent, responsive forms.
You do not need to review every single change.
I only ask you to verify the essential mORMot parts:
• Database design and data transfer objects
• Service implementation
• Handling of data types and conversion between mORMot types and UI types
Does this match the current mORMot design?
Can I use it as a reference implementation for myself (and maybe others)?