1

Topic: Reusage of existing methods

At us in the company the software which with some changes is on sale to different clients is developed. I.e. on-essence one and that product, but with differences for different clients. Standard enough situation in general. There is a facade of services which contains business logic, code EF and everyone .  we gain idea of reusage of methods for different clients, and he can be understood - set of methods differ at level . Parameter to request, the fields displayed on the screen . There is a percent of absolutely identical methods, but small enough - tell percent of 20 %. At present on each project the code is simply copied in new  where methods change under new requirements.  very strongly wants to have ONE project for services, which  for different clients. The question - to somebody was possible to find the successful decision for such problem? Problem that if to start to do methods more by "general" it will be obvious for pressing on productivity. And at all a case of various parameters when the new method is almost inevitable, but also in a case when new clients instead of one field of essence it is required to display another. If to pull from basis ALL fields, and then to transform them to necessary cutoff DTO for the specific client loading on basis strongly enough increases

2

Re: Reusage of existing methods

Hello, Stalker., you wrote: S> At us in the company the software which with some changes is on sale to different clients is developed. I.e. on-essence one and that product, but with differences for different clients. Standard enough situation in general. There is a facade of services which contains business logic, code EF and everyone .  we gain idea of reusage of methods for different clients, and he can be understood - set of methods differ at level . Parameter to request, the fields displayed on the screen . There is a percent of absolutely identical methods, but small enough - tell percent of 20 %. At present on each project the code is simply copied in new  where methods change under new requirements.  very strongly wants to have ONE project for services, which  for different clients. S> the question - to somebody was possible to find the successful decision for such problem? Problem that if to start to do methods more by "general" it will be obvious for pressing on productivity. And at all a case of various parameters when the new method is almost inevitable, but also in a case when new clients instead of one field of essence it is required to display another. If to pull from basis ALL fields, and then to transform them to necessary cutoff DTO for the specific client loading on basis strongly enough increases There was at me a similar experience. I consider that for similar systems it is necessary to divide  ("engine") and .  and the data scheme should be the general for everything, and  - different, them  it is impossible. The reason at all in high-speed performance, and in configuration volume. To add a functional for the specific client, it is necessary to add in the code if in bulk in different places and to fasten them on some flags in adjustments of the client. Such system quickly quits from under control. I so understood, at you was not present , is simple API. Then I would make the general circuit of a DB, the general layer DAO for this a DB and individual implementations API under each client, leaning against the general layer DAO. As to high-speed performance, it is impossible to speak about it abstractly, always it is necessary to make samplings at first. It as I thought that the basis is slowly, and then it appeared that  on AWS micro holds 3000  in a second.

3

Re: Reusage of existing methods

Hello, scf, you wrote: scf> I so understood, at you was not present , is simple API. Then I would make the general circuit of a DB, the general layer DAO for this a DB and individual implementations API under each client, leaning against the general layer DAO. As to high-speed performance, it is impossible to speak about it abstractly, always it is necessary to make samplings at first. It as I thought that the basis is slowly, and then it appeared that  on AWS micro holds 3000  in a second. Is both , and API, the database scheme now one and is, on it sits F which one turns out too, you it  under "the general layer DAO"? If yes, it already is. That is not present, it is the further unification of methods. I.e. method FindCustomers () is necessary for example. This method is in a facade to which address client GUI and various API. Now it is necessary to one client of all customers with  and date of birth, and to another - with the address. The third client still wants to add to search of customers . The filter (for example on a city) and to deduce phones of customers. I.e. variants on-essence the such: 1) to Deduce all possible fields of customers and to return all of them to all clients. I.e. the client to whom the address all the same it is not necessary receives, simply should ignore. 2) to create a superstructure over a facade unique for each client which is engaged in that creates specific to client DTO from lump of that returned a facade. I.e. on-essence to create one more facade-layer responsible only for the assembly specific D. 3) to Each client to create the method, i.e. on-essence for each client there is a facade (approximately that now and happens) where all logic is doubled for all clients. 4) for a case with under. The filter to try any dynamic filters/parameters? Probably-whether such also has-whether sense? At methods 1 and 2 1 general facade that is good turns out only, but it starts to expand, after all if absolutely new method is necessary to any one client - it there will be added and can eventually the facade-monster turns out

