Create React App 的演变 在 2016 年发布 Create React App 时，工具的环境是分散的。如果想要将 React 添加到现有应用，需要添加一个 script 标签或从 npm 中导入，然后调整现有的构建工具配置。但是，如果要从头开始创建一个仅使用 React 构建的新应用，则没有明确的方法可以做到这一点。 在 Create React App 之前，必须安装一堆工具并将它们连接在一起，提供正确的预设以使用 JSX，为开发和生产环境进行不同的配置，为资源缓存提供正确的设置，配置 linter 等，想要正确完成这一系列工作非常困难。人们通过创建和共享可以克隆的“样板”存储库来解决了这个问题。然而，这产生了另外一个问题：一旦在项目中调整了克隆的样板文件，就很难再拉取样板的更新。这样，项目的设置会变得旧，要么放弃更新，要么花费大量精力让所有工具再次协同工作。在快速发展的生态系统中，这非常困难。 Create React App 通过将多个工具组合在一个包中解决了这个问题。现在，如果想用 React 开始一个新项目，有一个明确的推荐方法（Create React App）可以做到这一点！ 然后，每隔一段时间，可以更新这个包，以获得所有底层工具的更新。这种模型变得很流行，以至于今天有很多工具都以这种方式工作。Vite 确实是拥有相似愿景的最佳工具之一，并且在在某些方面更进一步。 Create React App 的目标是为大多数 React 用户提供启动新 React Web 应用的最佳方式，它支持一组协同工作的精选功能。随着时间的推移，它提供的开箱即用的“baseline”会随着我们找到正确的权衡而扩大。 例如，为运行时错误添加了一个遮罩层，添加了对不同样式选项的支持，默认添加了快速刷新，它允许保存组件的代码并查看更改而不会丢失状态。对于默认的 React 开发体验来说，这是一个巨大的里程碑。总的来说，由于 Create React App 完全控制了编译管道，因此添加编译相关的功能是很容易的。 有这样一个精心策划的设置对生态系统仍然很有价值。当 React Hooks 出现时，React 团队将 React Hooks lint 规则添加到默认设置中。除此之外，Create React App 还允许 React 团队向尽可能广泛的受众部署重要的工具更改（快速刷新支持、React Hooks lint 规则）。 如果没有 React 团队策划的流行模板，将很难如此广泛地推出这些工具更改。 ...

创建方法 npx: npx 来自 npm 5.2+ 或更高版本 npx create-react-app my-app npm: npm init 在 npm 6+ 中可用 npm init react-app my-app Yarn: yarn create 在 Yarn 0.25+ 中可用 yarn create react-app my-app Scripts 在新创建的项目中，你可以运行一些内置命令： npm start 或 yarn start 在开发模式下运行应用程序, 默认在浏览器打开http://localhost:3000。如果更改代码，页面将自动重新加载。 npm test 或 yarn test 以交互模式运行测试程序。 默认情况下，运行与上次提交后更改的文件相关的测试。 npm run build 或 yarn build 将生产环境的应用程序构建到 build 目录。 它能将 React 正确地打包为生产模式中并优化构建以获得最佳性能。构建将被压缩，文件名中将包含哈希。 npm run eject 注意：这是单向操作。一旦 eject ，就回不去了！ 执行完这个命令后会将封装在 CRA 中的配置全部反编译到当前项目，这样开发者完全取得 webpack 文件的控制权，可以自定义修改webpack打包配置。 ...

