Assessment Answers

The answers to the practice questions for each chapter are as follows:

Chapter 1

1. No. However, sending a body with a GET request is not forbidden by the HTTP specifications, but such a request semantic is not defined either. It is preferable to avoid sending GET requests with a body.
2. Long methods are indicators that a method handles too many responsibilities and should be split into multiple methods or have some of the responsibilities extracted to other classes.
3. No. Target .NET Standard 2.0 when you want to support most runtime versions, like .NET Framework and .NET 6+. Target .NET Standard 2.1 to share code between Mono and Xamarin. Otherwise, target .NET 6+ directly.
4. A code smell represents a potential design flaw that could benefit from being rewritten.

Chapter 2

1. Yes, it is true.
2. To test a unit of code, such as the logical code path of a method.
3. As small as possible. A unit test aims at testing the smallest possible unit of functionality in isolation.
4. Integration tests are usually used for that kind of task.
5. No, there are multiple ways of writing code, TDD being only one of them.

Chapter 3

1. Five: S.O.L.I.D. (SRP, OCP, LSP, ISP, and DIP).
2. No, the idea is the opposite: create smaller components that interact with each other in a loosely coupled manner.
3. No, you want to encapsulate similar logic, not similar-looking blocks of code.
4. Yes, it is easier to reuse smaller pieces than adapt enormous ones.
5. It is the SRP, but the separation of concerns principle states that too.

Chapter 4

1. The controller manipulates the model and chooses what view to render.
2. The @model directive.
3. A view model should have a one-to-one relationship with a view.
4. Yes.
5. Yes.

Chapter 5

1. 201 CREATED.
2. The [FromBody] attribute.
3. The GET method.
4. Yes, those are precisely the objectives of a DTO: loosely coupling the ins and outs from the model.
5. Yes.

Chapter 6

1. It helps manage behaviors at runtime, such as changing an algorithm in the middle of a running program.
2. The creational patterns are responsible for creating objects.
3. v1 and v2 are two different instances. The code next to the arrow operator is executed every time you call the property’s getter.
4. Yes, it is true. That’s the primary goal of the pattern, as we demonstrated in the MiddleEndVehicleFactory code sample.
5. The Singleton pattern violates the SOLID principles and encourages the use of global (static) variables when it can be avoided.

Chapter 7

1. Transient, Scoped, Singleton.
2. The composition root holds the code that describes how to compose the program’s object graph—the types bindings.
3. Yes, it is true. Volatile dependencies should be injected instead of instantiated.
4. The Strategy pattern.
5. The Service Locator pattern is all three. It is a design pattern used by DI libraries, internally, but becomes a code smell in application code. If misused, it is an anti-pattern that has the same drawbacks as using the new keyword directly.

Chapter 8

1. Singleton.
2. Scoped.
3. Transient.
4. Yes, you can configure as many providers as you want. One could be for the console, and another could be used to append entries to a file.
5. No, you should not log trace-level entries in production. You should only log debug-level entries when debugging an issue.

Chapter 9

1. Yes, we can decorate decorators by depending only on interfaces because they are just another implementation of the interface, nothing more.
2. The Composite pattern adds simplicity when it comes to managing complexity.
3. Yes, we could use an adapter for this.
4. We usually use façades to simplify the use of one or more subsystems, creating a wall in front of them.
5. The Adapter and Façade design patterns are almost the same but are applied to different scenarios. The Adapter pattern adapts an API to another API, while the Façade pattern exposes a unified or simplified API, hiding one or more complex subsystems.

Chapter 10

1. False; you can create as many abstract (required) or virtual (optional) extension points as you need, as long as the class stays cohesive and does not break architectural principles. For example, ensure the class has a single responsibility.
2. Yes, there is no reason not to.
3. No, there is no greater limit than with any other code.
4. Yes, you can have one handler per message or multiple handlers per message. It is up to you and your requirements.
5. It helps divide responsibilities between classes by encapsulating the shared logic into one or more base classes.

Chapter 11

1. Yes. Actually, the HttpResponseMessage instance returned by the HttpMessageInvoker.Send method is an operation result. HttpClient inherits from HttpMessageInvoker and exposes other methods that also return an instance of HttpResponseMessage.
2. We implemented two static factory methods.
3. Yes, returning an object is faster than throwing an exception leading to a marginal performance gain which is a situational optimization technique. In most cases, you should not solely use the Operation Result pattern for that speed gain.