4

Re: Reusage of existing methods

Hello, Stalker., you wrote: S> Hello, scf, you wrote: S> is both , and API, the database scheme now one and is, on it sits F which one turns out too, you it  under "the general layer DAO"? If yes, it already is. That is not present, it is the further unification of methods. I.e. method FindCustomers () is necessary for example. And so it is impossible to make: public class CustomerService <T> where T:CustomerBase {public T FindCustomers () {throw new NotImplementedException ();}} public class CustomerBase {} Generally standard refactoring, select the general for all clients, and there already inheritance, a composition etc.

5

Re: Reusage of existing methods

Hello, Stalker., you wrote: S> 1) to Deduce all possible fields of customers and to return all of them to all clients. I.e. the client to whom the address all the same it is not necessary receives, simply should ignore. To you OData or GraphQL yet did not advise? It is a pity, and at me more so much remarkable ideas were! ((A joke about Gorbachev)

6

Re: Reusage of existing methods

To you it is necessary  (that is from your decision to make a kernel-frejmvork and with its help to write specific  decisions). Look on Cuba, be probably inspired. S> the question - to somebody was possible to find the successful decision for such problem? A problem that if to start to do methods more by "general" it will be obvious for pressing on productivity. And at all a case of various parameters when the new method is almost inevitable, but also in a case when new clients instead of one field of essence it is required to display another. If to pull from basis ALL fields, and then to transform them to necessary cutoff DTO for the specific client loading on basis strongly enough increases not obviously that it will press on productivity. The client should specify the list of fields which are necessary to it, the server them will pull out. Here the most important thing at all in normal fields (them to pull cheaply), and in . Basically any ORM allows it.

7

Re: Reusage of existing methods

Hello, Stalker., you wrote: S> is both , and API, the database scheme now one and is, on it sits F which one turns out too, you it  under "the general layer DAO"? If yes, it already is. That is not present, it is the further unification of methods. I.e. method FindCustomers () is necessary for example. This method is in a facade to which address client GUI and various API. Now it is necessary to one client of all customers with  and date of birth, and to another - with the address. The third client still wants to add to search of customers . The filter (for example on a city) and to deduce phones of customers. S> I.e. variants on-essence the such: S> 1) to Deduce all possible fields of customers and to return all of them to all clients. I.e. the client to whom the address all the same it is not necessary receives, simply should ignore. S> 2) to Create a superstructure over a facade unique for each client which is engaged in that creates specific to client DTO from lump of that returned a facade. I.e. on-essence to create one more facade-layer responsible only for the assembly specific D. S> 3) to Each client to create the method, i.e. on-essence for each client there is a facade (approximately that now and happens) where all logic is doubled for all clients. S> 4) for a case with under. The filter to try any dynamic filters/parameters? Probably-whether such also has-whether sense? S> at methods 1 and 2 1 general facade that is good turns out only, but it starts to expand, after all if absolutely new method is necessary to any one client - it there will be added and can eventually the facade-monster I for a variant 3 turns out. The main requirement in such "tree-like" system - minimization of volume of testing at modification. I.e. The architecture should be such not to test the facades which behavior should not to change. Here there will be at you 100 facades - if finishing of one of them can affect remaining you wallow in testing. In fashionable now the microservice architecture for each new client needs to write separate application which would pull  and gave to client API. Despite duplication, this approach has enormous plus - at change or adding of the client of all remaining clients it is possible not to test. I offer a rearrangement of the data from one model in another not to consider at all as duplication - to reuse the similar code is fraught with fragility of system. If there is something reused and that it is possible to name business logic I would make its separate unit/service. That the facade addressed and to layer DAO, and to this service. The main restriction at designing of such service - the guaranteed backward compatibility at modification. If you are excited with high-speed performance, this service in the middle can use GraphQL or something similar as the protocol: he allows to specify specific fields. But I will repeat - warranties of reverse compatibility should be such that to anybody to a head did not come  facades to which directly changes were not imported.

