26

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

Hello, Shmj, you wrote: S> 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. For what reason it is impossible to create get-only??

27

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

Hello, Shmj, you wrote: S> 1. If use the same EF CodeFirst it is necessary to mark with attributes of a field. And if do not use, it is not necessary. Especially counter EF. S> And it means that the library of your contracts will have dependence on specific ORM. Well also what? You changed  in the same project much?  is not that the fundamental thing, but nevertheless is written not for one year (in difference from JS libraries). Yes, at classes some fields will be with specific attributes. To you they press? S> 2. All fields should be get and set Vashche not so. From what it? You want - field creeks, you want -  (access any kind). The main thing - that the object was able to give the fields necessary for basis and to write down what undertake from basis (and it there can be different dial-ups). S> Actually any your object can be changed in any layer, you cannot forbid it. And what for to me something to "forbid" in own code?? For the sake of someone's paradigm? It you write the code - you and decide what to change.

28

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

Hello, Kolesiki, you wrote: S>> 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. K> for what reason it is impossible to create get-only?? If at you one object for everything in one layer it can be required set, and in other only get. And that there was a versatility to you everywhere it is necessary will put down both get and set.

29

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

Hello, Kolesiki, you wrote: K> And if do not use it is not necessary. Especially counter EF. That is your decision is not compatible with EF? S>> And it means that the library of your contracts will have dependence on specific ORM. K> Well also what? You changed  in the same project much?  is not that the fundamental thing, but nevertheless is written not for one year (in difference from JS libraries). Yes, at classes some fields will be with specific attributes. To you they press? As already told above, your layer of contracts will know about all. Besides, attributes can and clash - for one layer serialization is necessary and for another is not present. S>> 2. All fields should be get and set K> Vashche not so. From what it? You want - field creeks, you want -  (access any kind). The main thing - that the object was able to give the fields necessary for basis and to write down what undertake from basis (and it there can be different dial-ups). And if in one of layers you do not want to resolve record in property to which the basis should be able to write? S>> actually any your object can be changed in any layer, you cannot forbid it. K> and what for to me something to "forbid" in own code?? For the sake of someone's paradigm? It you write the code - you and decide what to change. And what others do not use your code? Well if it is pure for itself - it agree.

30

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

Hello, Shmj, you wrote: S> 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. S> well why ? You read Guidelines https://docs.microsoft.com/en-us/dotnet … llections? S> the Same collections should not have set-erov under these recommendations. And for XML-serialization/deserializatsii, for example, they are mandatory. S> 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. Simply because described - not OOP. It not objects and methods, and data structures and the procedures existing separately. Objects incapsulate the data and the procedures grouped together, reflecting essence of object. You do not have no selected.

31

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)? If the code identical by sight has different assignment, it is the different code.) in the present state of affairs IMHO it is more preferable own classes in the layers, solving specific targets, instead of one class collecting all that it is possible in porridge.

32

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

Hello, Shmj, you wrote: S> Hello, Kolesiki, you wrote: K>> And if do not use it is not necessary. Especially counter EF. S> That is your decision is not compatible with EF? I.e. to my decision  that for  is used - hang up attributes from any! S> as already told above, your layer of contracts will know about all. Also what in it of bad? I will remind, we speak about ONE object on all. For each layer the object has the necessary attributes and . And layers at us - three. S> Besides, attributes can and clash - for one layer serialization is necessary and for another is not present. Nonsenses, it not "conflict", and small . It is necessary to what layer, that and  (finding the attributes necessary to it). S> And if in one of layers you do not want to resolve record in property to which the basis should be able to write? Well so and who in this layer gets in ?? It is impossible to write - mark with a comment and do not write! S> and what others do not use your code? Well if it is pure for itself - it agree. You so boringly wrap all this problem, as if at the programmer only and a headache, what "and who in that layer wants to change my invaluable ?!" . Probably, in porridge too many different groats - reconsider a kettle. Business object is not any touchy person who should be protected are a data, your business code should operate with them and only. Where there to undertake to "another's code"?? And if there are "strangers" so for this purpose (a specific case) specially it is necessary to sharpen architecture! But I assure, it not the general case. Few times I had moments when a certain data should not be visible. Made the most elementary method of cloning which in a copy transferred only the visible data and sent object to other unit - all ! There was still a moment when a certain data categorically cannot be re-recorded (in basis). My decision: from basis I read out ORM-OBJECT, I re-record the fresh data  necessary , I save reversely. Thus you can distort , but they never spoil system. More shortly, specific business cases which not so mandatory to drag on architecture level. As bonus the idle time, the supported code - prime property at  decisions served. And if I on each layer/module/svistelku have a dial-up of classes... Yo eat... I will be hung up supporting it in a consistent state! Tables - they not that often changed, but their changes should not turn to week audit of the code "where I here  did ??". , the easier - the more clearly.

