51

Re: About confusion with repositories and DAO

Hello, gandjustas, you wrote: G> Hello, another_coder, you wrote: IT>>> Druzhishche, tell how many you personally wrote systems in which what exactly is unimportant there is a data source (a DB, IList, a file or web service)? _>> the Couple is. G> tell about them. After you. Only do not forget to result architecture with  why such decision was accepted. More I do not see sense to continue this , since .

52

Re: About confusion with repositories and DAO

G> give the reference to the one who proved this axiom. I perhaps will finish our talk on this wonderful citation.

53

Re: About confusion with repositories and DAO

Hello, Baudolino, you wrote: G>> give the reference to the one who proved this axiom. B> I perhaps will finish our talk on this wonderful citation. Ah, forgive, incorrectly expressed. Give the reference to well-known work on OOP in which the given axiom though is somehow used for a substantiation of model of OOP and its advantages.

54

Re: About confusion with repositories and DAO

Hello, another_coder, you wrote: _> Hello, gandjustas, you wrote: G>> Hello, another_coder, you wrote: IT>>>> Druzhishche, tell how many you personally wrote systems in which what exactly is unimportant there is a data source (a DB, IList, a file or web service)? _>>> the Couple is. G>> tell about them. _> After you. Only do not forget to result architecture with  why such decision was accepted. More I do not see sense to continue this , since . Yes here I somehow did not have examples that the same program could work with any data source. The reverse is faster. Even small distinctions in different engines of a DB led to the various code, even with application ORM.

55

Re: About confusion with repositories and DAO

Hello, another_coder, you wrote: IT>> Druzhishche, tell how many you personally wrote systems in which what exactly is unimportant there is a data source (a DB, IList, a file or web service)? _> the Couple is. And it there really was necessary or all for the sake of ?

56

Re: About confusion with repositories and DAO

Hello, Baudolino, you wrote: IT>> the Big uncles use recently exceptional LINQ. B> Between us, the big uncles, LINQ exists only on one, and not to the most popular platform. To us, the big uncles .

57

Re: About confusion with repositories and DAO

Hello, another_coder, you wrote: G>> Tell about them. _> After you. Categorically pulls on draining.

58

Re: About confusion with repositories and DAO

Hello, gandjustas, you wrote: G> Hello, another_coder, you wrote: _>> Hello, gandjustas, you wrote: G>>> Differently it as? Give an example. _>> well for example, 1 selects on one flag, 2 selects on two. The system , and logic of operation is defined dynamic. Storage at all IList. G> to Make two functions not? So it is possible. Speech here not about a choice of the optimal decision, and on a sight at a role . Not , .

59

Re: About confusion with repositories and DAO

Hello, IT, you wrote: IT> Hello, another_coder, you wrote: IT>>> Druzhishche, tell how many you personally wrote systems in which what exactly is unimportant there is a data source (a DB, IList, a file or web service)? _>> the Couple is. IT> and it there really was necessary or all for the sake of ? It has been made necessarily. Sense to answer is not present more deeply. If is interesting get a separate subject.

60

Re: About confusion with repositories and DAO

Hello, another_coder, you wrote: _>>> Well for example, 1 selects on one flag, 2 selects on two. The system , and logic of operation is defined dynamic. Storage at all IList. G>> to Make two functions not? _> So it is possible. Speech here not about a choice of the optimal decision, and on a sight at a role . Not , . Not simply about a role, whether and about that intelligently it to use. You suggest to mold some pattern, there where enough two . In this case the pattern should possess clear advantages. Tell about them.

61

Re: About confusion with repositories and DAO

Hello, gandjustas, you wrote: G> Alan Kej and Bertran Meyer just in the determinations of OOP lean against ghost effects at interaction with objects. Excuse, but  an eye. Alan Kej . OOP as possibility of sending of messages objects - on it can stretch ghost effects, of course. Meyer in OOP determination generally does not mention ghost effects. Martin or someone similar said that ghost effects are for the sake of what there is a calculation.

62

Re: About confusion with repositories and DAO

Hello, gandjustas. G> You offer... I do not offer. Re-read more attentively, ?

63

Re: About confusion with repositories and DAO

Hello, Sharov, you wrote: S> Hello, gandjustas, you wrote: G>> Alan Kej and Bertran Meyer just in the determinations of OOP lean against ghost effects at interaction with objects. S> excuse, but  an eye. Alan Kej . OOP as possibility of sending of messages objects - on it can stretch ghost effects, of course. Meyer in OOP determination generally does not mention ghost effects.  spoke that objects communicate by means of sending of messages. Meyer directly says that objects - +, and also ++. What of these determinations intelligently if we eliminate ghost effects from methods or messages? S> Martin or someone similar said that ghost effects are for the sake of what there is a calculation. I know that ghost effects - for the sake of what there is a calculation. But it at all does not mean that it is necessary to lean at designing against ghost effects. In practice to do pure functions just easier, and ghost effects to isolate. But it on , instead of OOP.

64

Re: About confusion with repositories and DAO

