Error handling in ASP.NET - Part 2 💪 In Part 1, I demonstrated how we can use the "UseExceptionHandler" method to add a middleware that will catch uncaught exceptions, reset the request path and re-execute it. This allowed us to specify a controller method that will handle this error flow. One of the big advantages of this solution is being able to use the base controller's methods. In the example from part 1, we used the "Problem(..)" method which creates the Problem Details response. Usually, we would like to customize the Problem Details response, adding some debugging data or other custom properties. By default, the DefaultProblemDetailsFactory (source code: https://lnkd.in/dJd7Y4uE) is used to create the Problem Details. In this part, we will show how we can create our custom ProblemDetailsFactory which will be used by all controllers to build the Problem Details response. Other than the "AddCustomProperties" method in the factory, the code is almost exactly the same as the original code from the DefaultProblemDetailsFactory. Have any of you implemented your own problem details factory? A sample project containing the minimum code needed for the example below is available on my GitHub: https://lnkd.in/dSP4ffYV Error handling in ASP.NET: Part 1: https://lnkd.in/dcaYG75m Part 3: https://www.linkedin.com/posts/amichaim_aspnetcore-aspnet-dotnetcore-activity-6865617913924087808-QmYI #aspnetcore #aspnet #dotnetcore #netcore #netcore5 #csharp9
Amichai Mantinband’s Post
More Relevant Posts
-
Designing REST APIs properly is crucial, since once you go public, you'll have to support that design for quite a while. Just released a video which covers almost everything you need to take into account when designing your REST APIs. Check it out! https://lnkd.in/daxezfph
REST API Design Best Practices
https://www.youtube.com/
-
Are you familiar with the “Richardson Maturity Model” for defining the maturity of a REST API? Just released a 150 second video covering what you need to know!
The 3 REST API Maturity Levels
https://www.youtube.com/
-
Roy Fielding, the one who defined REST, is frustrated with “so-called” REST APIs. Why? And what is actually considered a REST API? Just released a video covering exactly this, check this out!
Stop Calling Your API a "REST API"
https://www.youtube.com/
-
Just dropped the first video in a series of videos in which we'll build a REST API completely from scratch using ASP.NET 8! Throughout the series, we'll build a robust and resilient REST API that you could confidently run in production. Some of the features we'll implement include rate limiting, caching, health checks, logging, telemetry, Dockerization and much much more. Check it out! https://lnkd.in/dE4SbqaW
ASP.NET 8 REST API Tutorial - The "Sweet Spot" Architecture
https://www.youtube.com/
-
Aggregate design, especially a clear design across bounded contexts, is perhaps the only key process in Domain-Driven Design that lacks a clear step-by-step structure. After designing multiple systems, I came up with the following formula that has worked well a for me. I call it "Aggregate Storming" (for now). Here are the steps: 1. Identify entities. 2. Map relationships between entities. 3. Mark all entities as aggregates. 4. Merge aggregates. Prerequisites: 1. Identifying and classifying sub-domains. 2. Define (preliminary) bounded contexts. 3. Context mapping for key processes. 4. (high-level) Invariants draft. 1. Identify entities: Throughout the strategic and tactical phases we refine the domain models. By the time we reach aggregate design, we already have a preliminary set of entities in each bounded context. 2. Map relationships between entities: Each entity may have relationships with 0 or more other entities. These are not database relationships and this has nothing to do with the database. This is what domain "concepts" have to do, or need to know about other domain "concepts". 3. Mark all entities as aggregates: When it comes to aggregate design - the smaller the better. Which is why ideally, if there is no other constraint, each entity is an aggregate and the aggregate root. This is the stage in which we look at each group of of entity-to-related entities as an aggregate. Which also means related (now) aggregates are converted to a reference by id. 4. Merge aggregates: Practically, we can't have each entity be an aggregate. The main constraint is that we need to be able to enforce invariants. This is when we review all the invariants and see if an invariant requires us to merge aggregates. We can often just propagate some details from one aggregate to another in an eventual consistent manner. Sometimes, however, eventual consistency cannot be tolerated and this would also force us to merge aggregates. This becomes increasingly interesting when suddenly we need information from one bounded context in another bounded context. I cover this process in depth in my "Deep Dive: Domain-Driven Design" course I just launched on dometrain. Screenshot below is from 5 and a half hours in, where we do aggregate design in action for a complex domain. We look at the several choices we can make in each fork in the road and how it affects the overall design. If you like DDD, I think you'll enjoy the course! This is the link to the course (use promo code AMICHAI20 for 20% off): https://lnkd.in/dzGCWK-i
-
-
It's out! A 6 hour deep dive into designing Aggregates, identifying Sub-Domains, establishing Bounded Contexts, defining Ubiquitous Language and Invariants, Event Storming workshops, Context Mapping and more. Really stoked about this one. Can't wait for you to watch it. https://lnkd.in/dzGCWK-i (promo code AMICHAI20)
-
-
Fascinating video by Nick
Big thanks to Dave Callan for the inspiration on this video! This video highlights some collection initializer performance differences: https://lnkd.in/ecr3gZvt As with all of my benchmark videos, my goal isn't to convince you to use different code... it's to get you thinking about profiling and benchmarking things for yourself 🙂
UNEXPECTED 87% Performance Boost! - C# Collection Initializers
https://www.youtube.com/
