Hello, Baudolino, you wrote: B> Hello, gandjustas, you wrote: G>> As you hide these three in essence different operations behind one general-purpose interface? B> there is such word "abstraction", know? Let's recall its determination: the abstraction is technics of the analysis in whom essential aspects come to light, and insignificant are eliminated. You insignificant not declared that. Insignificant distinctions it to do Repository or extension-methods for List <T>. This distinction does not influence program characteristics. And the data source type very strongly influences. B> 1. To the client it is necessary foreach: the repository should be able to return the iterator on objects stored in it. It can be implemented at the expense of reversal to storage and caching of results for productivity optimization. If the storage - area of operative storage, a cache is not required, if remote service or a DBMS - it is possible to find data packages and to save in a cache. B> 2. Search in parameters is necessary to the client: the repository should give a method of search with parameters. Implementation will build the filter or to form request to storage - variants much. B> 3. To the client it is necessary : , but it normally becomes at business logic level (the transaction manager should use the general sessions together with all transactional services, not only with repositories, but also, for example, queues). If suddenly you decided to make nevertheless support of transactions by a repository part, it is necessary, certainly to implement its logic. Perfectly - you have a web service, normal web api with Get and Post on a key. And you a repository with search in parameters. What further to do? Also it was necessary initially such to do it? G>> in C# by the way invented such general-purpose interface - linq requests. But linq the provider very few people writes the, uses the ready. G>> here and the answer to a question why pattern Repository is useless presently. B> LINQ represents the convenient interface of the description of possible requests to objects. In a case from a DB, such object is component DAL if is more exact - ORM. B> the Fact of existence LINQ, generally speaking, means nothing. The fact of existence ORM_ c support Linq means. Because Linq can hide behind the identical interface and the list in storages, and web services (with restrictions) and databases. But nobody will write such from zero for one application, it is necessary to use the ready. Therefore a pattern repository categorically not in a subject, it is necessary to use orm. 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. G>> normal functional decomposition too is engaged complexities. For this purpose it is not necessary to create separate entities and patterns. B> Patterns standardize such decomposition, offering the typical approach to the decision of typical tasks. To refuse their usage there where it is justified, - to invent an unnecessary bicycle. Repository an in itself bicycle in the presence of ORM. You still prove correctness of a repository in comparison with normal decomposition. B>>> Repository abstracts a DB as collection G>> 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> from the point of view of a spherical horse in vacuum probably all. From the point of view of the specific client code of the basic distinctions can and not to be. The basic distinction in speed of operation. As soon as calls start to intersect process it is necessary to watch closely as often happen reversal and how many the data is transferred. The brake shit otherwise turns out. And it too an architecture part. And much more important, than patterns. B>>> architectural patterns are the interfaces which implementation can be any. G>> cannot, at them contracts different. B> the contract is defined by the interface, instead of its implementation. You of that now told? is wider than the interface. For example the interface cannot describe sajd-effects. For ORM the contract normally such - you work with a collection of objects in storage, and then cause function of saving of changes in a DB. Saving does not figure in the interface in any way. And you can erraticly think that the table in basis is equivalent List <T>, though it at all so. B>>> Implementation in the form of storage in storage here simply convenient bun for early development cycles and units-tests. G>> 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. B> At you ten classes working with storage of objects of type of A.Chto are easier - to change in one place implementation of the interface of storage of objects, or to change in all places operation with it from the list for something other? Who to you told about tens classes? B> P.S. Give for more constructive talk we specify positions. I do not state that the repository is necessary always - more likely, I mean that this pattern has sense and application field, therefore the statement that it "is not necessary generally" is not true and is connected, more likely, with misunderstanding of this sense and application field. I state that this pattern does not have application field because for a DB is ORM, and for remaining cases repository does not approach.