1

Topic: About confusion with repositories and DAO

People who consider surprise that the correct repository should  as this interface interface IRepository <T> where T: class {List <T> GetAll (); T Find (int entityId); T SaveOrUpdate (T entity); T Add (T entity); T Update (T entity); void Delete (T entity);} It that other, as implementation DAO of a pattern. The repository can not know at all about the mechanic and data storage details (basis, files, service). On small projects a difference not so it is strongly visible. And on big when besides requests, still it is necessary to fasten , , a filtration on the auxiliary fields, suddenly it appears that a repository already at all the same that DAO. From here and questions at beginners, type, whether should have a repository methods GetSomethingByUser, GetUserTickets or it is simple CRUD without knowing about other repositories and types. And modern  confuse  even more strongly, implementing all Data Access a layer. And that DAO named repositories start to think that repositories are not necessary, and it is possible to stitch a Linq-code all business the logic. Even pictures at Fowler and on MSDN promote that the repository is perceived, mainly, as the data provider, i.e. Abstraction over RDBMS, though its role more significant at designing. Probably, I read DDD books. Whether it seems to you, what it is time to correct a little idea of a repository that when one spoke another this term both understood something one?

2

Re: About confusion with repositories and DAO

Hello, another_coder, you wrote: whether _> it seems to you, what it is time to correct a little idea of a repository that when one spoke another this term both understood something one? It seems to us that the idea of a repository concerning a DB is time for burying for a long time.

3

Re: About confusion with repositories and DAO

Hello, IT, you wrote: IT> it seems To us that the idea of a repository concerning a DB is time for burying for a long time. And what for a class at us in the project, is called Repository?

4

Re: About confusion with repositories and DAO

Hello, another_coder, you wrote: _> it is possible, I read DDD books. If it is short, domain-driven is very sensible and cynical approach to designing of systems. Once again: about designing, about "a method to think", not about implementation. I.e. as soon as the next expert starts to tell about  at code level because DDD it is possible to deliver a small volume and tenderly to knock on a head, to suggest to renew. Well and further under the text the Author: Sinix Date: 15.02 10:19. Whether _> it seems to you, what it is time to correct a little idea of a repository that when one spoke another this term both understood something one?  to dig. As well as the most terrible sin of the architect: a habit to mold patterns without thinking about implementation tools. It is necessary to begin with the task, language and used  - here then it is already possible to consider something in detail.

5

Re: About confusion with repositories and DAO

6/13/2016 18:58, IT writes: whether> _> it seems to you, what it is time to correct a little idea of a repository,> that when one told another this term both understood something one?>> it seems to us that the idea of a repository concerning a DB is time for burying for a long time. Hurrah, I such not one. - WBR, Serge. Posted via RSDN NNTP Server 2.1 beta

6

Re: About confusion with repositories and DAO

Hello, MozgC, you wrote: IT>> it seems To us that the idea of a repository concerning a DB is time for burying for a long time. MC> and what for a class at us in the project, is called Repository? At us the class so is called only because somehow was not invented other title. But with the offered interface of a repository it has not something in common. At first, we generally do not have any interface because it  is not necessary. Secondly, the primary goal of our class - possibility of testing of processes which use it without data reading from basis. I.e. it is closer to DI, than to pattern Repository. And here the repository is necessary as a part or even changeover DAO, such classical vestige of the heavy past.

7

Re: About confusion with repositories and DAO

Hello, another_coder, you wrote: _> It that other, as implementation DAO of a pattern. The repository can not know at all about the mechanic and data storage details (basis, files, service). On small projects a difference not so it is strongly visible. And on big when besides requests, still it is necessary to fasten , , a filtration on the auxiliary fields, suddenly it appears that a repository already at all the same that DAO. _> From here and questions at beginners, type, whether should have a repository methods GetSomethingByUser, GetUserTickets or it is simple CRUD without knowing about other repositories and types. I for all central types, i.e. master in terminology master-detail have a repository and here there just a heap here such methods GetSomethingByUser, GetSomethingByUser etc.

8

Re: About confusion with repositories and DAO

