Assessment Answers

The answers to the practice questions for each chapter:

Chapter 1

1. No.
2. Long methods are indicators that a method handles too many responsibilities and should be split.
3. Yes; by targeting .NET Standard, you can reach multiple runtime versions, including .NET Core and .NET Framework.
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. 3. As small as possible. A unit test aims at testing the smallest possible unit of code 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.
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 concern 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. 2. The [FromBody] attribute.
3. The GET method.
4. Yes, those are precisely the objectives of a DTO: decoupling 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 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 getter of the property.
4. Yes, it is true. That's the primary goal of the pattern, as we demonstrated in the MiddleEndVehicleFactor code sample.
5. The Singleton pattern violates the SOLID principles and encourages the use of global (static) variables.

Chapter 7

1. Transient, Scoped, Singleton.
2. The composition root holds the code that describes how to compose the program–all the registrations and bindings between abstractions and implementations.
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 brings 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 a problem.

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 long as the class is cohesive with 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.

Chapter 11

1. Yes. Actually, the HttpResponseMessage instance that is returned by the HttpMessageInvoker.Send method is an operation result. HttpClient inherits from HttpMessageInvoker and exposes other different 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.

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, taking the pros and cons into consideration 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.
4. We can create MVC filters in any ASP.NET MVC application. We can augment the MediatR pipeline using behavior in any application that uses MediatR. We can also implement ASP.NET 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. 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 could use CQRS even inside a single application.
5. No, you can deploy microservices without containers if you want to. In any case, containers will most likely save you many headaches (and create new ones).

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 UI 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. Yes, it compiles. It uses the target-typed new expressions, introduced in C# 9.
7. No, it does not. If we replace the class keyword by the record keyword it will compile, like this: public record MyDTO(int Id, string Name);.
8. A class can have as many display templates as there are levels in the views/pages hierarchy.
9. Display and editor templates are directly related to a type.

Chapter 18

1. No, it is compiled to WebAssembly.
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.