8

Re: Reusage of existing methods

Hello, Qulac, you wrote: Q> Generally standard refactoring, select the general for all clients, and there already inheritance, the composition etc. Is a problem architectural) the Problem of the general code that at depositing in it of changes can change to (break) behavior of all functional which uses this general code. For small applications or for a monolith it not a problem, but here in the HARDWARE situation when from the general basis tens applications which all should work stablly at modification of one of them grow... It is necessary or write tests from 100 % a covering (long and not the fact that is reliable), or to build such architecture that this problem dared automatically.

9

Re: Reusage of existing methods

Hello, scf, you wrote: scf> It is a problem architectural) the Problem of the general code that at depositing in it of changes can change to (break) behavior of all functional which uses this general code. For small applications or for a monolith it not a problem, but here in the HARDWARE situation when from the general basis tens applications which all should work stablly at modification of one of them grow... It is necessary or write tests from 100 % a covering (long and not the fact that is reliable), or to build such architecture that this problem dared automatically. Thanks, idea OData + microservices definitely similar that it is necessary to start to study. OData helps to unify methods differing with fields and filters, microservices can divide the "general" logic for all and unique for each client where the "general" microservice is delivered all clients, and "unique" depending on the client

10

Re: Reusage of existing methods

Hello, Stalker., you wrote: S> If to pull from basis ALL fields, and then to transform them to necessary cutoff DTO for the specific client loading on basis strongly enough increases Here I do not trust. In most cases there is no difference to load all fields or only a few. In those rare occurences when the difference is - it is possible to make a separate method for heavy fields (type: GetPersonalInfo (ids) and GetPersonalPhotos (ids)). Well and if service returns many data it is necessary to start to reflect on a partition on pages, parallel loading, etc. Generally, my council - should not be complicated. If superfluous methods about 20 % it is not necessary to fool a head - let and remain. Well and whenever possible classic methods  to the logician on the server. If to leave in jungle OData and any languages of requests it is possible there for ever and to remain.

11

Re: Reusage of existing methods

Hello, Cyberax, you wrote: a C> Here I do not trust. In most cases there is no difference to load all fields or only a few. In those rare occurences when the difference is - it is possible to make a separate method for heavy fields (type: GetPersonalInfo (ids) and GetPersonalPhotos (ids)).> Well and if service returns many data it is necessary to start to reflect on a partition on pages, parallel loading, etc. a C> Generally, my council - it is not necessary to complicate a C. If superfluous methods about 20 % it is not necessary to fool a head - let and remain. Well and whenever possible classic methods  to the logician on the server. If to leave in jungle OData and any languages of requests it is possible there for ever and to remain. Level strongly/not strongly certainly it is possible to debate, but that loading increases by a DB it is unambiguous. At first returning all fields we on determination we do not construct effective indexes on basis, any index on each table will be accompanied  all remaining fields, it is not cheap operation. Secondly, water all can be much, at us on-extreme measure their tens in each table. Thirdly, the set of attributes will be accompanied superfluous  since they lie in other tables that too expensive operation. And also there is one more moment which I did not mention are updates of system. Everyone half a year-year quit new versions of a product. In it any possibilities the most part from which is the general for all are added. Now it simply becomes in such a manner that any general feature is copied on all to product versions.

12

Re: Reusage of existing methods

S> I.e. method FindCustomers () is necessary for example. This method is in a facade In a facade there should not be such method, that business of the logician  in abstraction differently turns out. Something of type can be a good method for a facade: facade.setect (table, condition, fields); As intermediate are necessary  classes which to a facade turn result of requests in objects of the classes necessary to the client.//core interface ICustomer; class CustomerServiceBase {Facade facade; List <ICustomer> selectCustomers (Condition cond);}//client class ClientACustomer: ICustomer; class ClientACustomerService: CustomerServiceBase {List <ICustomer> selectCustomers (Condition cond) {//to broadcast request to a facade and to return the object list of class ClientACustomer}}

13

Re: Reusage of existing methods

