Recently I’ve had this idea that came into my mind while working on the Sentry – let the users of my library (if there will be any) to configure not only the set of rules, connection strings, urls etc. but also the underlying providers that do all of the heavy lifting (e.g. the HttpClient responsible for communicating with the API). It means that as long as you’re not satisfied with the default solution, please feel free to provide your own engine that will for example talk to the database and perform a query on it. And that’s one part of the story, however, even the more important thing to do was to test that behavior – I had to be sure that would work. So how can we test the classes (I’m talking mostly about the integration testing), that hardly implementy any interface (pretty much none) such as the mentioned above HttpClient? Actually it turned out to be quite simple with the usage of the Wrapper pattern.
CQS stands for the command query separation. There’s a chance that you may have not heard about it, but on the other hand the CQRS might ring a bell. Even though these 2 patterns have very much in common, there is a significant difference (definitely a bigger one than the additional “R” character within the CQRS acronym) in how do they apply to the architecture of our system. In this post I’ll focus on the CQS – the older brother of the CQRS – that will help you understand how to design the software that is less error prone.
In one of my previous posts (which you can read here), I’ve told about my feelings for the repository pattern. Complaining about something is one thing (please, don’t even try to tell me, that you have never seen some piece of code, that made you cry like a baby), however, if we want to (pretend to) be professionalists, it is very important to come up with some ideas in order to solve the given problem (at least partially). In this post, I’ll present to you one of my solutions to the commonly misused repository pattern (especially on the querying side).
Many of the programmers fall into the trap of creating too many unnecessary abstractions in code, that may introduce even more chaos and maintenance issues, instead of simplifying overall project structure and providing some real benefit. One of such abstractions, that have been discussed countless number of times, is the (one and only) repository pattern. I’m going to mostly whine about this abstraction (I have to point out some common mistakes) which of course can be useful in some cases. In order to keep things clear (and stop making that wall of text even bigger wall), in the next post, I’ll provide code examples of the extension methods that you can use, to have your data access logic aggregated in a single place and separated from the other infrastructural code. Bare in mind that the extension methods are not the only solution (also query handlers may come in handy, which I’d like to discuss in the future as well).