Thank you very much. I really appreciate it.

Seriously though! He get’s straight to the point!

Thank you!

Thank you! I’m working on getting another one out.

He put up two videos and ghosted.

@@ewomer100 A year ago he seemed very promising ngl

Thank you!

You are right! Thank you for pointing that out! That was an oversight on my part. I’ll see if I can add a note at that part of the video to clarify things. Thanks again for letting me know!

Thank you!

Thanks! I’m working on another video. Apologize for the delay!

@@CodingConcepts :D

@@Zoreens I’m working on one. Promise 🙂

You’re welcome!

Appreciate the nice comment. I am working on another video. Just takes me some time because it’s something I do in my spare time and I’ve been busy at work. I plan on going through the DDD concepts first and take it from there.

For most cases it’s usually acceptable to have different method definitions. -FindByName -FindByEmail -FindByPhone etc.. If your query is particularly complex, or it needs to be used in other areas of the system, typically complex business logic, you may want to look into the specification pattern. In short, you would encapsulate the query logic inside the specification object, and then inject that specification wherever needed, in this case, a repository. Happy Coding! Rob

Thanks for the feedback!

Interesting question! I haven't thought about it from this context. There isn't an obvious tradeoff or drawback that comes to mind. I would say the biggest debate I've seen regarding the pattern has delt with specific implementations. Particularly when injecting an Object Relational Mapper (ORM) such as Entity Framework, which already implements the Repository Pattern (with unit of work) itself and will lead to code duplication and violation of the DRY principle (Don't Repeat Yourself).

@@CodingConcepts Why would you inject an ORM if you already created a custom data access layer with the repository pattern? The only reason I see where you would reach such a situation is if your main data access is already an ORM and you also integrate your own repository for more custom work. Wouldn't this scenario only create complementary code, thus not violating the DRY principle? (i mean it's still not 100% DRY, but still reasonably well)

​@@pictzone Great question! There is no definitive answer to this and it really comes down to the trade-offs you're willing to accept. I find myself writing my own repository classes because I find it makes my code much more testable. I'm a strong advocate for Test Driven Development (TDD) and I believe good code is testable code. By writing my own repositories, I'm able to easily mock their return values with testing tools such as Moq. I'm able to reduce the duplicate code it creates, which you've correctly identified, by using generic repositories in a lot of cases. ORM tools do provide in memory testing tools, but I just don't find the usability as streamlined as Moq. So for me, I find the trade off of increased testability at the cost of some duplication acceptable.

You’re typically going to be using the repository pattern in conjunction with a database or some other data store. You could receive data from a REST Api such as a CustomerId to then fetch additional information about that customer using a repository. I hope that clears things up for you.

Of course! At 2:24 I was trying to illustrate a scenario where a lot of logic resides in the controller. When you see "thick" or "bulky" controllers like this, it becomes very difficult to test your code because of the dependencies these controllers are using. ie: a database. The design at 2:45 is improved because it moves the database dependency out of the controller and into the repository. This puts us in a position to use a Mock for our repository to better target the specifc area of code we're looking to test. Hope this answers your question. Happy Coding! Rob

Take a look at the specification pattern

Thank you for letting me know!

There is a pretty good discussion I had in the comments about this with another viewer. I linked the comment below. Let me know if that clears things up. ukposts.info/have/v-deo/sGZ0Zmaxn5B52Gw.html&lc=UgwoV2MDbSnxx_sXtFR4AaABAg

@@CodingConcepts I don't see the discussion. Is the url correct?

@@titobundy Sorry about that. I'm not seeing the comment any more. I will post the discussion here. Question: I might be confused but i find this pattern really similar to the use of Data Access Objects. Are there any differences ? Should we be using one over the other ? Reply: A Data Access Object (DAO) is all about data persistence. It will sit below the Repository, and will match one to one with an underlying database table or view. It's an object representation of the underlying data schema. It's logicless. The return type of a repository is going to be an Entity or Aggregate which are business objects. They may closely resemble the underlying data schema, but you're getting business objects back. Which will have some form of business logic in them. In general, you'll see DAOs used in more complex architectures, to handle specific persistence requirements. Question: So if i understood correctly, they are used together and DAO will return data as JSON for example, when Repository will cast it to Business objects (and perform other operations) ? Do you have some tips on how to know if we should use DAO, repository or both ? Reply: A repository is an abstraction of a collection of objects. A DAO is an abstraction of data persistence. A UserRepository should only ever return User. It shouldn't for example return a RoleObject. A UserDAO on the other hand, it would be acceptable to return information about a User and have another method to return information about it's Roles. As it's only concern is how the information is persisted/stored in the database. The key thing to note here is it's just returning data for you. A good use case for a DAO would be when the underlying data schema is very complex. Perhaps, that UserObject needs several database operations behind the scenes to construct. Put logic like that in a DAO, not a Repository. An Object Relational Mapper (ORM) such as Entity Framework, is going to eliminate the need for a DAO in most cases. It's going to do most of that work for you.

@@CodingConcepts Thank for your post. I would like to have your point of view. Do you think tools like TypeOrm or Spring Data, which apply the repository pattern, do so according to Martin Fowler's definition in his book Refactoring or perhaps Eric Evans in his book DDD, or do you think such implementations are closer to what DAO offers?

@@titobundy I can't speak specifically to TypeOrm or SpringData as I haven't used those tools before, I mainly use Entity Framework. But in general, I would say both. Modern ORM's are applying the repository "by the book" but are also becoming exceptionally well at mapping complex data objects. I would expect the need for a DAO layer to decrease over time.

Good question! A Data Access Object (DAO) is all about data persistence. It will sit below the Repository, and will match one to one with an underlying database table or view. It's an object representation of the underlying data schema. It's logicless. The return type of a repository is going to be an Entity or Aggregate which are business objects. They may closely resemble the underlying data schema, but you're getting business objects back. Which will have some form of business logic in them. In general, you'll see DAOs used in more complex architectures, to handle specific persistence requirements.

​@@CodingConcepts So if i understood correctly, they are used together and DAO will return data as JSON for example, when Repository will cast it to Business objects (and perform other operations) ? Do you have some tips on how to know if we should use DAO, repository or both ? Thanks for answering !

​@@emmanuelyolou4434 A repository is an abstraction of a collection of objects. A DAO is an abstraction of data persistence. A UserRepository should only ever return User. It shouldn't for example return a RoleObject. A UserDAO on the other hand, it would be acceptable to return information about a User and have another method to return information about it's Roles. As it's only concern is how the information is persisted/stored in the database. The key thing to note here is it's just returning data for you. A good use case for a DAO would be when the underlying data schema is very complex. Perhaps, that UserObject needs several database operations behind the scenes to construct. Put logic like that in a DAO, not a Repository. An Object Relational Mapper (ORM) such as Entity Framework, is going to eliminate the need for a DAO in most cases. It's going to do most of that work for you.

​@@CodingConceptsThe two first lines made it a lot clearer in my mind lol. Thank you very much for taking your time to explain all these concepts in depth !

@@emmanuelyolou4434 No problem! Happy coding 🙂

I agree. Not trying to make the argument that a generic repository is best in all cases. Just trying to show different strategies and implementations. Appreciate your comment.