Repository navigation
Question #1
Description
Activity
I think there are points where it fits and does not comply with solid principles. For example, it does not comply with the single responsibility principle. However, it fits the open & close principle. Because the created classes are closed to change, but on the other hand, when a new job comes, it can be applied quickly.
When choosing a design pattern, you should consider the needs of the project. I reviewed the project you mentioned and saw that you used an ORM. In such a scenario, the repository pattern may cause problems in terms of performance, I wanted to point this out first. Coming to your problem specifically, it is almost impossible to develop a project by adhering to SOLID principles one hundred percent. Regarding the SRP principle, we can clearly see that the repository pattern does not adhere to this principle. For example, where a class has only one concern, it has a lot of concerns. Not only that, what @Burakkylmz said is suitable for OCP, but in some usages, we may have crushed the DRY principle. In conclusion, I can say that the aim is to stick to SOLID as much as possible, not to comply with it as a coercion.
@kadir-code, i'm agree with you. Also, you mentioned another very nice subject. There are problems in scenarios where we open a per-entity repository in the project. That times, we don't disobey to the don't repeat yourself principle.
When choosing a design pattern, you should consider the needs of the project. I reviewed the project you mentioned and saw that you used an ORM. In such a scenario, the repository pattern may cause problems in terms of performance, I wanted to point this out first. Coming to your problem specifically, it is almost impossible to develop a project by adhering to SOLID principles one hundred percent. Regarding the SRP principle, we can clearly see that the repository pattern does not adhere to this principle. For example, where a class has only one concern, it has a lot of concerns. Not only that, what @Burakkylmz said is suitable for OCP, but in some usages, we may have crushed the DRY principle. In conclusion, I can say that the aim is to stick to SOLID as much as possible, not to comply with it as a coercion.
I think the more correct question is, does the repository pattern also act in accordance with the soc principle?
@kadir-code, i'm agree with you. Also, you mentioned another very nice subject. There are problems in scenarios where we open a per-entity repository in the project. That times, we don't disobey to the don't repeat yourself principle.
Let's think about it, you have few objects in your project and you didn't bother to prepare a separate repository for each object, it's okay to a point. But what if you have dozens of objects and the project will be taken care of by other developers at a higher level? It is important that you produce logical solutions and that you can do a lot with little code. Avoid creating a separate repository for each object. I can suggest that we make your repositor generic. Only this time, you call a method, but you get a lot of information related to the entity that you don't want. Once again, we are stuck on performance.
Reacted by Burak YılmazIf I'll give an answer to Songul's question, I'd say that I totally agree with Burak. Because when I use repositories, I focus on entity. Things like CRUD operations, various methods or functions related to this entity might come with one class. Thus we can not ensure our app fully meets SOLID, especially SRP. In the other hand, you don't always have to meet SOLID's requirements but if you do, your app is going to be more improvable by the others. And here that's the point. You are not going to develop a project just by yourself all the time.
Reacted by kadirWhen choosing a design pattern, you should consider the needs of the project. I reviewed the project you mentioned and saw that you used an ORM. In such a scenario, the repository pattern may cause problems in terms of performance, I wanted to point this out first. Coming to your problem specifically, it is almost impossible to develop a project by adhering to SOLID principles one hundred percent. Regarding the SRP principle, we can clearly see that the repository pattern does not adhere to this principle. For example, where a class has only one concern, it has a lot of concerns. Not only that, what @Burakkylmz said is suitable for OCP, but in some usages, we may have crushed the DRY principle. In conclusion, I can say that the aim is to stick to SOLID as much as possible, not to comply with it as a coercion.
I think the more correct question is, does the repository pattern also act in accordance with the soc principle?
Do you mean to use the repository pattern and the unit of work pattern together?
hi kadir, your solid principle work is quite nice. For this reason i want to ask something. I use repository in my project, but i consider to repository pattern does it comply with solid principles?