十九、答案
各章练习问题的答案如下：
第一章
- 不
- 长方法是指一种方法处理了太多的责任，应该进行拆分。
- 对通过以.NET 标准为目标，您可以达到多个运行时版本，包括.NET Core 和.NET 框架。
- 代码气味代表一个潜在的设计缺陷，可以从重写中获益。
第二章
- 是的，这是真的。
- 测试代码单元，如方法的逻辑代码路径。
- 3.尽可能小。单元测试旨在孤立地测试尽可能最小的代码单元。
- 集成测试通常用于此类任务。
- 不，有多种编写代码的方法，TDD 只是其中之一。
第三章
- 五点：S.O.L.I.D。（SRP、OCP、LSP、ISP 和 DIP）。
- 不，想法正好相反：创建更小的组件。
- 不，您希望封装相似的逻辑，而不是外观相似的代码块。
- 是的，重用较小的组件比适应较大的组件更容易。
- 这是 SRP，但关注点分离原则也指出了这一点。
第四章
- 控制器操纵模型并选择视图进行渲染。
@model指令。- 视图模型应该与视图有一对一的关系。
- 对
- 对
第五章
- 201 已创建。
- 2.
[FromBody]属性。 GET方法。- 是的，这些正是 DTO 的目标：将ins和OUT与模型解耦。
- 对
第六章
- 它有助于管理运行时的行为，例如在程序中间更改算法。
- 创建模式负责创建对象。
v1和v2是两个不同的实例。每次调用属性的 getter 时，都会执行 arrow 操作符旁边的代码。- 是的，这是真的。这是该模式的主要目标，正如我们在
MiddleEndVehicleFactor代码示例中演示的那样。 - 单例模式违反了坚实的原则，鼓励使用全局（静态）变量。
第七章
- 瞬态、作用域、单态。
- 组合根目录包含描述如何组合程序的代码——抽象和实现之间的所有注册和绑定。
- 是的，这是真的。应注入易失性依赖项，而不是实例化。
- 战略模式。
- 服务定位器模式是所有三种模式。它是 DI 库在内部使用的一种设计模式，但在应用代码中成为一种代码气味。如果被误用，这是一种反模式，与直接使用
new关键字具有相同的缺点。
第八章
- 辛格尔顿。
- 范围。
- 转瞬即逝的
- 是的，您可以根据需要配置任意多个提供程序。一个用于控制台，另一个用于将条目附加到文件。
- 不，您不应该在生产中记录跟踪级别的条目。调试问题时，应该只记录调试级别的条目。
第九章
- 是的，我们可以通过仅依赖接口来装饰装饰器，因为它们只是接口的另一个实现，仅此而已。
- 当涉及到管理复杂性时，复合模式增加了简单性。
- 是的，我们可以用一个适配器。
- 我们通常使用立面来简化一个或多个子系统的使用，在它们前面创建一堵墙。
- Adapter 和 Façade 设计模式几乎相同，但适用于不同的场景。适配器模式将一个 API 适配到另一个 API，而 Façade 模式公开了一个统一或简化的 API，隐藏了一个或多个复杂的子系统。
第十章
- 错误的您可以创建任意数量的
abstract（必需）或virtual（可选）扩展点，只要类与单个职责相衔接。 - 是的，没有理由不这样做。
- 不，没有比任何其他代码更大的限制。
- 是的，每个消息可以有一个处理程序，或者每个消息可以有多个处理程序。这取决于您和您的要求。
- 它有助于在班级之间划分职责。
第 11 章
- 对实际上，
HttpMessageInvoker.Send 方法返回的HttpResponseMessage实例就是一个操作结果。HttpClient继承自HttpMessageInvoker并公开了其他不同的方法，这些方法也返回HttpResponseMessage的实例。 - 我们实现了两种静态工厂方法。
- 是的，返回对象比抛出异常更快。
第 12 章
- 不，您可以根据需要拥有任意多的层，并且可以根据需要命名和组织它们。
- 不，两者都有各自的位置、优点和缺点。
- 对
DbContext是工作单元模式的实现。DbSet<T>是存储库模式的一个实现。 - 不，您可以按任何方式查询任何系统。例如，您可以使用 ADO.NET 查询关系数据库，使用
DataReader手动创建对象，使用DataSet跟踪更改，或者执行任何符合您需要的操作。尽管如此，ORMs 还是非常方便。 - 对层永远不能访问外部层，只能访问内部层。
第 13 章
- 是的，可以，但不一定。移动依赖项并不能修复设计缺陷；它只是将这些缺陷转移到其他地方。
- 是的，制图员应该帮助我们遵循 SRP。
- 不，它可能不适用于所有场景。例如，当映射逻辑变得复杂时，请考虑不使用 AutoMapper。
- 是的，使用概要文件来连贯地组织映射规则。
- 四个或更多。再一次，这只是一个指导方针；在一个类中注入四个服务是可以接受的。
第 14 章
- 是的，你可以。这就是调解模式的目标：调解同事之间的沟通。
- 在 CQRS 的原始意义上：不，命令不能返回值。其思想是，查询读取数据，而命令改变数据。在 CQR 更宽松的意义上，是的，一个命令可以返回一个值。例如，没有任何东西可以阻止 create 命令部分或全部返回所创建的实体。您总是可以用一点模块化来换取一点性能。
- MediatR 是一个根据 Apache 许可证 2.0 授权的免费开源项目。
- 是的，你应该；使用标记接口添加元数据通常是错误的。然而，您应该单独分析每个用例，在得出结论之前考虑利弊。
第 15 章
- 您知道的任何可以帮助您实现解决方案的模式和技术。这就是它的美：你不受限制；只有你自己。
- 不，您可以在每个垂直切片内为作业选择最佳工具；你甚至不需要图层。
- 应用很可能会变成一个大泥球，很难维护，这对你的压力水平不好。
- 我们可以在任何 ASP.NET MVC 应用中创建 MVC 过滤器。我们可以在任何使用 MediatR 的应用中使用行为来扩充 MediatR 管道。我们还可以在非 MVC 应用中实现 ASP.NET 中间件，或者在进入 MVC 管道之前执行代码。
- 内聚性是指应作为一个统一的整体共同工作的要素。
- 紧密耦合描述了不能独立改变的元素；这直接依赖于彼此。
第 16 章
- 消息队列获取一条消息，并有一个订阅者将其出列。如果没有任何东西使消息出列，它将无限期地留在队列中（FIFO 模型）。发布子模型获取消息并将其发送给零个或多个订阅者。
- 事件源是按时间顺序累积系统中发生的事件的过程。它允许您通过重播这些事件来重新创建应用的状态。
- 是的，您可以混合网关模式（或子模式）。
- 不，如果愿意，您可以在本地部署微应用（微服务）。此外，在第 14 章，Mediator 和 CQRS 设计模式中，我们发现我们甚至可以在单个应用中使用 CQRS。
- 不，如果愿意，可以不使用容器部署微服务。在任何情况下，容器都很可能为您省去许多麻烦（并创建新的麻烦）。
第 17 章
- Razor Pages 最擅长创建面向 web 页面的应用。
- 是的，我们可以访问与 MVC 基本相同的内容。
- 从技术上讲，是的，您可以，但您应该只使用局部视图来呈现部分 UI 和 UI 逻辑，而不是域逻辑和数据库查询。
- 是的，你可以。您还可以创建新标记。
- 是的，你可以。视图组件类似于渲染一个或多个视图的基于组件的单动作控制器。
- 是的，它可以编译。它使用 C#9 中引入的目标类型
new表达式。 - 不，没有。如果我们将
class关键字替换为record关键字，它将编译，如下所示：public record MyDTO(int Id, string Name);. - 一个类可以有与视图/页面层次结构中的级别一样多的显示模板。
- 显示模板和编辑器模板与类型直接相关。
第 18 章
- 否，它被编译为 WebAssembly。
- 没有一个这三个选项都是可以接受的，这取决于你在建什么，和谁一起建。
- 模型（状态）–视图（组件）–更新（减速器）。
- 不，MVU 模式是关于一个单向的数据流，以简化状态管理。
- 对 Blazor 可以与 JavaScript 交互，反之亦然。
版权属于：月萌API www.moonapi.com，转载请注明出处
