前言

在项目中我们会经常遇到对象的映射，比如像Model和Dto之间的映射，或者是对象的深拷贝，这些都是需要我们自己实现的。此时，项目中会出现很多初始化对象的代码，这些代码写起来相当的枯燥乏味，那么有没有什么办法减轻我们的工作量，使得我们可以把时间花费到业务功能上呢？

目前，.Net中的对象映射框架，功能强大且性能极佳的对象映射框架已经存在，其中使用最多的有:

• Mapster
• AutoMapper

前言

上一篇我们讲了使用HttpClient的方式调用，那么如果我们现在需要更换为通过dapr实现服务调用，我们需要做哪些事情呢？

前言

绝大多数项目都离不开服务调用，服务的调用方式通常是基于Http、RPC协议的调用，需要获取到对应服务的域名或者ip地址以及详细的控制器方法后才能进行调用，如果项目需要支持分布式部署，则需要借助服务发现或者Nginx才能实现。

但随着Dapr的崛起，服务的调用方式也发生了变化，它不仅仅提供了处理重试和瞬态错误等功能，还内置服务发现，启用dapr的服务仅需知道任意一个启用dapr服务的HttpPort端口、gRpc端口、以及对应服务的appid以及对应的方法名称就可以完成调用，dapr的出现使得服务间调用变得更为的简单、方便

目前我们有一个项目是Dapr的，但它所依赖的另外一个项目是基于Http协议的调用，目前只能使用HttpClient或RestSharp实现服务间的调用，但未来有一天它会使用Dapr，因为我们计划会把所有的项目都逐步升级到Dapr上

介绍

Dapr简化了云原生开发，让开发可以把焦点放在应用的业务逻辑上，从而让代码简单、可移植，那作为一个.Net开发者，我们也希望项目可以快速用上dapr，那究竟应该如何做呢？

Dapr提出了Sidecar(边车)的概念，在启动项目时再额外启动一个Sidecar, 通过Sidecar可以解决进程间通信，为此官方提供了两种部署方式：

1. 自托管方式下运行Dapr
2. 在 Kubernetes 模式中部署和运行 Dapr

其中Kubernetes模式部署是通过Kubernetes来完成的，在开发中我们更多的是通过自托管模式使用Dapr，那自托管模式是怎么做的呢？

使用命令行工具，在项目根目录输入：

1

dapr run --app-id assignment-server --app-port 5038 dotnet run

详细文档参考：手把手教你学Dapr - 3. 使用Dapr运行第一个.Net程序

参考以上详细文档操作后，我们就可以在命令行工具中执行dapr invoke --app-id assignment-server --method hello或者Http请求来调用对应的应用的方法

看似好像也不是很复杂，但如果你需要调试dotnet项目呢？再复杂一点的需要启动多个项目进行调试呢？端口一多起来的确会显得很麻烦。

有没有什么办法可以解决呢？有，docker-compose。

但我还不想用这么重的东西，我想像平时开发项目一样直接在windows上运行可不可以？

Clean Architecture

国内对于Clean Architecture的翻译很多，干净/整洁/清晰。但无论哪一种都说明了它简洁、清晰的特性。

DDD

领域驱动设计是一个有关软件开发的方法论，它提出基于领域开发的开发模式，基于DDD理论，我们可以设计出高质量的软件模型。

它围绕业务概念构建领域模型来控制业务的复杂度，解决软件难以理解和演化的问题。

概述

利用发布订阅模式来解耦不同架构层级，亦可用于解决隔离业务之间的交互

优点：

• 松耦合
• 横切关注点
• 可测试性
• 事件驱动

源起

年初我们在找一款框架，希望它有如下几个特点：

1. 学习成本低

   只需要学.Net 每年主推的技术栈和业务特性必须支持的中间件，给开发同学减负，只需要专注业务就好

   个人见解：一款好用的框架应该是补充，而不是颠覆或过度创新

2. 对扩展开放

   可以按照业务需求任意调整依赖实现，而不被捆绑在一个架构思路上

3. 功能强大却不限制架构，从单体到 SOA 再到微服务都可以适应

   因为一个系统中总有复杂的也有简单的，最好能全面覆盖我们的业务场景

4. 行业不限

   既能支持传统行业的业务特殊性，又可以支持互联网行业的高并发特性

5. 稳定性

   有严格的测试标准，用起来更安心