first of all, does it actually go to the database? :)
it could be optimized...
the reason behind it, you don;t need an extra local variable of that entity.
so it's less code for us.
mind you, these are my assumptions and experiences :)
on the less variable.
1. you can always do a getforupdate<entity> before actual storing/update the record.
2. and you will end up with the listrecord or editrecord value which will be different than the original aggregate if you actully changed it.
and the other
- the optimization goes a long way. if you are showing less attributes in the screen, it will fetch only those attributes instead of the whole record. (in production mode at least)
and in my experience, the interpretation is pretty good :)
if you are searching in the database, you will have a complex where-clause anyways, so chances are it will go to the database anyways.
what i was thinking about "does it actually go to the database" was merely about the aggregrate of the detail-screen, which is a simple query with a clause on the primary-key.
since PK's cannot be null in outsystems (well it can, but you get my drift) it can easily detect if it wants to go to the database or stay in the code...