Anonymous Types - syntax needed

NickFriend · Post by **NickFriend** » Tue Oct 25, 2016 4:23 pm

Hi Phil,

If you're going to be moving this data around and using it elsewhere, surely it would be better to project into a concrete type and have done with it.

You could simply create classes to represent these subsets of data, and then you can have everything strongly typed and under control.

Nick

Phil Hepburn · Post by **Phil Hepburn** » Tue Oct 25, 2016 4:32 pm

Thanks Robert (Nick

: XSteamAT_11.jpg (29.52 KiB) Viewed 356 times

and all),

This has done the trick. Even though at present I seem to have to use an enumeration (FOREACH) when I would prefer a "results.ToList()" assignment.

DYNAMIC seems to be the way to go - I will invest more time tomorrow.

Yes, Nick (next post) it would be best to make our own classes and in fact when we move to "LINQ to SQL" and "LINQ to Entities" things are simpler because we tend to have our classes.

If we are to have and use Anonymous Types then it is good to have some measure of control over them and their use ;-0)

Cheers,
Thanks to you all for your help,
Phil.

Phil Hepburn · Post by **Phil Hepburn** » Tue Oct 25, 2016 4:36 pm

Hi Nick,

I tend to agree with your thoughts and ideas, and have expressed such ideas in my C# eNotes some years back.

However, ATs (anonymous types) do have some uses and therefore it is nice to feel that we can get the most out of them if and when we wish.

Well, for 'most' I mean a bit more then them being in control of me / us !!!

Thanks for your input, I will need much more advice as the session material develops.

Next stop is "LINQ to SQL' then "LINQ to Entities".

Cheers,
Phil.

NickFriend · Post by **NickFriend** » Tue Oct 25, 2016 4:42 pm

I really dislike the idea of using Dynamic types.... if you're just using the anonymous type inside a single method, then that's fine to keep it anonymous, as you have all the info you need to understand what's going on right in front of you.

But as soon as you start to return info from a method, I think you should really go for a known concrete type, unless there's a really good reason not to. Otherwise to use the returned data, you either have to use reflection (very slow and inefficient, and horrible to understand the resulting code), or else you have to go and look at the called method to interpret the data, which makes it difficult to write reliable, maintainable code.

Just my 2p.

Nick

NickFriend · Post by **NickFriend** » Tue Oct 25, 2016 4:43 pm

Hi Phil, posted at the same time you were making your points about anonymous types... anyway at least you know what I think about them now!!!

Nick

Phil Hepburn · Post by **Phil Hepburn** » Thu Oct 27, 2016 8:15 am

Hi Nick,

Now I have done some more research and testing I see just what you mean about DYNAMICS. I have the syntax working quite satisfactorily - BUT !!!

Because the DYNAMIC type is 'by-passed' for checking by the compiler then the properties are not then available for intellisense in other places (or anywhere) in our code being created, particularly annoying for outside of the Method collecting the query results data, when we MUST have intellisense.

So your idea of always making a 'concrete' Class for the relevant property values seems a much better idea to me - even if it is the simplest of Class definitions. Even though we may still use anonymous types within the query syntax for things like the Group clause - the select clause can still use a user define 'concrete' class for the results set.

This is just another of those 'things' that the published eBooks, by well known authors, do not address and/or answer. There are quite a few such issues related to LINQ, that's why I ended up writing and creating my own 'ClickStartLINQ' eNotes.

I will do some more testing on this as I fill-out my sections and sub-sections in my Appendix 'X' in the eNotes I am compiling / writing.

Regards,
Phil.