Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
irene33941yController is the place for business logic. Assuming it is route/controller/service api architecture.
-
Yeah... I'm so confused now. You usually always do Business logic in the controller, and database logic in a Repo. You obviously wouldn't do it in the factory... So idk where next you would put the logic. Help me out here.
-
irene33941yI guess define things. I most often make multi-tiered REST services. That is presentation/logic/data layers.
Presentation layer is the interactions that someone's client does at a route. Middleware builds a meaningful request context. The client can't interact with the data directly, and probably never knows what that data looks like or where it lives; they just build against the api version. Controller handles parse, validate, determines the action, initiates an action, and converts the response into something useful. Validate may need info from service layer. Service layer performs the action to get/set data from external apis, DBs, serverless functions, or etc.
That way the client can do simple actions without knowing or caring about how the work is done. You can make changes as much as you need and the client never needs to change until you release a new api version. -
irene33941yIf you just need a route to set or get directly use GraphQL. Since I build multitenant apps, and organizations have parent or child orgs, there is usually a bunch of info for the user in a JWT on the request. You then need to be sure that data access is scoped to their org, or child orgs, and that ends up being validation business logic in the controller because you probably won't provision thousands of users for a DB or whatever.
-
@iSwimInTheC It largely depends on what you see as a controller.
Lets assume conventional model-view-controller.
In my general interpretation, model is where I would suspect the core logic to reside. The controller receives user input, be it via a text field in the context of a ui or as some json payload for a REST API and converts it to a structure/command that is forwarded to model which applies it.
Do be honest the most important thing in architecture generally is to draw clear boundaries between logic that is integral to the application and any external technologies used (storage (databases, disk, ...), transport (REST, gRPC, ...), ui technology (QT, GTK, ...), etc.). This way you can exchange the technologies used without having to rewrite the entire application. -
There is some confusion here.
LAYER 1, controller: takes HTTP requests and forwards them to LAYER2
LAYER2: contains business logic and read data from\writes result to a db using a LAYER3
LAYER3 repository
You could call the business logic from jobs, from console, from RPC calls and whatever you want; the controller is just whatever takes care of reading HTTP requests and translate them into something you feed to a service. Which in turn uses the repository for long term storage; results might be sent to a db, to a file, to an entirely different API altogether and you wouldn't care. -
irene33941y@IHateForALiving
your layer 1 would be routing layer in my world
Your layer 2 would be controller layer in my world
Your layer 3 would be service layer -
What exactly is business logic? I’ve seen several different definitions of what it is ranging from the number crunching at the model layer to the more client facing stuff like login workflows (login failed? User sees messsge like “invalid password”).
-
My team’s arch uses controllers as dumb receivers of http requests which extract url params or query strings from the requests, calls whatever services are needed, and packs up the output as JSON back to the client. Not saying it’s the “one way” but it’s how we roll the dice
-
@TeachMeCode it's also how we decided to develop the feature I'm talking about. Which held true until someone started littering code around.
-
People generally get promoted to one or two positions above what they are actually component for
> ticket comes, new feature is requested
> create the new feature from scratch. Code is neatly splitted in files and methods, each with clear responsibilities
> every method is documented, there are clear service layers for the business logic, which resulted in controller having 10 lines of code, give or take
> commit the whole code, everything works
> check the develop branch today, team leader littered business logic in the controllers because "the codebase is a mess anyway"
rant