mirror of
https://github.com/microsoft/BCQuality.git
synced 2026-10-07 23:56:56 +01:00
Normalisering af alle 39 custom knowledge-filer til READ-kontraktens skema (validate_frontmatter.py + Test-KnowledgeIndex.ps1 begge groenne): - R01/R02: 28 filer manglede frontmatter eller brugte aeldre skemaer (title/category/severity/rule-id m.fl.) - alle har nu praecis de 6 kraevede noegler; keywords haandskrevet pr. fil da de driver worklist-selektionen i INDEX/knowledge-index - R09: manglende Description-sektion - regel-agtige foersteoverskrifter (Core Rule/Rule/Regel/Core Principle) omdoebt, eller sektion indsat efter titlen hvor intro-tekst fandtes - R10: fenced code blocks konverteret til 4-space indrykkede blokke i alle filer (indhold uaendret) - R11: 4 filer over 100 linjer fortaettet redaktionelt uden semantisk tab (ai-eval-scores 143->100, git-lifecycle 121->97, permission-sets 113->99, test-feature-scenario-tags 105->91) - R05: AL0197->al0197, add_repo->add-repo; keyword-lister trimmet til maks 10 Ingen regler er fjernet eller aendret i betydning - kun form. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
47 lines
2.3 KiB
Markdown
47 lines
2.3 KiB
Markdown
---
|
|
bc-version: [all]
|
|
domain: architecture
|
|
keywords: [pages, business-logic, codeunit, separation-of-concerns]
|
|
technologies: [al]
|
|
countries: [w1]
|
|
application-area: [all]
|
|
---
|
|
# CURABIS Architecture: Page Presentation vs. Business Logic
|
|
|
|
## Description
|
|
|
|
In CURABIS codebases, pages serve exclusively as presentation layers. All business logic—including calculations, validations, and record modifications—must reside in codeunits, not in page triggers or actions. This standard is more rigorous than general Business Central guidance and applies uniformly across all CURABIS PTE applications.
|
|
|
|
## Key Principle
|
|
|
|
"A page procedure that calculates a value and assigns it to a field, calls `Rec.Modify()` directly, or implements business rules is an architecture violation even if it compiles."
|
|
|
|
## Permitted Exceptions
|
|
|
|
Two specific scenarios allow deviation from this rule:
|
|
|
|
1. **Setup Pages**: May directly read and write their own setup records
|
|
2. **Conversion Pages**: The designated "Run Conversion" page may invoke the conversion codeunit directly
|
|
|
|
## Anti-Pattern Examples
|
|
|
|
Pages should not contain:
|
|
- Direct calculations (e.g., `Rec."Total Amount" := Rec.Quantity * Rec."Unit Price"`)
|
|
- Calls to `Rec.Modify()` within page triggers
|
|
- Business rule validation logic embedded in page triggers
|
|
|
|
## Best Practice Implementation
|
|
|
|
Pages should delegate to codeunits for all business operations:
|
|
- "The page owns the presentation" while "The codeunit owns the logic"
|
|
- Use codeunit procedures (e.g., `SVManagement.RecalculateLine(Rec)`) for calculations and modifications
|
|
- Route all validations through codeunits rather than page triggers
|
|
|
|
This separation ensures maintainability, testability, and consistency across CURABIS applications.
|
|
|
|
## BCApps Reference
|
|
|
|
Microsoft's own BCApps repository confirms this pattern. In the Performance Toolkit, `BCPTSetupCard.Page.al` and `BCPTSetupList.Page.al` contain no business logic — all operations are delegated to `BCPTStartTests.Codeunit.al` and `BCPTHeader.Codeunit.al`. This is consistent across all BCApps pages.
|
|
|
|
- **Source:** https://github.com/microsoft/BCApps/tree/main/src/Tools/Performance%20Toolkit/App/src
|
|
- **Pattern:** Pages only bind data and invoke actions; codeunits own all state mutations and business rules. Microsoft applies this uniformly across thousands of pages in BCApps.
|