You are not logged in.
Pages: 1
hi,ab
1. Project type and goals
- The project uses the MVC pattern to provide views/pages to the web, and at the same time exposes business services to multiple clients (AJAX from web frontends, PC clients, mobile apps, etc.) via interface-based methods.
- The goal is to centralize business logic in the interface-based methods so different clients can reuse it.
2. Code structure (simplified)
I split the TBlogApplication class into multiple classes: TUserApplication, TArticleApplication, TCommentApplication, … each handling different functionality.
Then I implemented interface-based methods, for example:
TUserManager = class(TInjectableObjectRest, IUserManager)
TArticleManager = class(TInjectableObjectRest, IArticleManager)
…
3. Call chain
- Frontends (web pages or AJAX/APP) call the Manager methods (the interface-based methods) to execute business logic.
- In the MVC scenario, Controllers may also call these Manager methods internally to reuse logic (i.e., MVC -> manager calls, not via HTTP requests).
Authentication and authorization status
1. MVC scenario authentication: uses CurrentSession (session mechanism), managed by the MVC framework to maintain user login state during page access.
2. REST/interface scenario authentication: uses TRestServerAuthenticationDefault.
3. I put all business logic into the interface-based Manager methods, which are called directly by external clients and also reused internally by MVC. This creates problems with authentication and context (Session/Principal/Identity) consistency.
Question 1: Is the approach above correct? Or is there a better solution?
Question 2: Because MVC also calls the interface-based methods and various frontends call them too, how should authentication be handled in this situation?
Question 3: Also, is my approach of splitting the TBlogApplication class the right direction, or is there a better solution?
Offline
1. My only concern is that you start from the data (User/Article/Comment), not the use cases.
IMHO there is an application layer missing. Or even a domain layer. From what you describe, you publish a persistence layer to the end user.
2. MVC Authentication is indeed not compatible with the regular TRest Authentication, on purpose.
You seem to be willing to handle authentication at persistence level, per kind of data, at 'I*Manager' services level - it does not make sense in practice.
If you start from the use cases, not the data, then authentication would make more sense.
MVC or REST/RPC services should handle the authentication at their own layer, in the application logic, or with a dedicated service.
3. See point 1.
Look at https://github.com/synopse/mORMot2/tree … dd-service
In the main ReadMe file, I spoke about "Clean Architecture".
Online
Pages: 1