Hello, Stalker., you wrote:>> Generally, my council - it is not necessary to complicate a C. If superfluous methods about 20 % it is not necessary to fool a head - let and remain. Well and whenever possible classic methods  to the logician on the server. If to leave in jungle OData and any languages of requests it is possible there for ever and to remain. S> level strongly/not strongly certainly it is possible to debate, but that loading increases by a DB it is unambiguous. S> At first returning all fields we on determination we do not construct effective indexes on basis, any index on each table will be accompanied  all remaining fields, it is not cheap operation. ? Search of a line in the table will be necessary anyway if only in an index there are no ALL fields necessary for performance of request. And search in a principal key - the most effective operation in a DB. If it  is necessary - we do the ad hoc method. S> Secondly, water all can be much, at us on-extreme measure their tens in each table. Thirdly, the set of attributes will be accompanied superfluous  since they lie in other tables that too expensive operation. Well let tens, also what? Other tables to model separate objects. S> and also there is one more moment which I did not mention are updates of system. Everyone half a year-year quit new versions of a product. In it any possibilities the most part from which is the general for all are added. Now it simply becomes in such a manner that any general feature is copied on all to product versions. Well so we add new fields in model of service and forward from songs.

14

Re: Reusage of existing methods

Hello, Muxa, you wrote: M> In a facade there should not be such method, that business of the logician  in abstraction differently turns out. M> something of type can be a good method for a facade: M> [cs] M> facade.setect (table, condition, fields); it also is approach OData?

15

Re: Reusage of existing methods

Hello, Cyberax, you wrote: a C> ? Search of a line in the table will be necessary anyway if only in an index there are no ALL fields necessary for performance of request. And search in a principal key - the most effective operation in a DB. There is a table with 30 fields. There is a search in 3 fields, on an output essence with 6 fields. The index on 3 fields becomes, the remained 3 fields are added as included. Search in an index returns at once essence. If we pull all 30 fields after search turnes on  remaining fields (that represents ONE MORE search already on clustered index of that data), cost will be the order of 10-20 % o request. It without considering logical reads of pages of all this field, their transportations and other S>> And also are one more moment which I did not mention are updates of system. Everyone half a year-year quit new versions of a product. In it any possibilities the most part from which is the general for all are added. Now it simply becomes in such a manner that any general feature is copied on all to product versions. A C> Well so we add new fields in model of service and forward from songs. And so to everyone  also are added now. From it also it would be desirable to leave

16

Re: Reusage of existing methods

Hello, Cyberax, you wrote:> Generally, my council - it is not necessary to complicate a C. If superfluous methods about 20 % it is not necessary to fool a head - let and remain. Well and whenever possible classic methods  to the logician on the server. If to leave in jungle OData and any languages of requests it is possible there for ever and to remain. I suspect that in Amazone where you work, is in large quantities used Java or Scala, and for them to this day, in 2017 there are no normal means for creation dynamic *. Well because it not for , and for those who writes on a rock, the tangency to a DBMS is  . From here and your so skeptical relation to means which simply works. * Guglenie on demand odata jooq did not give made results, odata hibernate showed something  (hibernate), odata4j does not contain means of manipulation with requests in the code, except as at level AST, odata slick does not show generally anything.

17

Re: Reusage of existing methods

Hello, Glory, you wrote: Well because it not for , and for those who writes on a rock, the tangency to a DBMS is  . And it is possible to ask (not for the sake of , and for the sake of the information) - why so? In a rock all in another way? avalon/2.0.3

18

Re: Reusage of existing methods

Hello, DenisCh, you wrote:> Well because it not for , and for those who writes on a rock, the tangency to a DBMS is  . DC> And it is possible to ask (not for the sake of , and for the sake of the information) - why so? In a rock all in another way? To tell the truth, it simply result of observations.  in an enterprise I did not meet, and a DBMS - it all about an enterprise.

19

Re: Reusage of existing methods

