Projections ... .ListValues vs .List

BIZ TMS XData
1
While absolutely loving the power and ease-of-use of xData, I still struggle in finding the best way to work around some of the limitations.  E.g. Clientside I would like to get a list of languages as in 
  Select * from lu_language
  where etc..

xData provides all this (and much much more ) out of the box... so far : great !

As I need some additonal server-side processing, I create a separate (serverside) servicefunction that returns a TLIST<Tlu_language> 
(also the use of generics is awsome here) ... all handled automatically by xData... and can be consumed clientside via REST and with hardly any code (Win, Mac, iOS, Android, Linux... AND Web !! :-).
Again GREAT.

Then... when going a little further and need some more basic query hocuspocus like a simple join (or select distinct etc)
----------------
SELECT
  lu_language.*
FROM user
  INNER JOIN lu_language
    ON user.nativelanguage_id = lu_language.language_id
GROUP BY lu_language.language_id
ORDER BY lu_language.language
----------------
I would still (on purpose) be getting exactly the same result-type so neither server- nor client-side anything should change.
So ... again... serverside Aurelius has a lot of useful functionality with Linq, criteria, filters etc under the hood that helps with this.

In order to use the "group by" functionality though, I understand I should use projections.  Again nice additions and possibilities but projections return values (makes sense when you add sums or averages etc...)

In above case though, I would definitely prefer to stick with my function-result TLIST<lu_language> objects.

As I'm new to Aurelius and xData, do you have any example/hints on the best/easiest/cleanest/suggested way to tackle this (USING instead of rewriting all the nice stuff you already created of course :-) ?

2

Hello Hans,

You have several options, the main three ones would be: 

1. Returning TList<Tlu_language>
2. Returning TList<TCriteriaResult>
3. Returning TList<Tlu_language_dto>

You did a very good summary of it. You are right in what you said.
Option 1 is straightforward in most cases. But if you are using grouping, you have indeed to manually perform the Aurelius criteria, which will return a TList<TCriteriaResult>.
Then, you can use option 2 straightforward, i.e., just directly returning the TList<TCriteriaResult> object you got from Aurelius.
If you do not want this approach, as you mentioned, then you have option 1 or option 3. In both cases you would have to manually create the instances of Tlu_language (or Tlu_language_dto) and manually fill their properties based on the results returned by Aurelius criteria.
I included option 1 Tlu_language because you mentioned you'd want to keep it, but that is what makes the less sense, because if you are returning a different subset of properties, even aggregate results (sum, count), the properties of Tlu_language won't be able to hold the values (where are you going to put the Count value for example?).
So what is usually done is creating a specific, simple Delphi class Tlu_language_dto with the properties you want to return, and return a list of it.
3

Thanks again for your speedy response... playing with the options...