From 18417634387c0f9b404ac144678386dcb3bb9a0d Mon Sep 17 00:00:00 2001
From: Your Name <you@example.com>
Date: Sun, 7 Jul 2024 21:37:59 +0800
Subject: [PATCH] webapi

---
 .../20240701 - RBAC.md"                       | 25 ++++++
 ...20240702 - ddd\350\256\276\350\256\241.md" | 65 +++++++++++++++
 ...06\345\261\202\346\236\266\346\236\204.md" | 26 ++++++
 .../20240704 - Fluntapi.md"                   | 83 +++++++++++++++++++
 .../20240705 - post.md"                       | 31 +++++++
 5 files changed, 230 insertions(+)
 create mode 100644 "\351\202\261\346\245\267\346\235\255/20240701 - RBAC.md"
 create mode 100644 "\351\202\261\346\245\267\346\235\255/20240702 - ddd\350\256\276\350\256\241.md"
 create mode 100644 "\351\202\261\346\245\267\346\235\255/20240703 - \345\210\206\345\261\202\346\236\266\346\236\204.md"
 create mode 100644 "\351\202\261\346\245\267\346\235\255/20240704 - Fluntapi.md"
 create mode 100644 "\351\202\261\346\245\267\346\235\255/20240705 - post.md"

diff --git "a/\351\202\261\346\245\267\346\235\255/20240701 - RBAC.md" "b/\351\202\261\346\245\267\346\235\255/20240701 - RBAC.md"
new file mode 100644
index 0000000..2ad447f
--- /dev/null
+++ "b/\351\202\261\346\245\267\346\235\255/20240701 - RBAC.md"	
@@ -0,0 +1,25 @@
+# rbac
+## 概念
+Role-Based Access Control，中文意思是：基于角色（Role）的访问控制。这是一种广泛应用于计算机系统和网络安全领域的访问控制模型。
+
+简单来说，就是通过将权限分配给➡角色，再将角色分配给➡用户，来实现对系统资源的访问控制。一个用户拥有若干角色，每一个角色拥有若干权限。这样，就构造成“用户-角色-权限”的授权模型。在这种模型中，用户与角色之间，角色与权限之间，一般者是多对多的关系。具体而言，RBAC模型定义了以下几个核心概念：
+
+角色（Role）：角色是指在系统中具有一组相关权限的抽象概念，代表了用户在特定上下文中的身份或职能，例如管理员、普通用户等。
+
+权限（Permission）：权限是指对系统资源进行操作的许可，如读取、写入、修改等。权限可以被分配给角色。
+
+用户（User）：用户是指系统的实际使用者，每个用户可以被分配一个或多个角色。
+
+分配（Assignment）：分配是指将角色与用户关联起来，以赋予用户相应的权限。
+
+RBAC 认为授权实际上是Who 、What 、How 三元组之间的关系，也就是Who 对What 进行How 的操作，也就是“主体”对“客体”的操作。
+
+Who：是权限的拥有者或主体（如：User，Role）。
+
+What：是操作或对象（operation，object）。
+
+How：具体的权限（Privilege,正向授权与负向授权）。
+
+通过RBAC模型，可以实现灵活且易于管理的访问控制策略。管理员可以通过分配和调整角色，来管理用户的权限。这种角色层次结构可以帮助简化权限管理，并确保用户只有所需的权限。
+
+RBAC模型广泛应用于系统安全、数据库管理、网络管理等领域，它提供了一种可扩展、可管理的访问控制机制，有助于保护系统资源免受未经授权的访问和潜在的安全威胁。
diff --git "a/\351\202\261\346\245\267\346\235\255/20240702 - ddd\350\256\276\350\256\241.md" "b/\351\202\261\346\245\267\346\235\255/20240702 - ddd\350\256\276\350\256\241.md"
new file mode 100644
index 0000000..5e533f5
--- /dev/null
+++ "b/\351\202\261\346\245\267\346\235\255/20240702 - ddd\350\256\276\350\256\241.md"	
@@ -0,0 +1,65 @@
+# ddd设计
+## 概述
+领域驱动设计（Domain-Driven Design，简称DDD）是一种软件设计方法，它强调以业务领域为中心进行软件开发，将业务专家的知识和系统设计紧密结合，以确保软件设计能够真实反映业务需求。
+
+## 核心概念
+领域（Domain）
+领域是指具有共同语言和边界的特定业务领域。
+
+子领域（Subdomain）
+子领域是领域内的一个特定部分，具有其独特的业务逻辑。
+
+领域模型（Domain Model）
+领域模型是业务概念和业务逻辑的软件表示，它包括实体、值对象、聚合、领域服务等。
+
+实体（Entity）
+实体是具有唯一标识和生命周期的领域对象。
+
+值对象（Value Object）
+值对象是描述领域概念的属性，它们是不可变的，并且通过相等性比较。
+
+聚合（Aggregate）
+聚合是由一个根实体和多个值对象组成的集合，它们一起构成一个数据修改的单元。
+
+领域服务（Domain Service）
+领域服务是领域逻辑的一部分，通常用于处理不自然属于实体或值对象的业务规则。
+
+领域事件（Domain Event）
+领域事件是领域中发生的有意义的业务事件，它们可以触发其他业务逻辑。
+
+DDD 实践
+统一语言（Ubiquitous Language）
+开发团队与业务专家使用统一的语言来沟通，确保双方对业务概念有共同的理解。
+
+限界上下文（Bounded Context）
+限界上下文定义了模型和语言的边界，确保在不同上下文中模型的一致性和清晰性。
+
+持续集成（Continuous Integration）
+团队成员持续集成他们的工作，以确保模型和实现的一致性。
+
+反腐层（Anti-Corruption Layer）
+反腐层用于隔离不同限界上下文之间的模型，防止模型的腐败。
+
+DDD 架构风格
+六边形架构（Hexagonal Architecture）
+六边形架构是一种软件架构模式，它将应用程序的核心与外部基础设施分离，使得应用程序可以在不同的基础设施上运行。
+
+洋葱架构（Onion Architecture）
+洋葱架构是一种分层架构模式，它将应用程序的不同关注点分层，每一层只依赖于更内层的代码。
+
+实现步骤
+领域探索：与业务专家合作，理解业务领域和需求。
+定义模型：创建领域模型，包括实体、值对象、聚合等。
+开发应用服务：开发应用服务来处理应用程序的业务逻辑。
+集成基础设施：将应用服务与数据库、消息队列等基础设施集成。
+持续迭代：根据反馈持续迭代领域模型和应用服务。
+优势与局限
+优势
+业务对齐：确保软件设计与业务需求紧密对齐。
+可维护性：清晰的模型和架构有助于软件的长期维护。
+可扩展性：灵活的架构支持业务的扩展和变化。
+局限
+学习曲线：DDD 需要团队成员理解和掌握新的概念和实践。
+过度设计：在某些情况下，DDD 可能导致过度设计。
+结论
+领域驱动设计是一种强大的方法论，它帮助开发团队深入理解业务领域，创建与业务紧密对齐的软件系统。通过DDD，可以提高软件的质量和可维护性，同时支持业务的持续发展。
\ No newline at end of file
diff --git "a/\351\202\261\346\245\267\346\235\255/20240703 - \345\210\206\345\261\202\346\236\266\346\236\204.md" "b/\351\202\261\346\245\267\346\235\255/20240703 - \345\210\206\345\261\202\346\236\266\346\236\204.md"
new file mode 100644
index 0000000..fe959f0
--- /dev/null
+++ "b/\351\202\261\346\245\267\346\235\255/20240703 - \345\210\206\345\261\202\346\236\266\346\236\204.md"	
@@ -0,0 +1,26 @@
+# 分层架构
+## 概念
+项目分层架构是一种常见的软件架构设计模式，旨在将系统分解为若干层次，每一层都具有特定的责任和关注点。这种架构模式有助于提高代码的可维护性、可扩展性和可测试性，同时促进团队协作和开发效率。
+
+## 典型的分层架构
+应用服务层（Application Service Layer）：
+
+应用服务层包含应用程序的核心逻辑和用例。
+负责协调领域对象和应用服务之间的交互，处理业务逻辑并调用领域层来实现具体的业务功能。
+应用程序接口层(Application.Contracts)
+
+服务接口：定义应用程序层服务的方法和操作。
+DTOs（数据传输对象）：定义用于在不同层之间传递数据的结构和格式。
+领域层（Domain Layer）：
+
+领域层包含业务对象、实体、值对象和领域服务。
+它体现了系统的核心业务规则和逻辑，保证数据的有效性和一致性，是系统的核心。
+基础设施层（Infrastructure Layer）：
+
+基础设施层提供支持系统运行的基础设施服务和工具。
+包括数据库访问、文件系统、外部服务接口等，负责与外部系统的通信和数据存储。
+设计原则和实践
+单一职责原则（SRP）：每一层次和组件应该只有一个引起变化的原因。
+依赖反转原则（DIP）：高层次模块不应依赖于低层次模块，而是应该依赖于抽象。
+开闭原则（OCP）：系统应该对扩展开放，对修改关闭，通过接口和抽象来实现可扩展性。
+接口隔离原则（ISP）：不应该强迫客户依赖于它们不使用的接口。
\ No newline at end of file
diff --git "a/\351\202\261\346\245\267\346\235\255/20240704 - Fluntapi.md" "b/\351\202\261\346\245\267\346\235\255/20240704 - Fluntapi.md"
new file mode 100644
index 0000000..c4f9524
--- /dev/null
+++ "b/\351\202\261\346\245\267\346\235\255/20240704 - Fluntapi.md"	
@@ -0,0 +1,83 @@
+# fluntapi
+## 概念
+Fluent API是Entity Framework Core中用于配置数据库模型的一种强大工具。相比传统的属性标记或XML配置，Fluent API通过链式调用方法来定义实体类与数据库之间的映射关系，提供了以下几个显著优势和常见用法：
+
+优势和用法总结：
+可读性和可维护性：
+
+Fluent API通过链式调用方法，使得配置代码更加清晰和易读。特别是在配置复杂的数据库关系和索引时，相比使用属性标记或XML配置，它更容易理解和维护。
+灵活性：
+
+提供了丰富的配置方法，可以精确控制实体的映射细节，包括表名、主键、列名、数据类型、索引、外键关系等。这种灵活性允许开发人员根据实际需求对数据库模型进行精细化调整。
+集中式配置：
+
+可以将所有与数据库映射相关的配置集中在一个或多个实现了IEntityTypeConfiguration<TEntity>接口的配置类中。这种做法有助于代码的组织和维护，使得数据库映射配置更加结构化和易管理。
+不侵入性：
+
+Fluent API的配置与实体类本身解耦，不需要侵入到实体类的定义中。这样可以保持实体类的简洁性和纯粹性，不受特定ORM特性的限制，增强了代码的可移植性和可测试性。
+
+## 例子
+```js
+
+ using Microsoft.EntityFrameworkCore;
+using Microsoft.EntityFrameworkCore.Metadata.Builders;
+using System.Collections.Generic;
+
+public class Product
+{
+    public int ProductId { get; set; }
+    public string Name { get; set; }
+    public decimal Price { get; set; }
+
+    public int CategoryId { get; set; }
+    public Category Category { get; set; }
+}
+
+public class Category
+{
+    public int CategoryId { get; set; }
+    public string Name { get; set; }
+
+    public ICollection<Product> Products { get; set; }
+}
+
+public class ProductConfiguration : IEntityTypeConfiguration<Product>
+{
+    public void Configure(EntityTypeBuilder<Product> builder)
+    {
+        builder.ToTable("Products"); // 表名
+        builder.HasKey(p => p.ProductId); // 主键
+
+        builder.Property(p => p.Name)
+               .HasColumnName("ProductName")
+               .HasMaxLength(100)
+               .IsRequired(); // 列配置
+
+        builder.Property(p => p.Price)
+               .HasColumnType("decimal(18,2)")
+               .IsRequired(); // 列配置
+
+        builder.HasOne(p => p.Category)
+               .WithMany(c => c.Products)
+               .HasForeignKey(p => p.CategoryId); // 外键关系
+    }
+}
+
+public class CategoryConfiguration : IEntityTypeConfiguration<Category>
+{
+    public void Configure(EntityTypeBuilder<Category> builder)
+    {
+        builder.ToTable("Categories"); // 表名
+        builder.HasKey(c => c.CategoryId); // 主键
+
+        builder.Property(c => c.Name)
+               .HasMaxLength(50)
+               .IsRequired(); // 列配置
+
+        builder.HasMany(c => c.Products)
+               .WithOne(p => p.Category)
+               .HasForeignKey(p => p.CategoryId); // 导航属性配置
+    }
+}
+
+```
\ No newline at end of file
diff --git "a/\351\202\261\346\245\267\346\235\255/20240705 - post.md" "b/\351\202\261\346\245\267\346\235\255/20240705 - post.md"
new file mode 100644
index 0000000..8ad9906
--- /dev/null
+++ "b/\351\202\261\346\245\267\346\235\255/20240705 - post.md"	
@@ -0,0 +1,31 @@
+# post
+
+## o
+EF Core 使用元数据模型来描述如何将应用程序的实体类型映射到基础数据库。
+
+此模型是使用一组约定构建的，这些约定是寻找常见模式的启发式方法。 然后，可以使用映射特性（也称为数据注释）自定义模型
+
+在 OnModelCreating 中调用 ModelBuilder 方法（也称为 Fluent API），这两者都将替代约定执行的配置。
+
+大多数配置可以应用于面向任何数据存储的模型。
+
+提供程序还可以启用特定于特定数据存储的配置，也可以忽略不支持或不适用的配置。
+
+有关提供程序特定配置的文档，请参阅数据库提供程序部分。
+
+## fluent API 配置模型
+可在派生上下文中替代 OnModelCreating 方法，并使用 Fluent API 来配置模型
+分组配置
+为了减小 OnModelCreating 方法的大小，可以将实体类型的所有配置提取到实现 IEntityTypeConfiguration 的单独类中。
+生成id的几种方式
+UUID （无序，基本可以认为不会重复，有根据mac地址生成（这种会暴露隐私）、时间、或者名称生成）
+数据库自增主键（分表的情况下会有问题，无法保证唯一性）
+redis的INCR和INCEBY（实际项目中没见过这样做的）
+雪花算法生成id（有序，不需要依赖中间件，但是因为有序可能会暴露隐私，导致安全问题；依赖时间戳，若时间快了重新校准，有时钟回拨问题）
+## 雪花算法
+雪花算法介绍
+雪花算法的原理就是生成一个的 64 位比特位的 long 类型的唯一 id。
+1：最高 1 位是符号位，固定值 0，表示id 是正整数
+41：接下来 41 位存储毫秒级时间戳，2^41/(1000606024365)=69，大概可以使用 69 年。
+10：再接下 10 位存储机器码，包括 5 位 datacenterId 和 5 位 workerId。最多可以部署 2^10=1024 台机器。
+12：最后 12 位存储序列号。同一毫秒时间戳时，通过这个递增的序列号来区分。即对于同一台机器而言，同一毫秒时间戳下，可以生成 2^12=4096 个不重复 id。
\ No newline at end of file
-- 
Gitee