Hello, gandjustas, you wrote: S>> Excuse, but  an eye. Alan Kej . OOP as possibility of sending of messages objects - on it can stretch ghost effects, of course. Meyer in OOP determination generally does not mention ghost effects. G> Kej spoke that objects communicate by means of sending of messages. G> Meyer directly says that objects - +, and also ++. Not, he (Meyer) spoke about the abstract data types, as the major line of OOP. "+" it is strong more low. G> what of these determinations intelligently if we eliminate ghost effects from methods or messages? The valid remark, but generally any determination intelligently as it is a question of other method of speculations over ghost effects, at other abstraction layer. I.e. they somewhere are present (at methods, certainly), but not this already principal. G> to lean against ghost effects. Well sounds, .

65

Re: About confusion with repositories and DAO

Hello, IT, you wrote: IT>>> Because in last years 8 there were more advanced modes of work from a DB. B>> and it is possible it is more torn? What? IT> the big uncles use recently exceptional LINQ. So, and if in basis there is more than hundred tables and some hundreds , functions and another ?  it is is easier sensitive  the interface  and to receive hyperfine "repository" over a link, it is stupid for convenience of operation. interface IRepository <T> where T: class {ListIQueryable <T> All {get; private set;}; T Find (int entityId); T SaveOrUpdate (T entity); T Add (T entity); T Update (T entity); void Delete (T entity);} in that case all these SP would leave in appropriate repositories (for compatibility) and they could be altered easy in normal  functions, leaving SP only there where it is really necessary. Plus will be a place for the general logic.

66

Re: About confusion with repositories and DAO

Hello, Baudolino, you wrote: B> the Task of any architectural pattern - a complexity fragmentation. Provided that architectural decisions do not import even more problems, than solve. B> patterns DAL separate complexity of business logic from complexity of operation with data store by means of a different type of interfaces. Not absolutely so. DAL isolates operation with basis in terms of the basis from a remaining part of application by conversion of terms of application in DB terms and on the contrary. With it consults LINQ is much better.

67

Re: About confusion with repositories and DAO

Hello, __ SPIRIT __, you wrote: IT>> the Big uncles use recently exceptional LINQ. __ S> So and if in basis there is more than hundred tables and some hundreds , functions and another ? From  it is necessary  at the first opportunity. The logic in a DB is today a nonsense. As to hundreds everyone  I do not see any problems. Under tables the data model of application which by the way, can include both functions and the saved procedures is generated.

68

Re: About confusion with repositories and DAO

Hello, IT, you wrote: IT>>> the Big uncles use recently exceptional LINQ. __ S>> So and if in basis there is more than hundred tables and some hundreds , functions and another ? IT> From  it is necessary  at the first opportunity. So that it so, but process is rather expanded in time... IT> the Logic in a DB is today a nonsense. As to hundreds everyone  I do not see any problems. Under tables the data model of application which by the way, can include both functions and the saved procedures is generated. Yes but if it is all to push in one  a context, there  will not find. Much more conveniently to scatter them on "repositories"

69

Re: About confusion with repositories and DAO

Hello, __ SPIRIT __, you wrote: IT>> From  it is necessary  at the first opportunity. __ S> so that it so, but process is rather expanded in time... For this reason  linq2db since at all does not impose the architecture and it is possible to start to use all in . __ S> yes but if it is all to push in one  a context, there  will not find. Much more conveniently to scatter them on "repositories" Use circuits. linq2db for circuits generates separate classes. For example, if table Issuer is in circuit Instrument reversal to it will be db. Instrument. Issuers it is very convenient.

70

Re: About confusion with repositories and DAO

Hello, IT, you wrote: IT> Use circuits. linq2db for circuits generates separate classes. For example, if table Issuer is in circuit Instrument reversal to it will be IT> db. Instrument. Issuers IT> it is very convenient. Basically a variant.

71

Re: About confusion with repositories and DAO

Hello, IT. A question concerning terminology. How you name object which will connect in a uniform configuration such things, how , audit  to the data, data access and something else? Thus I want to change a data access method, leaving all remaining.

72

Re: About confusion with repositories and DAO

Hello, Baudolino. I still will look at this big answer. But here the interesting question at me arose on the same subject. You can,  look? Interesting your judgement here the Author: another_coder Date: 22.06 11:06

73

Re: About confusion with repositories and DAO

Hello, another_coder, you wrote: _> the Question concerning terminology. How you name object which will connect in a uniform configuration such things, how , audit  to the data, data access and something else? I such piece would name a dustbin.

74

Re: About confusion with repositories and DAO

Hello, IT, you wrote: IT> I such piece would name a dustbin. Nevertheless, it is in each project. Describe, how all of you it unite in one project? If you had an experience, certainly.

75

Re: About confusion with repositories and DAO

Hello, another_coder, you wrote: _> Hello, IT. _> the Question concerning terminology. How you name object which will connect in a uniform configuration such things, how , audit  to the data, data access and something else? Thus I want to change a data access method, leaving all remaining. I do not know as at you, and at me these functions fulfills Entity Framework. He is able  requests, saves interrogated objects in storage and actually obtains the data. You all the same work to result the scenario, when also that it is necessary to change in data access and what for this purpose abstractions you will create. The spherical horse otherwise turns out.