Chapter 12

1. No, you can have as many layers as you need, and you can name and organize them as you want.
2. No, both have their place, their pros, and their cons.
3. Yes. A DbContext is an implementation of the Unit of Work pattern. DbSet<T> is an implementation of the Repository pattern.
4. No, you can query any system, any way you want. For example, you could use ADO.NET to query a relational database, manually create the objects using a DataReader, track changes using a DataSet, or do anything else that fits your needs. Nonetheless, ORMs can be very convenient.
5. Yes. A layer can never access outward layers, only inward ones.

Chapter 13

1. Yes, it can, but not necessarily. Moving dependencies around does not fix design flaws; it just moves those flaws elsewhere.
2. Yes, mappers should help us follow the SRP.
3. No, it may not be suitable for every scenario. For example, when the mapping logic becomes complex, think about not using AutoMapper.
4. Yes, use profiles to organize your mapping rules cohesively.
5. Four or more. Once again, this is just a guideline; injecting four services into a class could be acceptable.

Chapter 14

1. Yes, you can. That’s the goal of the Mediator pattern: to mediate communication between colleagues.
2. In the original sense of CQRS: no, a command can’t return a value. The idea is that a query reads data while commands mutate data. In a looser sense of CQRS, yes, a command could return a value. For example, nothing stops a create command from returning the created entity partially or totally. You can always trade a bit of modularity for a bit of performance.
3. MediatR is a free, open source project licensed under Apache License 2.0.
4. Yes, you should; using Marker Interfaces to add metadata is generally wrong. Nevertheless, you should analyze each use case individually, considering the pros and cons before jumping to a conclusion.

Chapter 15

1. Any pattern and technique that you know that can help you implement your solution. That’s the beauty of it: you are not limited; only by yourself.
2. No, you can pick the best tool for the job inside each vertical slice; you don’t even need layers.
3. The application will most likely become a Big Ball of Mud and be very hard to maintain, which is not good for your stress level, the product quality, time to market of changes, and so on.
4. We can create MVC filters in any ASP.NET Core MVC application. We can augment the MediatR pipeline using behavior in any application that uses MediatR. We can also implement ASP.NET Core middlewares in non-MVC applications or to execute code before getting into the MVC pipeline.
5. Cohesion means elements that should work together as a united whole.
6. Tight coupling describes elements that cannot change independently; that directly depend on one another.

Chapter 16

1. The message queue gets a message and has a single subscriber dequeue it. If nothing dequeues a message, it stays in the queue indefinitely (FIFO model). The Pub-Sub model gets a message and sends it to zero or more subscribers.
2. Event sourcing is the process of chronologically accumulating events that happened in a system instead of persisting the current state of an entity. It allows you to recreate the state of the application by replaying those events.
3. Yes, you can mix Gateway patterns (or sub-patterns).
4. No, you can deploy micro-applications (microservices) on-premises if you want to. Moreover, in Chapter 14, Mediator and CQRS Design Patterns, we saw that we can use CQRS even inside a single application.

Chapter 17

1. Razor Pages is best at creating web page-oriented applications.
2. Yes, we have access to mostly the same things as with MVC.
3. Technically, yes, you could, but you should use partial views only to render part of the UI and presentation logic, not domain logic and database queries.
4. Yes, you can. You can also create new tags.
5. Yes, you can. View components are like component-based, single-action controllers rendering one or more views.
6. A class can have as many display templates as there are levels in the views/pages hierarchy.
7. Display and editor templates are directly related to a type.

Chapter 18

1. No, it is compiled to WebAssembly (AOT compilation) or leverages the .NET Wasm runtime (JIT compilation) and runs the .NET binaries in the browser.
2. None. All three are acceptable options—it depends on what you are building and with whom.
3. Model (State), View (Component), Update (Reducer).
4. No. The MVU pattern is all about a unidirectional flow of data to simplify state management.
5. Yes. Blazor can interact with JavaScript and vice versa.

Join our book’s Discord space

Join the book’s Discord workspace for Ask me Anything session with the authors:

https://packt.link/ASPdotNET6DesignPatterns