Hello, IT, you wrote: IT> Hello, another_coder, you wrote: whether _>> it seems to you, what it is time to correct a little idea of a repository that when one spoke another this term both understood something one? IT> it seems to us that the idea of a repository concerning a DB is time for burying for a long time. And it is possible on more in detail (for own outlook)? On serious dataful of basis we do not work, in the core editing , and there is hardly on more difficult a functional - well and all. Idle time DataGrid in.NET, is very similar to a repository. Objects are stored, with status Updated/Deleted/Inserted and then by certain button OK all it is written to basis. It is a trivial case, but for editing  quite. If to complicate logic something we do, we do, we do, then we press Save and all left in basis (here certainly it is possible to run into conflicts, but it already other subject).

9

Re: About confusion with repositories and DAO

This question in a network rises often enough, but it is possible to talk about it once again. At first, for a repository there is good enough determination: it is a collection implementing long-term storage of the same objects of a domain model and abstracting the user from details of implementation (= in other words Fowler's statement). The example resulted by you completely corresponds to this determination, therefore can quite describe the repository interface. Secondly, Fowler does not select separately DAO as a pattern and, to tell the truth, I did not meet classification in which simultaneously there are both patterns, therefore it is possible to consider them independent from each other. If to look for example at this article which describes DAO how very many developers it is possible to note understand it that DAO it is simple a component of a layer of data access, without any additional determinations and conditions. Actually, under determination DAO all patterns of section Data Source Architectural Layer from here get. I.e. any repository - DAO, but not any DAO - a repository. Further, you write: a> And on big when besides requests, still it is necessary to fasten , , a filtration on the auxiliary fields, suddenly it appears that a repository already at all the same that DAO. Here all is mixed in one big heap with the incorrect inference. Logic of implementation of "requests" (methods, or, how in  OOP, "messages"?), caching and  - singularities of internal implementation about which the client does not know. A filtration on the auxiliary fields - interface DAO part (and as it is told above, maybe, a repository) and object of domain model (property of object which is used by business logic, is a part of domain model, therefore the word "auxiliary" here has no special sense).

10

Re: About confusion with repositories and DAO

Hello, IT, you wrote: IT> it seems To us that the idea of a repository concerning a DB is time for burying for a long time. It why?

11

Re: About confusion with repositories and DAO

Hello, Baudolino, you wrote: IT>> it seems To us that the idea of a repository concerning a DB is time for burying for a long time. B> it why? Because in last years 8 there were more advanced modes of work from a DB.

12

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. And it is possible it is more torn? What?

13

Re: About confusion with repositories and DAO

Hello, Baudolino. First of all, I want to mark that speech not that current variants of usage wrong. Speech about change of a paradigm of consciousness concerning a repository which, in my opinion, ripened. Ripened because such talks arise permanently, being a consequence of ambiguity of this concept. Further I will try to explain using your examples. You wrote: B> At first, for a repository there is good enough determination: it is a collection implementing long-term storage of the same objects of a domain model and abstracting the user from details of implementation (= in other words Fowler's statement). Now, such determination, in my opinion, misleads people since is too the general. Behind this determination any functional, any can disappear. And the resulted example, really, satisfies. But it not a repository. B> I.e. Any repository - DAO, but not any DAO - a repository. Because of such representation also there is a confusion in dialogue. I think, it is necessary to divide flies from cutlets: DAO - abstraction over storage to the data, without logic connected to business, Repository - it is similar, as aggregate root in DDD. It is mixed Nothing. Look and try to think, where you it will reduce all in uniform system? B> the logic of implementation of "requests" Is pure DAO, or ORM framework. B> caching and  - singularities of internal implementation about which the client does not know. It is the service logic which can change it is not dependent on storage on not dependent on designing and a software  either the client, or . At what level it will be used? B> a filtration on the auxiliary fields - interface DAO part (and as it is told above, maybe, a repository) the Auxiliary fields to the auxiliary fields . There are that are a part logic business, there are those, a part of integrity of data storage, and are that are necessary within the limits of system maintenance. Where concerns, for example, IsDeleted (means, what is deleted nothing), and where a filtration on CreatedDate (means not to show too old)? And in addition in the presence of all you start to think, how all it to test. Start to select multifunctions that from them to be isolated. You find out that, for example, IsDeleted should be up to standard DAO, CreatedDate - in Repository, thus 2L  it is necessary for you also you think of fastening 3rd party library and it too it is necessary in Repsoitory. And here  most likely it to be necessary for you in DAO. Though, any clever auxiliary ( for support, for example, or for collection  information)  you besides thrust in . Certainly, it is too much conditions to lead an accurate line between meanwhile that where concerns. But that it would be desirable to see, this understanding of that Data Layer is not one class in which at first all falls down, and then turns that it is difficult to test and support. It should be simple and angry: DAO - object of data access, Repository - object of data preparation to BO. Without any generalizations and "transformations"  in DAO as you wrote. And at once I will answer a possible question about  and  to the logician in . No, it does not stitch its code, and  there, being described in other classes. And in any way differently.

14

Re: About confusion with repositories and DAO

Hello, another_coder, you wrote: _> Hello, Baudolino. _> Now, such determination, in my opinion, misleads people since is too the general. Behind this determination any functional, any can disappear. Any, satisfying to pattern determination. It is a normal situation. _> and the resulted example, really, satisfies. But it not a repository. It is a repository on determination. And on standard enough determination. If you want to make other determination, give, but you will need to explain, than it is better. B>> I.e. any repository - DAO, but not any DAO - a repository. _> Because of such representation also there is a confusion in dialogue. The confusion in dialogue normally arises that someone something does not know or does not understand. Normally dares a phrase "give to begin with we define that the such..." And a glossary in the architectural documentation. _> I think, it is necessary to divide flies from cutlets: DAO - abstraction over storage to the data, without logic connected to business, Repository - it is similar, as aggregate root in DDD. You suggest to separate flies from cutlets, but use words "similarly" and "as". Good determination should not use analogy because determination by analogy is unsharp: it is necessary on mental model of the reader which at different people can be different. Make accurate determination in Russian and we consider it. _> it is mixed nothing. Look and try to think, where you it will reduce all in uniform system? B>> the logic of implementation of "requests" _> Is pure DAO, or ORM framework. What is "pure DAO"? That means in this case "or": if it ORM, it not DAO? Or DAO=ORM? How from it repository determination changes? B>> caching and  - singularities of internal implementation about which the client does not know. _> it is the service logic which can change it is not dependent on storage on not dependent on designing and a software  either the client, or . At what level it will be used? What is "the service logic"? Auxiliary? Logic of a service layer? Caching is algorithmic, instead of an architectural pattern. As your component of access to a DB is implemented is the latent detail of implementation. The repository can cache, the DB gateway - can, the client of a layer of data access - can. The essence of determinations from it does not change. B>> a filtration on the auxiliary fields - interface DAO part (and as it is told above, maybe, a repository) _> the Auxiliary fields to the auxiliary fields . There are that are a part logic business, there are those, a part of integrity of data storage, and are that are necessary within the limits of system maintenance. Where concerns, for example, IsDeleted (means, what is deleted nothing), and where a filtration on CreatedDate (means not to show too old)? It is specificity of the functional requirements to specific system which need to be analyzed properly. Let's disassemble on example IsDeleted. In itself such field never appears - it is a part of requirements to an application infrastructure, to that as specific entities are processed given generally, instead of. As a rule, its task - to save the data for audit, planned or in an emergency situation (for  such method approaches badly). To understand, at what level this flag appears, it is necessary to find the ultimate user and the interface used by it. If this same application without variants is a part of domain model and interface DAO knows about its existence (for example, in the form of type ad hoc methods findDeleted). If for reading of this flag other application (for example, the regular client of a DB) is used - at you takes place to be integration through a DB, this flag is a part of the protocol of integration, i.e. a singularity of internal implementation DAO. Thus all aforesaid does not influence in any way a choice of specific type DAO: it can concern equally a repository, the gateway of the table of a DB (table data gateway), etc. _> And in addition in the presence of all you start to think, how all it to test. Start to select multifunctions that from them to be isolated. You find out that, for example, IsDeleted should be up to standard DAO, CreatedDate - in Repository, thus 2L  it is necessary for you also you think of fastening 3rd party library and it too it is necessary in Repsoitory. And here  most likely it to be necessary for you in DAO. Though, any clever auxiliary ( for support, for example, or for collection  information)  you besides thrust in . As I already spoke, in my representation the repository is variety DAO, and you yet did not offer alternative treatment. Problems with testing I do not see generally any. Even with everything that you mentioned, tests (both a unit, and integration) here will be very simple. That changes what you have a dependence of one component on another with accurately certain interface allowing in need of the test to inject a stub for verification of interaction? _> it is finite, it is too much conditions to lead an accurate line between meanwhile that where concerns. But that it would be desirable to see, this understanding of that Data Layer is not one class in which at first all falls down, and then turns that it is difficult to test and support. _> it should be simple and angry: DAO - object of data access, Repository - object of data preparation to BO. Without any generalizations and "transformations"  in DAO as you wrote. To whom should? Here I, by the way, started to understand approximately where you drive. Let's discard for a minute all our representations about patterns-figatternah, and we consider the task in a general view to define them anew. So, we have a business logic implemented within the limits of OOP. There is a data store, more often relational (). We need to provide date transmission from storage in business logic. As storage heavy, implemented by outside people, we want with a view of simplicity of support and testing to isolate access to it in a separate architectural layer. We name it Data Access Layer (DAL). In this layer we will have a quantity of components which will be used by business logic. Following step we define a type of these components, selecting level of connectivity of business logic and storage. If we are ready to sacrifice flexibility in favor  productivity, we select the interface of components in which each method represents a certain request to a DB and returns transient object (DTO). We name type of such components Table Data Gateway. If we want on the contrary that the business logic perceived storage simply as a certain collection, we in the interface of components DAL will use type methods to add/replace/remove and we name such components Repository. Each such component will correspond to one essence of model (or one hierarchy). Having defined with interfaces, we start an implementation choice. We will use any standard API for access to a DB which allows us to fulfill SQL queries and to receive in the answer tabular data. As we need to transform a relational model to objective, objective-relational display (ORM) is required to us. It can be implemented independently, building requests and  data retrieveds (in that case it is necessary to carry out logic of creation of requests and readings of results in a separate class - Object-Relational Mapper), and it is possible to select the ready ORM-decision which using declarative model of the description of display, reduces the code of your repository to one line in each method. Further, the storage is far from a development node, therefore we want to accelerate its operation at the expense of algorithm of caching. We can use a ready cache, therefore we add in the necessary methods of component DAL attempt of reading from a cache before reading from a DB. The cache will be presented at us by the simple interface with type methods get/putIfAbsent/invalidate, etc. For  to specific implementation of a cache to our component DAL, container DI will answer. But is better will adjust in that case a cache in ORM/f and at all  on own implementation of logic. As to journalizing and error handling,  the code such auxiliary logic not mandatory if you have a possibility to turn your components in proxy which will be  calls of methods. It normally becomes by means of AOP. And now attention, a question: and where here actually there should be your sharing on "object of data access" and "object of data preparation to IN"? (Also what such IN?) _> And at once I will answer a possible question about  and  to the logician in . And who would bring this attention to the question? Like all normal people already use for a long time DI.

15

Re: About confusion with repositories and DAO

Hello, IT, you wrote: IT> Hello, Baudolino, you wrote: IT>>> it seems To us that the idea of a repository concerning a DB is time for burying for a long time. B>> it why? IT> Because in last years 8 there were more advanced modes of work from a DB. And and here a DB and if it is necessary to store the data simply in storage, and for storage to throw off them in a file through  how then to organize operation dataful? For certain as be so: class UserCollection {int Add (User user) {} void Remove (User user) {} IEnumerable <User> Find (Specification s) {}} Than not a repository? If by development to use principles grasp the repository should appear.

16

Re: About confusion with repositories and DAO

Hello, Qulac, you wrote: Q> Than not a repository? If by development to use principles grasp the repository should appear. : the code of the healthy person looks approximately so: [Transactional] void SetRecordData (string code, string data) {var existing = Context. FirstOrDefault <MyRecord> (r => r. Code == code); if (data == null) {existing?.Delete ();} else {if (existing == null) {existing = Context. NewObject <MyRecord> (r => r. Code = code);} existing. Data = data;}} I.e. a zero of the technical details, all magic under a cowl. Certainly, the code spherical in vacuum, is simple to show the main scenarios. On occasion it can appear more favourably  sql merge statement, in others - to be confused with correct handling simultaneous update/delete and  and .

17

Re: About confusion with repositories and DAO

Hello, Qulac, you wrote: IT>> Because in last years 8 there were more advanced modes of work from a DB. Q> and and here a DB and if it is necessary to store the data simply in storage, and for storage to throw off them in a file through  how then to organize operation dataful? Thus that without a DB the repository has even less sense. If at you bluntly collection in storage, it List <T>. On  Dictionary <TKey, T>. During the necessary moments of time they  in a file, and at program start will be deserialised from a file.

18

Re: About confusion with repositories and DAO

Hello, gandjustas, you wrote: G> Hello, Qulac, you wrote: IT>>> Because in last years 8 there were more advanced modes of work from a DB. Q>> and and here a DB and if it is necessary to store the data simply in storage, and for storage to throw off them in a file through  how then to organize operation dataful? G> thus that without a DB the repository has even less sense. G> if at you bluntly collection in storage, it List <T>. On  Dictionary <TKey, T>. During the necessary moments of time they  in a file, and at program start will be deserialised from a file. Not well it is natural that inside our collection will be List, Dictionary or that that still similar. Sense: at us that does not stick out superfluous through the interface and if any data samplings repeat in the program in many places here we them  in our collection in the form of methods. All logic of operation dataful in one place to test easier.

19

Re: About confusion with repositories and DAO

Hello, Sinix, you wrote: S> Hello, Qulac, you wrote: Q>> Than not a repository? If by development to use principles grasp the repository should appear. S> Kep: the code of the healthy person looks approximately so: S> S> [Transactional] S> void SetRecordData (string code, string data) S> {S> var existing = Context. FirstOrDefault <MyRecord> (r => r. Code == code); S> if (data == null) S> {S> existing?.Delete (); S>} S> else S> {S> if (existing == null) S> {S> existing = Context. NewObject <MyRecord> (r => r. Code = code); S>} S> existing. Data = data; S>} S>} S> S> I.e. a zero of the technical details, all magic under a cowl. S> Certainly, the code spherical in vacuum, is simple to show the main scenarios. On occasion it can appear more favourably  sql merge statement, in others - to be confused with correct handling simultaneous update/delete and  and . Well on health how to be told, to whom how to be pleasant.

20

Re: About confusion with repositories and DAO

Hello, Qulac, you wrote: Q> Hello, gandjustas, you wrote: G>> Hello, Qulac, you wrote: IT>>>> Because in last years 8 there were more advanced modes of work from a DB. Q>>> and and here a DB and if it is necessary to store the data simply in storage, and for storage to throw off them in a file through  how then to organize operation dataful? G>> thus that without a DB the repository has even less sense. G>> if at you bluntly collection in storage, it List <T>. On  Dictionary <TKey, T>. During the necessary moments of time they  in a file, and at program start will be deserialised from a file. Q> not well it is natural that inside our collection will be List, Dictionary or that that still similar. Sense: at us that does not stick out superfluous through the interface and if any data samplings repeat in the program in many places here we them  in our collection in the form of methods. All logic of operation dataful in one place to test easier. In List <T> there is a superfluous? Logic in different places? You about what generally? If in the program the list of people is necessary to you, for example, that what for to fence something atop List <T>? You should not test List <T>. And if samplings repeat, do an extension-method for List <Person>.

21

Re: About confusion with repositories and DAO

Hello, gandjustas, you wrote: G> you should not test List <T>. And if samplings repeat, do an extension-method for List <Person>. And if it has to work differently with List <T> (storage) depending on the customer? Different samplings without change of the main logic.

22

Re: About confusion with repositories and DAO

Hello, another_coder, you wrote: _> Hello, gandjustas, you wrote: G>> you should not test List <T>. And if samplings repeat, do an extension-method for List <Person>. _> And if it has to work differently with List <T> (storage) depending on the customer? Different samplings without change of the main logic. Differently it as? Give an example.

23

Re: About confusion with repositories and DAO

Hello, gandjustas, you wrote: Q>> And and here a DB and if it is necessary to store the data simply in storage, and for storage to throw off them in a file through  how then to organize operation dataful? G> thus that without a DB the repository has even less sense. And at what here generally any specific implementation? Lists, a DB... Why you do not consider a remote web service, for example, in that case? The task of any architectural pattern - a complexity fragmentation. Patterns DAL separate complexity of business logic from complexity of operation with data store by means of a different type of interfaces. Repository abstracts a DB as a collection, TDG as the objective interface to the table, CQRS isolates separate operations etc. Architectural patterns are the interfaces which implementation can be any. Using them, you speak: to the client should be all the same that behind this interface while they observe the contract. Changes in implementation, for example, optimization of productivity or journalizing, are reliably hidden behind this contract and do not break the client code. Implementation in the form of storage in storage here simply convenient bun for early development cycles and units-tests.

24

Re: About confusion with repositories and DAO

Hello, Baudolino, you wrote: B> Hello, gandjustas, you wrote: Q>>> And and here a DB and if it is necessary to store the data simply in storage, and for storage to throw off them in a file through  how then to organize operation dataful? G>> thus that without a DB the repository has even less sense. B> And at what here generally any specific implementation? Lists, a DB... Why you do not consider a remote web service, for example, in that case? Because with a web service, a database and the list in storage operation is conducted absolutely differently. 1) the List in storage it is possible to bypass all the operator foreach 2) To a web service it is possible to make request with certain parameters 3) To basis it is possible to make SQL request, and still it supports transactions. How you hide these three in essence different operations behind one general-purpose interface? In C# by the way invented such general-purpose interface - linq requests. But linq the provider very few people writes the, uses the ready. Here and the answer to a question why pattern Repository is useless presently. B> the task of any architectural pattern - a complexity fragmentation. Patterns DAL separate complexity of business logic from complexity of operation with data store by means of a different type of interfaces. Normal functional decomposition too is engaged  complexities. For this purpose it is not necessary to create separate entities and patterns. And generally nobody says that it is necessary in  to cause SqlCommand. It is necessary to use the functional decomposition. B> Repository abstracts a DB as a collection It is the first and principal error.  objects in storage and the table in a DB possess in essence different properties from the point of view of the code even if it is possible to reduce them to one interface. B> architectural patterns are the interfaces which implementation can be any. Cannot, at them contracts different. Sm above. B> Changes in implementation, for example, optimization of productivity or journalizing, are reliably hidden behind this contract and do not break the client code. For this purpose again the repository as a pattern is not necessary. B> implementation in the form of storage in storage here simply convenient bun for early development cycles and units-tests. In itself adding of a repository at early stages - useless complication of the code. It is possible is banal to address to static lists in storage there will be no yet a necessity to save the data.

