1

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)?

2

Re: About business objects: for saving, for API, for the internal

Hello, Shmj, you wrote: whether S> you See 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)? I consider normal that the same data alters the representation depending on the task. And faced reverse a problem. Variants of representation of the same data were considered as independent from each other. And output agents had the independent. As a result, it was necessary to import the same editings in different code locations.

3

Re: About business objects: for saving, for API, for the internal

Hello, Mihas, you wrote: M> I consider normal that the same data alters the representation depending on the task. What do you mean under representation? That that for each case you create conterminous classes on 90 %? M> and faced reverse a problem. Variants of representation of the same data were considered as independent from each other. And output agents had the independent. As a result, it was necessary to import the same editings in different code locations. If create classes for each of 5 cases - that at change of a data structure of editing should be imported everywhere.

4

Re: About business objects: for saving, for API, for the internal

Hello, Shmj, you wrote: S> But presence set-erov contradicts an internal paradigm. Here also it is necessary to begin with it. If certain   it is not inscribed in the practical logic, not "paradigm", and a spherical horse in vacuum. Whether S> you see a problem in that that as a matter of fact the same data on  time should be copied Certainly! Therefore I do easier - I create combined classes. 1. In them there are all fields which are accurately laying down on fields of a DBMS. 2. Fields not for a DBMS we mark as SqlIgnore are those useful "business-properti". 3. Serialization in JSON at us is used in all breadth, therefore just as from a DBMS that is not necessary - we mark JsonIgnore. As a result, the same class EASY rotates in business to the logician, springs in  and is reverse,  for exterior API and pleases  without everyones  MVVM/MVC, etc.

5

Re: About business objects: for saving, for API, for the internal

Hello, Kolesiki, you wrote: K> Here also it is necessary to begin with it. If certain   it is not inscribed in the practical logic, not "paradigm", and a spherical horse in vacuum. Well why ? You read Guidelines https://docs.microsoft.com/en-us/dotnet … llections? The Same collections should not have set-erov under these recommendations. And for XML-serialization/deserializatsii, for example, they are mandatory. With collections was mistaken, it appears and without  serialization works. But how to be with other properties? If one object for everything generally it is impossible to create only get-properties. It turns out if transferred object in a method - there are no warranties that it there does not undergo to changes.

6

Re: About business objects: for saving, for API, for the internal

Hello, Shmj, you wrote: M>> I consider normal that the same data alters the representation depending on the task. S> that you mean under representation? I understand as representations enumerated in a start post: 1. For internal consumption 2. For saving through ORM 3. For saving in a xlsx-file. 4. In structure REST/SOAP-API (for example, the goods description) it is necessary to represent the Same data member in this or that structure. M>> and faced reverse a problem. Variants of representation of the same data were considered as independent from each other. And output agents had the independent. As a result, it was necessary to import the same editings in different code locations. S> if create classes for each of 5 cases - that at change of a data structure of editing should be imported everywhere. Something can be carried out in a common part.

7

Re: About business objects: for saving, for API, for the internal

Hello, Mihas, you wrote: S>> If create classes for each of 5 cases - that at change of a data structure of editing should be imported everywhere. M> Something can be carried out in a common part. That is you suggest to use inheritance?

8

Re: About business objects: for saving, for API, for the internal

Hello, Shmj, you wrote: S> That is you suggest to use inheritance? For 1-3 - the inheritance which has been tied up to ORM. 4-5 - dto with  in business objects.

9

Re: About business objects: for saving, for API, for the internal

Hello, Shmj, you wrote: S> the Same collections should not have set-erov under these recommendations. And for XML-serialization/deserializatsii, for example, they are mandatory. A correction: if it is a collection (ICollection <T>, IDictionary <TKey, TValue>, ISet <T> or their successors) the setter is not necessary, all and so works, if... <<RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>

10

Re: About business objects: for saving, for API, for the internal

Hello, Sharov, you wrote: S> For 1-3 - the inheritance which has been tied up to ORM. 4-5 - dto with  in business objects. And it is is specific. You create objects in EF DB-First/Model-First and are then inherited from them? I.e. all your architecture is beaten by nails to EF?

11

Re: About business objects: for saving, for API, for the internal

Hello, Kolesiki, you wrote: K> As a result, the same class EASY rotates in business to the logician, springs in  and is reverse,  for exterior API and pleases  without everyones  MVVM/MVC, etc. Here in an ideal it would be desirable such that 1 class formed on one essence. Well or as a last resort inheritance. But there are two minuses: 1. If use the same EF CodeFirst it is necessary to mark with attributes of a field. And it means that the library of your contracts will have dependence on specific ORM. 2. All fields should be get and set, even if on your internal logic object not . Actually any your object can be changed in any layer, you cannot forbid it.

12

Re: About business objects: for saving, for API, for the internal

Hello, Sharov, you wrote: S> 4-5 - dto with  in business objects. And still. How fulfill ? By means of a reflection or manually?

13

Re: About business objects: for saving, for API, for the internal