33

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

As a matter of fact some classes with similar structure it  with all that it implies to consequences. Adding of a field demands changes not in one class, and in several. Also try be mistaken. And if changes more difficult than field adding (communications between classes changed)? Meanwhile in  data structure changes quite normal thing. Yes, clients do not know that want or know but cannot explain, it is necessary to reconcile to it. And thus ready to  it is necessary to receive a product in the shortest periods. Therefore whenever possible I do the general-purpose classes.

34

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

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)? Yes, it is a problem when objects becomes> 1. And in what a question?

35

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

Hello, igor-booch, you wrote: IB> As a matter of fact some classes with similar structure it  with all that it implies to consequences. IB> adding of a field demands changes not in one class, and in several. Also try be mistaken. And if changes more difficult than field adding (communications between classes changed)? And how you look at usage of interfaces as a basis/skeleton of business objects for all layers?

36

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

Hello, rm822, 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)? R> Yes, it is a problem when objects becomes> 1. And in what a question? And if 10 thousand - that not a problem?

37

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

S> And if 10 thousand - that not a problem? As a rule - is not present, a little...

38

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

S> And how you look at usage of interfaces as a basis/skeleton of business objects for all layers? I am not assured that correctly I understand your technology of interfaces. We admit there is a data access layer. There is web application and a desktop an application. Web application and a desktop application are able to save the order, using thus a data access layer. What classes and interfaces where will be?

39

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

Hello, igor-booch, you wrote: IB> I am not assured that correctly I understand your technology of interfaces. We admit there is a data access layer. There is web application and a desktop an application. Web application and a desktop application are able to save the order, using thus a data access layer. What classes and interfaces where will be? 1. Select a layer of the services which implementation does not depend from GUI. Create contracts for each service. For example, there will be interface IOrderService. And in it method CreateOrder (IOrder order). And so IOrder - too the interface, but already for a business object. 2. In implementation of service IOrderService do class OrderService which implements method CreateOrder. And as in implementation of services do a class of business object Order which implements IOrder (becomes one button). And at this class already put down the fields necessary to you. 3. The web application and a desktop-appendix work not with service OrderService, and with contracts IOrderService. Specific implementation connect by means of IoC (is ready  type Unity and so forth). 4. The web application does the class-realization IOrder. And can add . Fields and . Attributes which are necessary to it. Accordingly the desktop-appendix does the same - the . Fields and attributes. 5. If you change any field in the contract or add new - the compiler informs at once on it, i.e. do not forget to correct in all layers.

40

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