Hello, Stalker., you wrote: a C>> ? Search of a line in the table will be necessary anyway if only in an index there are no ALL fields necessary for performance of request. And search in a principal key - the most effective operation in a DB. S> there is a table with 30 fields. There is a search in 3 fields, on an output essence with 6 fields. The index on 3 fields becomes, the remained 3 fields are added as included. Search in an index returns at once essence. If it is critical request on time - well and the separate method is done. What problems? Really them will well a maximum of ten pieces. A C>> Well so we add new fields in model of service and forward from songs. S> and so to everyone  also are added now. From it also it would be desirable to leave That in it of bad?

20

Re: Reusage of existing methods

Hello, Glory, you wrote:>> Generally, my council - it is not necessary to complicate a C. If superfluous methods about 20 % it is not necessary to fool a head - let and remain. Well and whenever possible classic methods  to the logician on the server. If to leave in jungle OData and any languages of requests it is possible there for ever and to remain. I suspect that in Amazone where you work, is in large quantities used Java or Scala, and for them to this day, in 2017 there are no normal means for creation dynamic *. There where I work, there are no dynamic requests generally. As well as . There where  is, too it is few dynamic requests or only very supervised. Well because it not for , and for those who writes on a rock, the tangency to a DBMS is  . From here and your so skeptical relation to means which simply works. On the Rock we quite write to ourselves. But the relation to "simply works" to monsters of type odata - strictly negative. The pair of hundreds superfluous stupid code lines, than weeks of debugging workaround' for "clever" decisions will be better let.

21

Re: Reusage of existing methods

Hello, Cyberax, you wrote: the C> If is critical request on time - well and the separate method is done. What problems? Really them will well a maximum of ten pieces. Problems such, what receiving from the client request about request acceleration, instead of the elementary adjustment of an index we will be forced to deliver it the NEW version of a facade of a C> That in it bad? Than reproduction of the identical code by mass of clients is bad? Can though what it is necessary to test all of them? By a problem of duplication of the code started to be taken about 50 years ago probably

22

Re: Reusage of existing methods

Hello, Stalker., you wrote: the C>> If is critical request on time - well and the separate method is done. What problems? Really them will well a maximum of ten pieces. S> problems such that receiving from the client request about request acceleration, instead of the elementary adjustment of an index we will be forced to deliver it the NEW version of a facade If the method is so critical that search in a principal key causes an intolerable overhead projector it is necessary to select it unambiguously in separate API. Such contracts should be explicitly registered, instead of implicit "and here if you request only these 3 fields the request will be in 10 times faster". A C>> That in it of bad? S> than reproduction of the identical code by mass of clients is bad? Can though what it is necessary to test all of them? By a problem of duplication of the code started to be taken about 50 years ago probably There are 100500 different clients? I do not trust. A maximum 2-3.

23

Re: Reusage of existing methods

Hello, Cyberax, you wrote: the C> If a method is so critical that search in a principal key causes an intolerable overhead projector it is necessary to select it unambiguously in separate API. Such contracts should be explicitly registered, instead of implicit "and here if you request only these 3 fields the request will be in 10 times faster". In 10 times will not be. And here the load testing can ruin, or in  starts to brake, try to guess it at a specification stage a C> There are 100500 different clients? I do not trust. A maximum 2-3. Seriously? Their tens in the different countries, I even do not know exact number

24

Re: Reusage of existing methods

Hello, Stalker., you wrote: the C>> If a method is so critical that search in a principal key causes an intolerable overhead projector it is necessary to select it unambiguously in separate API. Such contracts should be explicitly registered, instead of implicit "and here if you request only these 3 fields the request will be in 10 times faster". S> in 10 times will not be. And here the load testing can ruin, or in  starts to brake, try to guess it at a specification stage the Contracts which violation causes  systems (a dip of tests) should be as more as possible explicitly registered. Implicit conditionalities of type "a step to the left, a step to the right - attempt to flight, I shoot on sight", - as a result lead to unsupported system.

25

Re: Reusage of existing methods

Hello, Stalker., you wrote: S> the Problem that if to start to do methods more by "general" it will be obvious for pressing on productivity. Absolutely unobviously. S> and at all a case of various parameters when the new method is almost inevitable, but also in a case when new clients instead of one field of essence it is required to display another. If to pull from basis ALL fields And what for to pull all fields? Projection operation already cancelled?... <<RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>