Hello, rameel, you wrote: R> the Correction: if it is a collection (ICollection <T>, IDictionary <TKey, TValue>, ISet <T> or their successors) the setter is not necessary, all and so works, if And here: https://docs.microsoft.com/en-us/dotnet … s/property  DO create get-only properties if the caller should not be able to change the value of the property. Keep in mind that if the type of the property is a mutable reference type, the property value can be changed even if the property is get-only. Under your circuit at all there will be no possibility to make get-only properties. Generally in any way. All should be both get and set. And what if your object demands an invariance? You transfer it and there should be a warranty that the method does not change it. What then?

14

Re: About business objects: for saving, for API, for the internal

Hello, Shmj, you wrote: S> Hello, Sharov, you wrote: S>> For 1-3 - the inheritance which has been tied up to ORM. 4-5 - dto with  in business objects. S> and it is is specific. You create objects in EF DB-First/Model-First and are then inherited from them? I.e. all your architecture is beaten by nails to EF? At me the scenario is easier, therefore everywhere I use generated orm objects (at me telerik openaccess). In case of object passing between services, I use transformation in dto which for me the same orm already generated. Transformation is fulfilled by copying + the logic specific business.

15

Re: About business objects: for saving, for API, for the internal

Hello, Shmj, you wrote: whether S> you See 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)? There is here no problem. You define 5 different classes, and all. If you will try  one - all ends with porridge (agitation of different units and layers) Copy  for example (the most widespread  for this purpose on.net) - provides floppy effective copying of "similar" objects.

16

Re: About business objects: for saving, for API, for the internal

Hello, Shmj, you wrote: I answered here it here: S> And for XML-serialization/deserializatsii, for example, they are mandatory.... <<RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>

17

Re: About business objects: for saving, for API, for the internal

Hello, bnk, you wrote: bnk> There is here no problem. bnk> you define 5 different classes, and all. If you will try  one - all ends with porridge (agitation of different units and layers) bnk> Copy  for example (the most widespread  for this purpose on.net) - provides floppy effective copying of "similar" objects. Not clearly why "porridge" is mandatory turns out. And about copying. After all there is such concept as the designer and it  at class creation. There mandatory fields are specified. And you automapper knows about designers and mandatory fields? Or you suggest to refuse the concept of designers, to leave it always empty and whether simply to use method VilidateInstance for check mandatory fields are installed?

18

Re: About business objects: for saving, for API, for the internal

Hello, rameel, you wrote: R> I answered here it here: S>> And for XML-serialization/deserializatsii, for example, they are mandatory. Yes, for collections it appears are not mandatory. But on the paradigm offered above with usage of a uniform class for all - generally all properties will  is mandatory both get and set. And what if the object does not imply possibility of changes?

19

Re: About business objects: for saving, for API, for the internal

Hello, Shmj, you wrote: S> But on your paradigm generally all properties will  is mandatory both get and set. And what if the object does not imply possibility of changes? To what paradigm?! I generally once only wrote, to specify that for standard XML () collection serializations is not mandatory presence of a setter. A question I think I am addressed not to me, in discussion not ... <<RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>

20

Re: About business objects: for saving, for API, for the internal

Hello, Shmj, you wrote: S> But on the paradigm offered above with usage of a uniform class for all - generally all properties will  is mandatory both get and set. And what if the object does not imply possibility of changes? Here I with you agree, if that. If the object does not imply changes also the class is projected  in the image... <<RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>

21

Re: About business objects: for saving, for API, for the internal

Hello, Shmj, you wrote: S> Hello, bnk, you wrote: bnk>> There is here no problem. bnk>> you define 5 different classes, and all. If you will try  one - all ends with porridge (agitation of different units and layers) bnk>> Copy  for example (the most widespread  for this purpose on.net) - provides floppy effective copying of "similar" objects. S> it is not clear why "porridge" is mandatory turns out. Clearly why -  serializations get into basis in Web API, and on the contrary. The data necessary only for UI, it will be necessary to mark "not to save", "not to export", well etc. Data types will are crumpled - we take for example enum. In basis  int, in UI - string. What it is done? S> and about copying. After all there is such concept as the designer and it  at class creation. There mandatory fields are specified. And you automapper knows about designers and mandatory fields? S> Or you suggest to refuse the concept of designers, to leave it always empty and whether simply to use method VilidateInstance for check mandatory fields are installed?  designers. A useless thing in this case. The data is checked strictly on the user input, and it is more anywhere. And there WebAPI and everyones [Required] to care there is nothing. All the same in such classes as a rule  fields not to thrust all of them in parameters of the designer?

22

Re: About business objects: for saving, for API, for the internal