S> 5. If you change any field in the contract or add new - the compiler informs at once on it, i.e. do not forget to correct in all layers. This powerful advantage. Certainly I for interfaces. What else you see  from interfaces in the considered scenario? I see following advantage: it is possible to hang logic on interface IOrder (for example, in a type  methods) to place it in the assembly together interface IOrder and to use this logic in a desktop and a web application (the desktop and a web application refer to the assembly with the interface). In a case if from a desktop and about an application web would be we admit direct access to a DB, I would make easier. A data access layer (having direct access to a DB) we implement in the assembly. The desktop and a web application simply refer to this assembly. If a web it are necessary for application . Properties at Order, in the assembly an application web we create successor WebOrder: Order. Similarly for a desktop. In this case interface IOrder is not necessary. More truly it can be necessary, but only as a part model business, but not as the technical interface for support of an infrastructure of layers (a skeleton business of objects as you told). If indirect access to a DB was necessary for someone (through service), we turn the same assembly of data access in service and then technical interfaces for support of an infrastructure of layers become necessary. But in this case logic on infrastructural interface IOrder any more you will not hang (as I above wrote) as it already is present at class Order. But I the supporter of direct access to a DB from a desktop (about an application web especially). Yes, it is necessary to work over safety, access rights of users at DB level, SSL connection of the client With a DB, but business of that costs. It is not necessary to create access service to a DB, only not to potter with its adjustments of safety. S> 3. The web application and a desktop-appendix work not with service OrderService, and with contracts IOrderService. Specific implementation connect by means of IoC (is ready  type Unity and so forth). Some various implementations IOrderService except testing can be necessary for something still?

41

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

Hello, Shmj, you wrote: S> Practically in each project this data is used for 4-5 things: S> 1. For internal consumption, i.e. you transfer/accept certain classes in the methods and something with them do. S> 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). S> 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. S> 4. You need to give the same structures through REST/SOAP-API to exterior users. S> 5. The same structures to you need to be received from exterior API on which already you depend. S> 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 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)? The short answer to this question such: - If application small (we tell, till 100000 lines) and with small lifetime (year-two) - do a combined class for all purposes at once, disconnecting unnecessary in each case at serializations. Because what for to repeat same in several places? In one object it is possible to set attributes and  serializations in XML (well, at least, until such format only one) and  on basis and all that there still is necessary. - If application average or big or is planned to long life - be not too lazy to create separate classes. Because saving on one class instead of five on the scale of the project will be scanty, and here problems of that it is necessary to change, for example, class usage in  API, and the structure is beaten by nails both to basis and to JavaScript (where almost never are not present the meticulous tests checking all variants of usage of all fields) - will be quite real. Plus permanently there will be latent errors or simply loss of speed of that somewhere something superfluous , or  not in that type... At me such cases with the old code  it is regular. Here is how time more recently was a fresh example: it was required to change field type with DateTime on DateTimeOffset for exterior API, leaving DateTime in remaining cases. And as it is good that at me somewhere these classes have already been selected for 80 %. Otherwise would collapse very much. For the second case it is necessary to think over the circuit of conversions in advance. If it appears "all to all" - that somewhere is an architectural problem. Something normally turns out star type: at center - "for internal consumption", and from it bidirectional conversions in basis, in DTO etc. Also it is necessary to understand business essence that the separate format of representations is not always a separate class created manually. For example, for  DataAccess this representation can be  for ORM. That is, , between application layers the format "for internal consumption" For saving in layer DataAccess walks the same comes "for internal consumption". As DataAccess it saves is its domestic concern. Can through  (if it is not registered in the most main essence), and can also creation of the intermediate class which will live only in DataAccess For exterior services and for transmission to the browser forms specialized DTO which lives in an access layer to these services  in selected service agent if that is. And the same essence "for internal consumption" comes to this service agent

42

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

Hello, Shmj, you wrote: S> 1. Select a layer of the services which implementation does not depend from GUI.... S> 3. The web application and a desktop-appendix work not with service OrderService, and with contracts IOrderService. Specific implementation connect by means of IoC (is ready  type Unity and so forth). And what for some implementations for different GUI if implementation does not depend from GUI are necessary?

43

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

Hello, vmpire, you wrote: S>> 3. The web application and a desktop-appendix work not with service OrderService, and with contracts IOrderService. Specific implementation connect by means of IoC (is ready  type Unity and so forth). V> And what for some implementations for different GUI if implementation does not depend from GUI are necessary? For testing.