25

Re: About confusion with repositories and DAO

Hello, gandjustas, you wrote: G> Hello, Qulac, you wrote: Q>> Hello, gandjustas, you wrote: G>>> Hello, Qulac, you wrote: IT>>>>> Because in last years 8 there were more advanced modes of work from a DB. Q>>>> and and here a DB and if it is necessary to store the data simply in storage, and for storage to throw off them in a file through  how then to organize operation dataful? G>>> thus that without a DB the repository has even less sense. G>>> if at you bluntly collection in storage, it List <T>. On  Dictionary <TKey, T>. During the necessary moments of time they  in a file, and at program start will be deserialised from a file. Q>> not well it is natural that inside our collection will be List, Dictionary or that that still similar. Sense: At us that does not stick out superfluous through the interface and if any data samplings repeat in the program in many places here we them  in our collection in the form of methods. All logic of operation dataful in one place to test easier. G> in List <T> there is a superfluous? Logic in different places? You about what generally? G> If in the program the list of people is necessary to you, for example, that what for to fence something atop List <T>? What for generally then the architecture on, sharing of interfaces and other, other is necessary. We after all about architecture speak or not? Then generally that it is not necessary, it is possible to write anyhow. G> you should not test List <T>. And if samplings repeat, do an extension-method for List <Person>. It is a special case of a solution of a problem, he does not solve a problem of too wide interface list who the husband is not in all languages.