Hello, bnk, you wrote: bnk> it is clear why -  serializations get into basis in Web API, and on the contrary. And than they hinder in practice? bnk> the data necessary only for UI, it will be necessary to mark "not to save", "not to export", well it is etc. correct, to mark that those or others it is not necessary to export. It unless is not logical and correct? Marked - and the system understands. bnk> data types will are crumpled - we take for example enum. In basis  int, in UI - string. What it is done? So it separately is underlined by means of attributes or Fluent bnk> to Nafik designers. A useless thing in this case. The data is checked strictly on the user input, and it is more anywhere. And there WebAPI and everyones [Required] to care there is nothing. The data arrives not only from the user. Idea such - it is impossible to create object of a class without mandatory fields. What for then generally designers with parameters are necessary? Or you at all do not use them never, refused the concept of the designer as that? bnk> all the same in such classes as a rule  fields not to thrust all of them in parameters of the designer? But not nevertheless from them mandatory?

23

Re: About business objects: for saving, for API, for the internal

Hello, Shmj, you wrote: bnk>> the Data necessary only for UI, it will be necessary to mark "not to save", "not to export", well etc. S> it is correct, to mark that those or others it is not necessary to export. It unless is not logical and correct? Marked - and the system understands. Well it is finite smile And attributes where are defined? In a layer of the data (EF?) We add  on it, aha. Further, attributes for WCF? Certainly, we add  on it too. Further, what there, WebAPI, JSON, XML? Yes, still . Then it is necessary to transfer pair of additional flags for UI, and to steam of lists for ? Certainly, we add fields and we mark all of them than it is necessary, for all units without forgetting. Time stamp was necessary for JSON-service? We add... In general I to what - as a result turns out a class of the data which "knows" all about all. Knows too much. For example, in a specific place, it can be not clear, what  are intended for the given subsystem, and what - for another. At modification of one system (bases for example) should be held in a head as it is necessary to mark given  that broke nothing and that it did not arrive where it is not necessary. bnk>> Data types will are crumpled - we take for example enum. In basis  int, in UI - string. What we do? S> So it separately is underlined by means of attributes or Fluent That is to make int/enum? And then type to hang clusters attributes-converters at line for WCF or API? Or to make in the line? bnk>> Nafik designers. A useless thing in this case. The data is checked strictly on the user input, and it is more anywhere. And there WebAPI and everyones [Required] to care there is nothing. S> Idea such - it is impossible to create object of a class that in it there were no mandatory fields. What for then generally designers with parameters are necessary? Or you at all do not use them never, refused the concept of the designer as that? If more than one-two-three - are not present, in wood. We do . For DTO - yes, any designers.

24

Re: About business objects: for saving, for API, for the internal

Hello, bnk, you wrote: bnk> Well it is finite And attributes where are defined? In a layer of the data (EF?) We add  on it, aha. bnk> Further, attributes for WCF? Certainly, we add  on it too. Further, what there, WebAPI, JSON, XML? Yes, still . The true share in it is. But many attributes, for example Table, Key, Required, Display, NotMapped and so forth are defined in system assembly System. ComponentModel. DataAnnotations. I.e. there is no binding to specific ORM, for example. Index, ForeignKey and so forth it is possible to add by means of Fluent API. If you at the head have business objects bad in attributes is not present anything. Or it is possible to make them in the form of interfaces. But also there without attributes of some not to manage... bnk> Then it is necessary to transfer pair of additional flags for UI, and to steam of lists for ? Certainly, we add fields and we mark all of them than it is necessary, for all units without forgetting. And you even do not define interfaces, simply do different classes? Basic interfaces of the general? bnk> in general I to what - as a result turns out a class of the data which "knows" all about all. Knows too much. It and and not so. In the theory all attributes should be in System. ComponentModel. DataAnnotations. But in practice not absolutely so. On the other hand time you defined specific classes, instead of contracts they and should know where them will use. Or then to define in the form of contracts-interfaces. bnk> for example, in a specific place, it can be not clear, what  are intended for the given subsystem, and what - for another. bnk> at modification of one system (bases for example) should be held in a head as it is necessary to mark given  that broke nothing, bnk> and that it did not arrive where it is not necessary. Yes, I will agree. S>> idea such - it is impossible to create object of a class that in it there were no mandatory fields. What for then generally designers with parameters are necessary? Or you at all do not use them never, refused the concept of the designer as that? bnk> if more than one-two-three - are not present, in wood. We do . For DTO - yes, any designers. And what for then generally designers with parameters are necessary? Can forbid at once designers with parameters and it becomes easier to all to live?

25

Re: About business objects: for saving, for API, for the internal

Hello, Shmj, you wrote: S> And you even do not define interfaces, simply do different classes? Basic neither interfaces of the general? Anything. Nor the general base class, interfaces. Simply different classes with equally named fields. bnk>> if more than one-two-three - are not present, in wood. We do . For DTO - yes, any designers. S> and what for then generally designers with parameters are necessary? Can forbid at once designers with parameters and it becomes easier to all to live? Well speech about DTO. Here for DTO - are not necessary. And generally - happens conveniently. using to make,  to throw, dependences to initialize. For DI for example. Last by the way the exception - can be more arguments. But here already purely technical restrictions used . Speech not only about the designer. Generally, what for in  to transfer it is a lot of arguments? If it is necessary - enveloped in object, transferred. And that make the designer of type new UserInfo (string domain, string username, string gender, string title, string password) -  do not confuse arguments by a call