ā How does one hold a value in a private field in a controller?
So basically controller gets created for every request right?
Problem is i have this field:
And i set it once the user creates a new lesson.
However if you call another endpoint that uses that variable it becomes null,
static wont do either as i read.
So how do you approach this?
58 Replies
Web servers are generally stateless
You'd normally pass a
lessonId
or such parameter with subsequent requests
And then load the lesson to do whatever it is you need to do with ityeah but
wont i have to make a DB call each time?
Yeah (unless you cache it)
I see
That's completely normal, though
So basically only services and managers go into the Di and into the service?
You've lost me there I'm afraid
and a few consts
well
consts? "in the DI" ?
this is what im talking about
So you've got a controller with all of those fields?
Its a service
thats way way way too much if thats a controller
nah thats the LEssonAppSErvice
so basically
all the private members gotta go?
For the most part, yeah
since i cant actually save em between requests unless they static
yes. and please dont put static data on a controller š
At what kind of level are you expecting this 'service' to live?
At the API level? At a lower domain level?
yeah its a work in progress
unsure what you mean
You mean the lifetime of the service? IDK?
basically its an app like whatsapp
but voice based
so a user logs in and stats a lesson
creates new ones on the fly etc
So is this a "domain" service as in any interface to your domain (a web API, a GUI, etc) can interact with it?
Or is this service specific to your API?
Its not a domain service no, and there is no real controller really
API/Auto API Controllers | Documentation Center | ABP.IO
Once you create an application service, you generally want to create an API controller to expose this service as an HTTP (REST) API endpoint. A typical API controller does nothing but redirects method
š
it exposes the service as a controller
Weird as hell but ok š
Remove everything that's a field that realistically depends on the request
e.g.
_currentLesson
Depend on the classes required to implement whatever functionality it is
And everything else should be a parameter coming from each request
(However that's wired up using whatever ABP is)
Whether as a parameter from the request itself or from a property of the session (e.g. user id)Ok thats good because i do have acess to the currentUser class
I was just tripping about all the DB calls
and the cost associated with getting that big ass json each time
because lesson is an aggregateroot
it pulls all its realted data
Phases answers questions etc
The cost of a database call generally pales in comparison to the HTTP roundtrip for the request anyhow
How many years you work with .net?
Err, 8?
oh thats nice
It's not, it means I'm getting old š
.net getting younger each year tho
the amount of features š
another thing
I'm waiting for proper ADTs to come across from F# to C# then I'll be happy.
If i create
a singelton with DI
then does it live basically from the moment i start the server?
no
and is the same for all requests till server shuts down
when its first resolved
Depends on how you register it
Then like phaseshift says, it's created the first time it's resolved
And then yes, the same instance will always be returned when it's resolved
Gotcha will have to change that then, OpenAi hallucinations are real
There's also an overload to register an instance
If you really wanted to control the instantiation
with an interface you mean?
oh yeah i dont need that lol
abp got a preconfigure methode
gets called first thing
So it basically registers it as soon as the server starts
Registers yes, instantiates when it is first resolved
Generally you can treat the two as the same
Oh yeah youre correct
But the actual
OpenAiManager
constructor won't be called until something asks the service collection for oneyup makes sense
Sounds like you've got it nailed
So basically
For each and every method?
you always cache as much as you can i guess
What dont you cache lets put it this way
And thx alot š
Caching is an extremely nuanced topic
What to cache, how long to cache it etc completely depends on the data
You'd generally use a cache to implement the same interface as the thing that retrieves the data, though
E.g.
IGetBookFromDatabase
would be the interface, GetBookFromSqlDatabase
physically goes to the DB, CachedGetBookFromDatabase
takes a cache and an IGetBookFromDatabase
So the caching is transparent to the consumer
The service doesn't care whether it comes from a cache or not, it just asks for a bookYeah makes perfect sense
thx again bud, have a great evening
You too, GL with your code
Also if your cache is string keyed, make sure you identify it properly
e.g. you don't want to store things with just their ids in case you store book id 1234 and then accidentally retrieve that book when trying to get user id 1234
š
yeah im using Guids everywhere
to prevent such things
You pro in efcore i guess?
I don't use EF at all I'm afraid
oh snap
well a question for another time then
thx alot š
No worries
Looks like nothing has happened here. I will mark this as stale and this post will be archived until there is new activity.