DTO usage

[amanda-mitchell]

If a type is used with JSON-serialization methods (for example JsonUtility.ToJson), raise a warning if the type does not have a Dto suffix.

For types that do have a Dto suffix, verify that all properties are auto-implemented and are of "approved" types:

• string
• number (int, long, float, double, whatever…)
• bool
• other types that have a Dto suffix
• ReadOnlyCollection / IReadOnlyCollection of any of the above
• ReadOnlyDictionary IReadOnlyDictionary from string to any of the above.

These will definitely need to be warnings, given the number of historical violations that we have.

[ddunkin]

IReadOnlyCollection or IReadOnlyList?

All properties should be nullable.

[ejball]

IReadOnlyList

[dustinsoftware]

We have a converter for DateTimeOffset, is that being deprecated?

[amanda-mitchell]

I recommend deprecating the DateTimeOffset converter.

Using converters makes it more difficult to create intelligible error messages when deserialization fails—particularly in the case of parameters to ASP.NET actions, where a failure to deserialize results in a 500 instead of a 400.

While this is still something of an issue with type mismatches (for example, a number where a string is expected), I don't see a compelling reason to exacerbate the problem, especially when the first thing we usually do with a DTO is to convert it to/from a domain object, which can have a wider variety of types on it.

[amanda-mitchell]

Additional recommendation: Dto types should be sealed.