在MAUI微软的官方方案是使用Blazor开发，但是当前市场大多数的Web项目使用Vue，React等技术构建，如果我们没法绕过已经积累的技术，用Blazor重写整个项目并不现实。Vue是当前流行的web框架， 简单来说是一套模板引擎，利用“模板”和“绑定”两大特性实现web页面mvvm模式开发。利用.NET MAUI框架可以将Vue应用嵌入到Web容器中。可以实现跨平台的混合开发。例如我在某医疗行业项目中，已经用这个混合开发的方式生成应用，Vue代码不需要做什么改动，就能跨平台运行：如果你

混合开发的概念是相对与原生开发来说的：App不直接运行原生程序，而是在原生程序中运行一个Web程序，原生程序中包含Web运行时，用于承载Web页面。暂且将原生应用称之为Web容器，Web容器应该能让JavaScript代码与原生平台的代码交互，互相调用，同时为上层提供交互逻辑，例如导航，事件，Cookie，刷新等内容。之前使用Xamarin可以利用WebView控件做混合开发，但是到目前为止WebView功能还是比较孱弱。用WebView实现混合开发主要是通过重写各个平台的自定义呈现器（Renderer

为什么要独立成服务？以一个健康医疗系统为例， 这个系统包含了用户模块，问卷的发放与填写，图表显示，报表生成与查看，患者管理等功能，传统的架构如下：随着项目规模的增长，在开发过程中会发现如下问题：各模块之间耦合严重，比如：报表模块引用了问卷，用户，随访，患者管理等几乎所有模块，难以维护 间接引用的情况过多，导致项目分层不明确，容易产生引用分歧，难以维护目前做的就是解耦各个模块之间的强关联状态，通过上一章提到的上下文边界划分方式，我们大致可以将系统的架构改造如下：通过调用者和实现者共

上一章我们完成了小项目的面向服务体系改造，你或许一直在思考一个问题。为什么要将业务独立成微服务？以一个健康医疗系统为例， 这个系统包含了用户模块，问卷的发放与填写，图表显示，报表生成与查看，患者管理等功能，传统的架构如下：随着项目规模的增长，在开发过程中会发现如下问题：各模块之间耦合严重，比如：报表模块引用了问卷，用户，随访，患者管理等几乎所有模块，难以维护 间接引用的情况过多，导致项目分层不明确，容易产生引用分歧，难以维护目前做的就是解耦各个模块之间的强关联状态，通过第一章提到的上下文

上一章我们建立了一个典型的面向领域设计的Abp小项目，如果按照常规的开发方式，会遇到什么问题呢？先来完善一下这个小项目，在定义好各实体类后，运行Miguration并向数据库里写入一些初始数据。现在整个项目的依赖引用图如下，每一个都有独立的引用路线，互不干涉。简略图如下假设现在有一个需求，MainService业务需要用到Service1和Service2 中的数据，如何操作？在使用Abp框架时，传统开发方式是先建立领域层服务，应用层中调用领域层服务（Manager）并返回给UI

在企业中大型项目中，随着业务的不断拓展，项目发展到一定程度，需要寻求项目的各模块解耦，独立成为微服务。如何实现呢？首先我们先来简单回顾一下Abp框架怎样实现（DDD）领域驱动设计的，Abp框架的全称是:Asp.Net Boilerplate Project（即Asp.Net 的样板项目），我们知道在领域驱动设计中，我们可以将整个系统分为四个大的层次,每一个层次都有其特定的功能，所以整个项目整体结构是非常清楚的。Eric Evans在《领域驱动设计－软件核心复杂性应对之道》这本书中提出了传统的四层架构

-> 问题：在使用Update-Database时，突然出现“数据库中已存在名为 'XXX' 的对象”。检查发现__EFMigrationsHistory表中的MigrationId与项目中的EntityFrameworkCore项目中的Migrations内容有不同的地方。ABP的更新机制是对比数据库的id与Migrations各文件Id，如果数据库缺少则往下继续执行，但如果有id冲突，则会认为产生分支，从第一个开始执行了。结果造成读到的全部是CREATE TABLE 的操作，从而产生冲突。解决

在工程根目录下新建一个打包脚本 pyinstall-singlefile.py 在工程根目录下创建icon图标，mainIcon.ico打开pyinstall-singlefile.py

闲来无事开发了个日期选择控件，感兴趣的同学前往：https://github.com/MatoApps/Mato.DatePickerMato.DatePicker说明这是一个带有农历日历的日期选择Xamarin控件 可以指定初始日期 多选和单选日期