抠丁客
为什么选择 ABP 平台？
本文旨在回答一个重要问题：
“为什么要使用 ABP 平台，而不是从零开始创建一个新的解决方案？”
本文介绍了构建现代软件解决方案所面临的挑战，并解释了 ABP 如何应对这些挑战。
另请参见 https://abp.io/why-abp-io
创建一个新解决方案
当你需要启动一个新解决方案时，有大量问题需要问自己，并且在开始编写第一个业务代码之前，你应该花费大量时间。
创建一个空解决方案
即使创建一个近乎空的解决方案也具有挑战性；
- 如何在项目之间组织你的代码库？
- 分层是什么？它们之间如何交互？
- 如何集成第三方库和系统？
- 如何设置自动化测试？
ABP 提供了一个基于领域驱动设计原则的、架构良好、分层且生产就绪的 启动解决方案。该解决方案还包含为每个层预先配置的单元和集成 测试 项目。
创建这样一个解决方案结构需要良好的架构经验和大量的准备时间。而 ABP 在一分钟内就能提供它。
通用库
你应该使用哪些库来实现通用需求？软件开发生态系统高度动态，很难跟上最新的工具、库、趋势和方法。
ABP 将流行的、成熟的和最新的库****预集成到解决方案中。你无需花费时间集成它们并让它们相互协作。它们开箱即用。
UI 主题和布局
当涉及到 UI 时，存在许多挑战，包括准备基础来创建具有一致外观和感觉以及大量功能（如左/顶导航菜单、页眉、工具栏、页脚、小部件等）的响应式、现代化和灵活的 UI 套件。
即使你购买了一个预构建的主题，将其集成到你的解决方案中也可能需要数天的开发时间。升级这样的主题是另一个问题。大多数情况下，主题的 HTML/CSS 结构会与你的 UI 代码混合在一起，以后升级或更改主题并不容易。
ABP 提供了一个主题系统，使你的 UI 代码独立于主题。主题是隔离的，并且它们是 NuGet/NPM 包。安装或升级主题只需一分钟。虽然你可以构建自己的主题（或集成现有主题），但 ABP 提供了专业且现代化的主题。
还有 UI 组件供应商（如 Telerik 和 DevExpress）。但它们只提供单独的组件。你需要负责创建自己的布局系统。你可以在基于 ABP 的解决方案中使用这些库，就像在任何其他项目中一样。
测试基础设施
准备一个健壮的测试环境需要时间。你需要在解决方案中设置测试项目，选择工具，模拟服务和数据库，创建所需的基础类和实用服务以减少测试中的重复代码等等。
ABP 启动模板已经为你配置好了测试项目，你可以在第一天立即编写第一个单元或集成测试代码。使用 ABP 编写单元测试非常清晰；请参阅如何编写测试。
编码标准和培训
一旦你创建了可用于开发的解决方案，通常需要培训开发人员以解释系统，并以标准和一致的方式、遵循相同的约定进行开发。即使你培训了开发人员，也很难准备和维护你的文档。随着时间的推移，每个开发人员都会以不同的方式编写代码，编码标准将开始出现分歧。
ABP 解决方案已经是定义良好且文档齐全的。教程和最佳实践指南清楚地解释了如何在 ABP 项目上进行开发。
保持解决方案更新
开始开发后，你必须跟踪所使用的库的新版本以进行升级和补丁更新。我们会定期将所有软件包更新到最新版本，并在稳定版发布前进行测试。当你更新 ABP 时，其所有依赖项都会升级到前沿技术。
abp update CLI 命令会自动发现并升级解决方案中所有依赖 ABP 的 NuGet 和 NPM 包。使用 ABP，保持最新版本变得更加容易。
不要重复你自己
创建一个基础的解决方案需要大量时间，并且需要良好的架构经验。然而，这仅仅是个开始！当你开始开发时，很可能需要编写大量重复的代码；如果所有这些都能自动处理，那就太好了。
ABP 通过遵循约定优于配置的原则，尽可能自动化和简化重复代码。然而，当需要切换到手动模式时，它并不会限制你。控制权始终在你手中。
认证
单点登录、Active Directory / LDAP 集成、OpenIddict 集成、社交登录、双因素认证、忘记/重置密码、邮箱激活、新用户注册、密码复杂度控制、失败尝试锁定账户、显示失败的登录尝试……等等。我们知道所有这些通用需求对你来说都很熟悉。你并不孤单！
ABP 及其商业版本为你预先实现了所有这些标准功能，作为一个可重用的账户模块。你只需启用并配置你需要的部分。
横切关注点
横切关注点是应该为每个用例实现的基本重复逻辑。一些例子：
- 启动事务，成功时提交，出错时回滚。
- 处理和报告异常，向客户端返回适当的错误响应，并在客户端处理错误情况。
- 实现授权和验证，返回适当的响应，并在客户端处理这些情况。
ABP 自动化或简化了所有常见的横切关注点。你只编写对你的业务重要的代码，ABP 通过约定处理其余部分。
架构基础设施
你通常需要构建基础设施来正确地实现你的架构。例如，你通常实现仓储模式。你定义一些基类来简化和标准化实体、服务、控制器和其他对象的创建。ABP 开箱即用地提供了所有这些以及更多。它成熟且文档齐全。
企业应用需求
在每个业务应用中，你都会重复实现很多需求；
- 详细的权限系统，以及基于角色和用户在 UI 上管理权限。
- 编写审计日志和实体历史以跟踪用户何时修改数据库记录。
- 使你的实体支持软删除，这样它们被标记为删除，而不是从数据库中物理删除，并在查询中自动过滤已删除的实体。
- 创建抽象和包装器以从前端代码消费你的后端 API。
- 排队并执行后台作业。
- 在全局系统中处理多个时区。
- 在服务器和客户端之间共享验证、本地化、授权逻辑。
还有更多。ABP 提供了基础设施来轻松实现这些需求。再次强调，你不必花费宝贵的时间一次又一次地重新实现所有这些。
生成初始代码和工具
ABP Suite 可以在几秒钟内为你的实体生成全栈 CRUD 页面。生成的代码是分层且清晰的。所有标准的验证和授权需求都已实现。此外，还会生成单元测试类。一旦你获得一个完全可运行的页面，就可以根据你的业务需求修改它。
集成第三方库和系统
大多数库被设计为低级的，你通常需要做一些工作来正确地集成它们，而无需在解决方案中到处重复相同的集成和配置代码。
例如，假设你必须使用 RabbitMQ 来实现你的分布式事件总线。你只想做的是：向队列发送消息并处理接收到的消息。但你需要理解消息模式、队列和交换细节。要编写高效的代码，你必须创建一个池来管理连接、客户端和通道。你还必须处理异常、ACK 消息、失败时重新连接到 RabbitMQ 等等。
ABP 的 RabbitMQ 分布式事件总线集成抽象了所有这些细节。你可以无忧无虑地发送和接收消息。需要编写低级代码吗？没问题，你随时可以这样做。当你需要使用所用库的低级特性时，ABP 不会限制你。
大量功能
标记帮助器、动态表单、BLOB 存储系统以及许多其他 ABP 功能帮助你保持 DRY（不要重复你自己）并专注于你的业务。
为什么不构建你自己的框架？
所有基础设施，即使是最简单的方式，也需要大量时间来构建、维护和记录文档。它会随着时间的推移而变得庞大，在你的解决方案中变得难以维护。将这些分离到一个可重用的项目中，是构建你自己内部框架的起点。
构建、记录文档、培训和维护一个内部框架真的很难。如果你没有一个经验丰富、专门负责框架的团队，你的内部框架很快就会变成无人能理解和维护的未记录的遗留代码。另一方面，这些框架通常由团队中的一两个开发人员开发。而这些伙伴正在成为知识孤岛。这对他们有好处，但对公司不利，因为他们是项目的单点故障 -SPOF-。一旦他们离开公司，项目就会急剧下滑。
架构基础设施
SaaS 应用、模块化或微服务系统是最常用的企业软件模型。构建这样的系统不仅需要良好的理解和经验，还需要强大的软件基础设施。否则，你会发现自己在代码库中花费大量精力来支持这些架构细节。
模块化
构建一个真正的模块化系统并不容易！系统的所有方面（数据库、实体、API、UI 页面/组件）都可以拆分为模块，每个模块都可以在其他模块不存在的情况下重用。普通的 ASP.NET Core 不提供这样的模块化架构。如果你需要它，应该从头开始思考。
ABP 天生就是一个模块化应用程序开发结构。框架中的每个功能都是为了与模块化兼容而开发的。文档和指南解释了如何以标准方式开发可重用的模块。
SaaS / 多租户
多租户 是实现 SaaS 系统的常用方式。然而，实现一个一致的多租户基础设施可能会变得复杂。
ABP 提供了一个完整的多租户基础设施，并将复杂性从你的业务代码中抽象出来。你的应用程序代码将主要是多租户感知的，而 ABP 会自动将租户的数据库、缓存和其他细节彼此隔离。它支持单一数据库、每个租户一个数据库和混合方法。它正确地配置了像 Microsoft Identity 和 OpenIddict 这样的库，这些库通常不兼容多租户。
微服务
构建一个微服务系统需要许多基础设施细节：对应用程序和微服务进行身份验证和授权，以及实现微服务之间的异步消息传递和同步（Rest/GRPC）通信模式是最基本的问题。
ABP 提供服务、指南和示例，帮助你使用行业标准工具实现微服务解决方案。
ABP 甚至更进一步，提供了一个完整的启动模板来启动你的微服务解决方案。
预构建模块
我们所有人都有相似但略有不同的业务需求。然而，我们所有人都应该重新发明轮子，因为别人的代码无法直接在我们的解决方案中工作。它们都是一个更大解决方案的嵌入部分。
ABP 模块 提供了许多可重用的应用程序模块，如支付、聊天、文件管理、审计日志报告……等等。所有这些模块都可以轻松安装到你的解决方案中并直接工作。我们正在不断添加更多模块。
所有模块都设计为可根据你的业务需求进行定制。如果你需要完全控制，可以下载任何模块的完整源代码，并根据你的具体业务需求进行完全定制。
ABP 社区
最后，身处一个大型社区中，每个人都遵循相似的编码风格和原则，并共享一个共同的基础设施，当你遇到麻烦或需要设计决策帮助时，会带来力量。因为我们以相似的方式编写代码，所以我们可以更好地互相帮助。ABP 是一个社区支持的项目，在 GitHub 上有超过 10K 星。
在 ABP 开发人员之间共享代码甚至可重用库很容易。一个对你有用的代码片段对其他人也有效。有很多示例和教程，你可以直接为你的应用程序实现。
当你雇佣一位以前使用过 ABP 架构的开发人员时，他会立即理解你的解决方案并在很短的时间内开始开发。
你心中的疑问
学习曲线高吗？
学习曲线比不使用 ABP 低得多。这对你来说可能听起来令人惊讶，但让我们解释一下；
ABP 在几秒钟内为你创建一个全栈、生产就绪、可工作的解决方案。许多现实生活中的问题已经解决，许多微调配置已经应用于 ASP.NET Core 和其他使用的库。如果从零开始，你将亲身体验和学习所有这些细节，以真正实现你的解决方案。
ABP 使用你已经知道（或需要学习以构建真实世界产品）的行业标准框架、库和系统，如 Angular、Blazor、MAUI、EF Core、AutoMapper（由于许可问题已切换到 Mapperly）、OpenIddict、Bootstrap、Redis、SignalR……等等。因此，你所有的知识都可以直接在 ABP 中重用。ABP 甚至简化了使用这些库和系统，并解决了集成问题。如果你现在不知道这些工具，在 ABP 内学习它们会更容易。
ABP 提供了一个绝佳的基础设施来应用 DDD 原则和其他最佳实践。它提供了许多出色的抽象和自动化来减少重复代码。然而，它并不强迫你使用或应用所有这些。一个常见的错误是认为 ABP 有很多功能，并且很难全部学会。拥有很多功能是一个优势，当你需要它们时就能体会到。但是，在你需要某个功能之前，你不需要知道它，你可以继续使用你习惯的开发方法。你仍然可以像没有 ABP 提供所有这些好处那样编写代码。学习 ABP 基础设施是渐进式的。每当你学会一个新功能时，你会爱上它，但即使不知道它的存在，也可以继续开发。
最后，学习一个 ABP 功能比你自己构建相同的功能要容易得多。我们已经为你完成了艰苦的工作并很好地记录了它。当你学习时，你会享受并爱上它。
对于简单的 CRUD 应用程序来说，它是累赘吗？
ABP 简化了构建 CRUD 应用程序，因为 CRUD 应用程序更适合自动化。
ABP 提供了默认的仓储、CRUD 应用服务基类、预构建的 DTO 类、简化的客户端到服务器通信方法、UI 组件、助手等，用于以生产质量为你的应用程序构建 CRUD 功能。
ABP Suite 甚至可以在你定义实体的属性时自动创建生产级的 CRUD 功能。
最后，大多数应用程序和系统在开始时被认为是简单的，但它们会随着时间的推移而增长。一旦你的应用程序增长并且你需要实现一些高级需求时，ABP 将为你提供更多帮助。
它是否足够应对复杂系统？
ABP 旨在解决现实世界的问题并构建复杂的系统。它为你的系统实现了很多基础设施需求，并提供了与许多企业系统和工具的集成。
我们当然知道复杂性的高山没有尽头，没有人能给你提供一切。ABP 平台是一架直升机，它将你置于高山的一个高点，并提供许多有用的工具来帮助你自行攀登其余部分。
如果我想定制它呢？
定制有不同的类型和级别：
- ABP 本身是高度可定制的。你几乎可以替换和覆盖任何服务。第三方依赖是抽象的，通常提供多种替代方案。你可以实现自己的集成来扩展框架。
- 模块被设计为可从数据库到用户界面进行定制和扩展。框架提供了一个标准扩展性模型，在可能的地方都已实现。
- 模块被设计为分层且兼容不同的架构。它们可以用作单体应用程序的一部分，也可以作为具有自己数据库的独立微服务部署。
- 模块彼此独立。你可以在不接触其他模块的情况下移除一个模块。
对于大多数应用程序来说，这些已经绰绰有余。然而，它可能与你的解决方案中的代码不同。当你想要完全更改一个模块时，你随时可以用它的源代码替换它。对于 ABP 模块，我们总是提供源代码选项。
如果我需要绕过 ABP 抽象层怎么办？
ABP 在 ASP.NET Core 和一些其他库之上提供了许多抽象，以简化开发并提高你的生产力。然而，你总有可能不使用 ABP 抽象，而直接使用底层 API。
例如，ABP 提供了仓储来简化数据访问。但是，如果你愿意，你可以像在任何 .NET 项目中那样，直接访问 DbContext 并使用任何 Entity Framework Core API。
我可以使用其他数据库系统吗？
ABP 开箱即用地提供了 Entity Framework Core（你可以使用几乎任何关系型数据库系统）和 MongoDB 集成。此外，它还提供了与 EF Core 兼容的 Dapper 集成。所有预构建模块都有 EF Core 和 MongoDB 选项。
如果你需要使用任何其他数据库系统，可以使用它的库和 API。ABP 在这里没有任何限制。例如，你可以在你的应用程序代码中使用 Cassandra。如果你使用预构建模块，它可能没有 Cassandra 集成包。这里你有两个选择：你可以自己实现 Cassandra 集成（通过实现模块定义的一些仓储接口），或者让模块继续使用它自己的数据库。多个数据库系统可以毫无问题地在一个应用程序中运行。
ABP 会拖慢我的应用程序吗？
ABP 自动化了许多你如果不使用它就需要手动实现的常见任务。一些例子是异常处理、验证、授权、工作单元（和事务管理）、审计日志……等等。
如果你自己编写了所有这些代码，并且它们在每个 HTTP 请求中运行，会不会让你的应用程序代码变慢一点？是的，ABP 会让你的应用程序稍微慢一点。好消息是开销不大，并且 ABP 功能已经过优化。如果你开始禁用这些 ABP 功能，你会看到开销减少。然而，你通常需要这些功能；轻微的性能差异是可以接受的。如前所述，如果你自己编写这些，也会有类似的性能开销。
因此，对于大多数系统，性能开销可以安全地忽略不计。对于其他系统，你可以禁用不需要的 ABP 功能。
ABP 是 CMS 吗？
ABP 不是 CMS（内容管理系统）。它是一个通用的业务应用程序开发框架。该框架不为 CMS 或任何应用程序做任何假设。它分层良好，核心模块与 Web 或 ASP.NET Core 无关，可用于开发控制台应用程序、后台服务或任何 .NET 兼容的应用程序。
顺便说一下，ABP 提供了模块化功能，可以在其之上开发 CMS 模块或 CMS 系统。我们已经提供了一个 CMS Kit 模块，它提供了一些常见的 CMS 基本组件，以便你可以在其上构建自己的 CMS。
