To start off my “Code Structure” tag, I usually find developers create a big type library to hold all their types used across multiple libraries. In my opinion, this violates the “Separation of Concerns” rule.
Another problem with this is developers tend to misuse the types and tightly couple code together such that a change to the type can potentially impact multiple areas.
For example, I’ve seen types meant for web service contracts used all the way down in the data access layer.
Another issue I’ve seen is types that have a ton of fields. In many cases they have most of the fields in the corresponding database table. By the way, I don’t necessarily believe that the types have to match the database table structure.
I believe this issue is also what is described as the “God Class”. Anyway one problem with this is that it can be confusing in code as to whether the objects of this type have been properly populated. The default thinking should be it is always correctly populated by the data access layer but of course I’ve seen developers reuse a type and only partially populate the object. They probably did this inadvertently from not thoroughly reviewing their code.
So at least when coding in the data access layer and Update/Add APIs, I believe we should carefully select what fields are passed in. All parameters and objects fields passed in should be assumed to be the exact values that will be stored in the database.
There are a few other issues with these “God Classes”. One is type fields that are for calculations. There is no good reason to pass these to the data access layer and cause confusion when reading the data access layer code. Another issue is there is unnecessary payload being passed around. And finally, the more fields you have to consider the more complex the API can be.
Ideally, the data access Update/Add APIs should be simple processing of related data.