Topic: About business objects: for saving, for API, for the internal
As a matter of fact the code works with the data. We name business objects. Practically in each project this data is used for 4-5 things: 1. For internal consumption, i.e. you transfer/accept certain classes in the methods and something with them do. 2. For saving. As a rule ORM allows to save these data structures. But so simply it is impossible - it is necessary or to allocate them with attributes or (well or a XML description). 3. The Same data structures sometimes should be saved a disk in somebody a format without ORM. For example for saving in a xlsx-file. 4. You need to give the same structures through REST/SOAP-API to exterior users. 5. The same structures to you need to be received from exterior API on which already you depend. Principal inconvenience I see that on very similar structures in each of these 5 cases it is necessary to copy one in another. Because they though are similar, occasionally on 90 %, but nevertheless differ. For example in one case mandatory presence set-erov is required, differently the library refuses to work dataful (for example, standard XML-serialization demands that at the list was set-er). But presence set-erov contradicts an internal paradigm. Whether see you a problem in that that as a matter of fact the same data on time should be copied from one structure in another only for the reason, what they are applied in different layers (but on identical entities)?