When implementing a web application, it can be a good idea to enforce some kind of auditing to all of your client interactions, either to track their behavior over time, to ensure any security breach will be properly logged, or just to help analyze system bugs.
Previously we talked about using the mediator pattern to implement the Command Query Responsibility Segregation (CQRS) and Event Sourcing (ES) and how pipelines could be used to implement transversal behavior to your application.
Since commands are responsible to mutate the system state, in this article I’m going to demonstrate how you could implement an audit pipeline to ensure all commands will be stored into a table. Because a variable number of events can be broadcasted when the state changes, the pipeline will also store them into another table and with a reference to the command, ensuring any correlation can be analyzed. …
When implementing a simplified CQRS service, which usually has a single database but still separates commands from queries, the mediator pipeline can be used to manage transactions when processing commands, ensuring changes will be implicitly committed unless an exception is thrown.
Implementing a pipeline for transactions has some key advantages even when using Entity Framework Core or other ORM that tracks and flushes changes at a single point in time.
Because the command handler is executing inside an implicit transaction, the developer is free to flush their changes as it sees fit knowing that any exception will rollback the changes. This is very helpful when it wants to cancel the flow when some business rules aren’t meet and could only be checked after changing the system state. Optimistic concurrency is a good example where you may want to flush your changes before leaving the handler so you know exactly what entity failed and can send a more detailed message to the user, which is the usual approach when implementing a dedicated Backend for Frontend service. …
When implementing web applications that manipulate information, there is always the need to validate data sent by the clients, ensuring business rules are properly implemented.
Previously I talked about the implementation of Command Query Responsibility Segregation (CQRS) and Event Sourcing (ES) using a mediator pattern and how to support transversal behavior via pipelines.
In this article I’m going to demonstrate how validation can be enforced into your commands and events before reaching the handlers, making sure that invalid data will be rejected by the API.
This approach not only reduces the amount of duplicated code, it also ensures validations won’t be forgotten, unless explicitly stated. …
In my previous article I explained how you could implement Command Query Responsibility Segregation (CQRS) and Event Sourcing (ES) patterns using a mediator instance from SimpleSoft.Mediator in ASP.NET Core applications.
This time I’m going to explain how to intercept commands, queries and events, making it possible to apply transversal behavior before they reach the handlers, reducing significantly the amount of boilerplate and duplicated code.
Transaction management, logging, auditing, caching or validations are some of the good examples where pipelines can be very helpful. Imagine the following chains:
For the last few years, Command Query Responsibility Segregation (CQRS) and Event Sourcing (ES) emerged as patterns that can help implement large scale systems, with some risky complexity, by having different models to read or mutate data while also using events as a single source of truth.
Since there are already great articles explaining CQRS or ES in great depth, I’m going to focus and show how you can decouple your application layers by only knowing POCOs and a mediator instance from SimpleSoft.Mediator.
Remember that, even if you are not using CQRS or ES to its full extend, just by ensuring a logical model segregation inside the project can make your life easier in the long run, even when implementing a simple Backend for Frontend (BFF) or a minimum viable product (MVP). …
Life as a .NET developer never looked brighter and more exciting. This last few years have been amazing: .NET Standard, ASP.NET Core, oficial Linux and Mac support, open source everywhere, what more can we ask? Well, one thing that always seems to be forgotten are console application, despite their important role.
In this article I’ll explain how can someone create more complex or fasten the development of console applications by using a small library named SimpleSoft.Hosting.
Ever since I entered the .NET world, my main focus was on all sorts of web applications, but over time I also found console applications to be an important part of my job, specially in automating stuff. From basic installers (copy some files, change some registries, stop some services), cleanup jobs (compress or delete log files), to Windows Services using wrappers like NSSM that can be useful for self-hosting Web APIs or update managers, console applications are an important part of my developer life. …
Nowadays, when someone talks about web development in the .NET world, it is almost certain to be talking about ASP.NET MVC, ASP.NET Web API or, the more recently released, ASP.NET Core MVC. These are frameworks developed by Microsoft to help the development of server side logic for web applications.
In this article I’ll explain how can someone simplify the global handling of exceptions based on their type or properties by using a small library named Simple Exception Handling in ASP.NET Core MVC applications.
Exceptions, despite being rare, are an important aspect that any developer should be aware when creating applications in the .NET world. They can be handled inside try-catch-finally blocks but, most of the time, no particular handling logic need to be implemented or are completely unexpected, like the well known OutOfMemoryException, and will be managed by the global exception handler logic. …