Otis wrote:
I indeed see the ordering is alphabetical. It doesn't really matter in which order the fields are stored for runtime functionality, you have a specific reason for requiring the fields in a given order in the generated poco class? We generate them alphabetically to make merging code easier in source control
Sometimes when working, it is useful when us humans when, for example looking for the field you missed in an initializer. For this type of exercise - having field in the same order is very useful. I use it often enough that it is my strong preference. I tend to intentionally group related fields together in terms of field order, so they are visually presented together.
As for merging - the most important aspect is the consistency - not alphabetical - (although alphabetical is a form of consistency). And if using the database field order in the designer ( as I usually do), then changes in POCO class usually end up at the end of the list of fields - another useful consistency when looking at code history.
I fully accept that in terms of machine functionality, does not matter - but when us humans are looking at code / objects, picking the order that works for us is useful.
Is there a technical reason why this was left of of .net core template - or is it just simply not implemented yet?