在日常开发中，应用程序的性能是我们需要关注的一个重点问题。当然我们有很多工具来分析程序性能：如：Zipkin等；但这些过于复杂，需要单独搭建。 MiniProfiler就是一款简单，但功能强大的应用新能分析工具；可以帮助我们定位：SQL性能问题、响应慢等问题。 MiniProfiler是一款针对.NET, Ruby, Go and Node.js的性能分析的轻量级程序。可以对一个页面本身，及该页面通过直接引用、Ajax、Iframe形式访问的其它页面进行监控,监控内容包括数据库内容，并可以显示数据库访问的SQL（支持EF、EF CodeFirst等 ）。并且以很友好的方式展现在页面上。 MiniProfiler官网：http://miniprofiler.com/ MiniProfiler的一个特别有用的功能是它与数据库框架的集成。除了.NET原生的 DbConnection类，MiniProfiler还内置了对实体框架（Entity Framework）以及LINQ to SQL、RavenDb和MongoDB的支持。任何执行的Step都会包括当时查询的次数和所花费的时间。为了检测常见的错误，如N+1反模式，profiler将检测仅有参数值存在差异的多个查询。

作者 Julie Lerman 你大概注意到了，自 2008 年以来，我写过许多关于 Entity Framework（即 Microsoft 对象关系映射器 (ORM)）的文章，ORM 一直是主要的 .NET 数据访问 API。市面上还有许多其他 .NET ORM，但是有一个特殊类别因其强大的性能得到的关注最高，那就是微型 ORM。我听人提到最多的微型 ORM 是 Dapper。据不同的开发者说，他们使用 EF 和 Dapper 制定了混合解决方案，让每个 ORM 能够在单个应用程序中做它最擅长的事，这最终激发了我的兴趣，促使我在最近抽出时间来一探究竟。 在阅读大量文章和博客文章，与开发者聊过天并熟悉过 Dapper 后，我想与大家分享我的一些发现，尤其是和像我这样，可能听说过 Dapper 但并不知道它是什么或者并不知道它的工作原理的人分享，同时说说人们为什么这么喜欢它。需要提醒你的是，我根本不是什么专家。目前我只是为了满足我的好奇心而变得足够了解，并且希望激发你的兴趣，从而进一步探索。 为什么是 Dapper？ Dapper 的历史十分有趣，它是从你可能再熟悉不过的资源中衍生的： Marc Gravell 和 Sam Saffron 在研究 Stack Overflow，解决此平台的性能问题时构建了 Dapper。考虑到 Stack Overflow 是一个流量极高的站点，那么必然存在性能上的问题。根据 Stack Exchange About 网页，在 2015 年，Stack Overflow 拥有 57 亿的网页浏览量。在 2011 年，Saffron 撰写过一篇关于他和 Gravell 所做的工作的博客文章，名为“我如何学会不再担忧和编写我自己的 ORM”(bit.ly/)，这篇文章介绍了 Stack 当时存在的性能问题，该问题源于 LINQ to SQL 的使用。他在文中详细介绍了为什么编写自定义 ORM，其中 Dapper 就是优化 Stack Overflow 上的数据访问的答案。五年后的今天，Dapper 已被广泛使用并已成为开源软件。Gravell 和 Stack 及团队成员 Nick Craver 继续在 github.com/StackExchange/dapper-dot-net 上积极地管理项目。 ...

当一个实体类型的任意数量的实体与相同或另一个实体类型的任意数量的实体相关联时，将使用多对多关系。 例如，Post 可以有多个关联的 Tags，并且每个 Tag 可以与任意数量的 Posts 关联。 了解多对多关系 多对多关系不同于一对多和一对一关系，因为它们不能仅使用外键以简单方式表示。 相反，需要其他实体类型来“联接”关系的两端。 这称为“联接实体类型”，并映射到关系数据库中的“联接表”。 此联接实体类型的实体包含外键值对，其中一对指向关系一端的实体，另一对指向关系另一端的实体。 因此，每个联接实体以及联接表中的每一行都表示关系中实体类型之间的一个关联。 EF Core 可以隐藏联接实体类型并在后台对其进行管理。 这允许以自然方式使用多对多关系的导航，从而根据需要在每一端添加或删除实体。 但是，了解后台发生的情况非常有用，以便其整体行为（尤其是映射关系数据库）有意义。 让我们从关系数据库架构设置开始，以表示帖子和标记之间的多对多关系： CREATE TABLE "Posts" ( "Id" INTEGER NOT NULL CONSTRAINT "PK_Posts" PRIMARY KEY AUTOINCREMENT); CREATE TABLE "Tags" ( "Id" INTEGER NOT NULL CONSTRAINT "PK_Tags" PRIMARY KEY AUTOINCREMENT); CREATE TABLE "PostTag" ( "PostsId" INTEGER NOT NULL, "TagsId" INTEGER NOT NULL, CONSTRAINT "PK_PostTag" PRIMARY KEY ("PostsId", "TagsId"), CONSTRAINT "FK_PostTag_Posts_PostsId" FOREIGN KEY ("PostsId") REFERENCES "Posts" ("Id") ON DELETE CASCADE, CONSTRAINT "FK_PostTag_Tags_TagsId" FOREIGN KEY ("TagsId") REFERENCES "Tags" ("Id") ON DELETE CASCADE); 在此架构中，PostTag 是联接表。 它包含两列：PostsId（指向 Posts 表的主键的外键）和 TagsId（指向 Tags 表的主键的外键）。 因此，此表中的每一行都表示一个 Post 和一个 Tag 之间的关联。 ...

当单个实体与任意数量的其他实体关联时，将使用一对多关系。 例如，Blog 可以有多个关联的 Posts，但每个 Post 都只与一个 Blog 相关联。 本文档采用围绕大量示例展开的结构。 这些示例从常见情况着手，还引入了一些概念。 后面的示例介绍了不太常见的配置类型。 此处介绍了一个不错的方法，即了解前几个示例和概念，再根据特定需求转到后面的示例。 基于此方法，我们将从简单的“必需”和“可选”的一对多关系开始。 提示 可在 OneToMany.cs 中找到以下所有示例的代码。 必需的一对多 // Principal (parent) public class Blog { public int Id { get; set; } public ICollection<Post> Posts { get; } = new List<Post>(); // Collection navigation containing dependents } // Dependent (child) public class Post { public int Id { get; set; } public int BlogId { get; set; } // Required foreign key property public Blog Blog { get; set; } = null!; // Required reference navigation to principal } 一对多关系由以下部分组成： ...

当一个实体与最多一个其他实体关联时，将使用一对一关系。 例如，Blog 有一个 BlogHeader，并且 BlogHeader 属于单个 Blog。 本文档采用围绕大量示例展开的结构。 这些示例从常见情况着手，还引入了一些概念。 后面的示例介绍了不太常见的配置类型。 此处介绍了一个不错的方法，即了解前几个示例和概念，再根据特定需求转到后面的示例。 基于此方法，我们将从简单的“必需”和“可选”的一对一关系开始。 可在 OneToOne.cs 中找到以下所有示例的代码。 必需的一对一 // Principal (parent) public class Blog { public int Id { get; set; } public BlogHeader? Header { get; set; } // Reference navigation to dependent } // Dependent (child) public class BlogHeader { public int Id { get; set; } public int BlogId { get; set; } // Required foreign key property public Blog Blog { get; set; } = null!; // Required reference navigation to principal } 一对一关系由以下部分组成： 主体实体上的一个或多个主键或备用键属性。 例如 Blog.Id。 依赖实体上的一个或多个外键属性。 例如 BlogHeader.BlogId。 （可选）引用依赖实体的主体实体上的引用导航。 例如 Blog.Header。 （可选）引用主体实体的依赖实体上的引用导航。 例如，BlogHeader.Blog。 提示 ...

父亲节，女儿很乖，儿子大闹，我又发了一轮火-_- 我们不算是鸡娃的家长，但是对子女有最基本的要求，为了引导和教育子女，我这段时间发现自己对小孩们发脾气的次数变多了。每次发完火之后，我知道这很不好，但是总是不能克制住自己，其实对小孩或者家人发火，只是情绪的宣泄，对谁都不好。我总结自己发火的点： 1、子女们的行为习惯。主要是生活习惯和本来应该养成的好习惯，有时候他们屡教不改，这方面是应该严厉、严格，但是不要动火，否则无济于事。 2、对于子女们的兴趣培养，比如小提琴，总是会有“恨铁不成刚”的想法。如果静下来想想，他们的水平已经远远在我之上，所以很多时候更多是自己的期望值太高。如果能认识到兴趣要坚持和长期培养，那么我确实应该要更有耐心，毕竟核心是要让他们感兴趣地坚持下去。 3、辅导子女们的学业过程。其实想想小孩子需要时间去成长，有时候我是以大人的要求去教育小孩，我应该给他们更多的时间来消化及成长。 我今天反思自己，就是希望自己能控制情绪，作为一个男人，应该能担当、沉住气，这样才能真的起到教育的作用。 “父母所遭受的文化和心理压力或伤害可能会传递到孩子身上。我绝不是危言耸听，我想提醒父母们，我们赋予孩子的一切中，有一半来自我们自己，因此，我们首先需要让自己变成身心健康的人。” 立帖为证，做好自己。

Blazor WebAssembly 主要的 Blazor 托管模型在 WebAssembly 上的浏览器中运行客户端。 将 Blazor 应用、其依赖项以及 .NET 运行时下载到浏览器。 应用将在浏览器线程中直接执行。 UI 更新和事件处理在同一进程中进行。 应用资产作为静态文件部署到可为客户端提供静态内容的 Web 服务器或服务中。 Blazor WebAssembly:Blazor 应用在浏览器内部的 UI 线程上运行。 如果创建了 Blazor WebAssembly 应用进行部署，但没有后端 ASP.NET Core 应用来为其文件提供服务，那么该应用被称为独立 Blazor WebAssembly 应用。 如果创建了应用进行部署，但没有后端应用来为其文件提供服务，那么该应用被称为托管的 Blazor WebAssembly 应用。 托管的 Blazor WebAssembly Client 应用通常使用 Web API 调用或 SignalR（结合使用 ASP.NET Core SignalR 和 Blazor）通过网络与后端 Server 应用交互。 blazor.webassembly.js 脚本由框架和句柄提供： 下载 .NET 运行时、应用和应用依赖项。 初始化运行应用的运行时。 Blazor WebAssembly 托管模型具有以下优点： 没有 .NET 服务器端依赖项。 应用下载到客户端后即可正常运行。 可充分利用客户端资源和功能。 工作可从服务器转移到客户端。 无需 ASP.NET Core Web 服务器即可托管应用。 无服务器部署方案可行，例如通过内容分发网络 (CDN) 为应用提供服务的方案。 Blazor WebAssembly 托管模型具有以下局限性： ...

本教程提供了使用 SignalR 和 Blazor 生成实时应用的基本工作经验。 本文适用于已经熟悉 SignalR 并正在寻求了解如何在 SignalR 应用中使用 Blazor 的开发人员。 有关 SignalR 和 Blazor 框架的详细指南，请参阅以下参考文档集和 API 文档： ASP.NET Core SignalR 概述 ASP.NET Core Blazor .NET API 浏览器 了解如何： 创建 Blazor 应用 添加 SignalR 客户端库 添加 SignalR 集线器 添加 SignalR 服务和 SignalR 中心的终结点 添加用于聊天的 Razor 组件代码 在本教程结束时，你将拥有一个正常运行的聊天应用。 先决条件 Visual Studio Visual Studio Code .NET CLI 具有“ASP.NET 和 Web 开发”工作负载的 Visual Studio 2022 或更高版本 示例应用 本教程不需要下载教程的示例聊天应用。 示例应用是按照本教程的步骤生成的最终工作应用。 查看或下载示例代码（如何下载） 创建 Blazor Web 应用 按照所选工具的指南进行操作： ...