Before you begin: Join our book community on Discord
Give your feedback straight to the author himself and chat to other early readers on our Discord server (find the “architecting-aspnet-core-apps-3e” channel under EARLY ACCESS SUBSCRIPTION).
https://packt.link/EarlyAccess
This chapter explores the Operation Result pattern, starting simple and progressing to more complex cases. An operation result aims to communicate the success or failure of an operation to its caller. It also allows that operation to return both a value and one or more messages to the caller.Imagine any system where you want to display user-friendly error messages, achieve some small speed gain, or even handle failure easily and explicitly. The Operation Result design pattern can help you achieve these goals. One way to use it is to handle the result of a remote operation, such as after querying a remote web service.This pattern builds upon foundational object-oriented programming concepts. In this chapter, we iterate and design different possibilities incrementally. Of course, you should always base your final design on your needs, so learning multiple options will help you make the right choices.
The Operation Result pattern is also known as the Result Object Pattern. I prefer Operation Result because the name specifies that it represents the result of an operation, while the Result Object has a broader meaning. Nonetheless, both are basically the same.
In this chapter, we cover the following topics:
- The Operation Result design pattern basics
- The Operation Result design pattern returning a value
- The Operation Result design pattern returning error messages
- The Operation Result design pattern returning messages with severity levels
- Using sub-classes and static factory methods for better isolation of successes and failures
The Operation Result pattern
The Operation Result design pattern can be very simple to more complex. In this section, we explore multiple ways to use this pattern. We start with its simplest form and build on that until we can return messages and values and add severity levels as the result of an operation.
Goal
The role of the Operation Result pattern is to give an operation (a method) the possibility to return a complex result (an object), which allows the consumer to:
- [Mandatory] Access the success indicator of the operation (that is, whether the operation succeeded or not).
- [Optional] Access the operation result if there is one (the method’s return value).
- [Optional] Access the cause of the failure if the operation was unsuccessful (error messages).
- [Optional] Access other information that documents the operation’s result. This could be as simple as a list of messages or as complex as multiple properties.
This can go even further, such as returning the severity of a failure or adding any other relevant information for the specific use case. The success indicator could be binary (true or false), or there could be more than two states, such as success, partial success, and failure.
Always focus on your needs first, then use your imagination and knowledge to find the best solution. Software engineering is not only about applying techniques that others tell you to. It’s an art! The difference is that you are crafting software instead of painting or woodworking. And that most people won’t see any of that art (code) or get it even if they do.
