Rolling Responsibility Pattern Repository

    In many discussions about the applicability of the Repository pattern, I noticed that people are divided into two camps. Within the framework of this text, I will conditionally call them abstractionists and concretists. The difference between the two is how they relate to the meaning of the pattern. The first ones think that a repository is worth having, because It allows you to abstract from the details of data storage. The second ones believe that we cannot completely ignore these details, therefore the idea of ​​the repository itself is meaningless, and its use is a waste of time. The argument between them usually turns into a holivar.

    What is wrong with the repository? Obviously, everything is fine with the pattern itself, but the difference is in the understanding of the developers. I tried to investigate this and came across two main points, which, in my opinion, are the reason for the different attitude towards him. One of them is the “rolling” responsibility of the repository, and the other is the underestimation of unit testing. Under the cut, I will explain the first.

    Repository's Moving Responsibility


    When it comes to building the application architecture, everyone immediately thinks of three layers: the Presentation Layer, the Business Layer and the Data Layer ( see MSDN ). In such systems, business logic objects use repositories to retrieve data from physical stores. Repositories return business entities instead of raw recordsets. This is very often justified by the fact that if we needed to replace the type of physical storage (base, file or service), we would make an abstract repository class and implement a specific storage for the storage we need. It looks something like this: Martin Fowler and MSDN

    image

    speak about the same separation.. As usual, a description is just a simplified model. Therefore, although this looks correct for a small project, it is misleading when you try to port this pattern to a more complex one. Existing ORMs are even more confusing because implement many things out of the box. But suppose a developer only knows how to use the Entity Framework (or another ORM) just to get data. Where, for example, should it put the second-level cache, or the logging of all business operations? In an attempt to do this, it is obvious that he will try to separate the modules by functionality, follow the SPR from SOLID, and build a composition from them, which, perhaps, will look like this:

    image

    Does the repository play the same role as before? The obvious answer is “NO”, because now it does not retrieve data from storage. This responsibility has been transferred to another facility. On this basis, the first discrepancy arises between the camps of abstractionists and concretists.

    Instead of analysis


    If we accept as a rule that all terms should retain their meaning regardless of code modifications, then it would be correct at the first stage not to call the object a repository that simply returns data. This is the DAO pattern of pure water, because its task is to hide a specific data access interface (ling, ADO.NET, or something else). At the same time, the repository may not know anything about such details, collecting all data access subsystems into a single composition.

    Do you think such a problem exists?

    Also popular now: