解决方案模板：为您选择合适模板的指南

ABP为您提供了多个启动模板。从一个适合您的项目和团队的正确启动模板开始非常重要。本指南旨在引导您根据需求选择最合适的启动模板。

将基于ABP启动模板讨论以下架构：

单层（非分层）应用程序
N层应用程序
模块化应用程序
微服务解决方案

什么是启动模板？

在接下来的部分，您将了解什么是启动模板以及它提供什么。

预架构的解决方案结构

启动解决方案模板是一个预架构的结构。例如，如果您想基于领域驱动设计原则和模式构建分层应用程序代码库，分层启动模板是一个很好的起点。

然而，从任何启动模板开始并不会限制您添加或删除项目、层、集成包以及创建其他应用程序/服务。您甚至可以从单层应用程序模板开始，并将其转换为微服务解决方案。但是，如果您想构建一个微服务解决方案，从微服务启动模板开始是最佳选择。

因此，最好从最适合您目的的启动模板开始，然后修改解决方案以满足您的自定义需求。

结构良好的代码组织

除了整体解决方案结构外，解决方案模板中每个项目的内部结构也组织良好。您将清楚地知道在哪里放置您的实体、仓储、数据访问代码、应用服务、API控制器、UI元素等。您无需在每个新项目中花费时间思考如何组织您的代码库。如果您喜欢为应用程序构建自动化测试，测试项目也已包含并预先配置好。

库集成与配置

当您使用ABP启动解决方案模板创建新解决方案时，一些基础库的安装（Serilog、Autofac、Mapperly、Swagger、HealthCheck等）及其经过微调的配置已经为您准备好了。同时，所需的**ABP包会根据您的偏好进行安装，并针对开发和生产环境**进行配置。

开发就绪

当您创建新解决方案，或者新队友开始处理您现有解决方案时，借助解决方案结构文档和开发教程，非常容易理解解决方案结构、设计决策和开发流程。

生产就绪

ABP的启动模板开箱即用，即可用于生产。您只需创建一个新解决方案并将其部署到您的生产环境。这不仅是技术就绪，也是功能就绪。

当您创建新的ABP解决方案时，基础模块已经安装。您的应用程序拥有一个稳健的账户模块（用户注册、登录、社交登录、双因素认证、用户锁定、密码复杂度控制...）、一个高级的身份模块（用户、角色和权限管理），以及许多其他生产就绪的预构建应用模块在第一天就能作为您应用程序的一部分正常工作。

启动解决方案模板

到目前为止，已经解释了什么是启动模板及其提供的功能。在接下来的部分，您将看到启动解决方案模板的类型以及哪种最适合您。

单层应用程序解决方案模板

单层解决方案模板是最简单的。它在启动新项目时提供了最小的解决方案架构。您的.NET解决方案通常包含单个或少数几个.NET项目，这取决于您在创建解决方案时选择的UI和其他偏好。

下图显示了一个具有MVC (Razor Pages) UI和Entity Framework Core数据库提供程序的单项目Web应用程序，采用默认配置：

如上图所示，所有应用程序代码（实体、数据访问、服务、UI页面等）都位于单个.NET项目中。

何时应使用单层解决方案模板？

在以下情况下，您可以考虑使用单层解决方案模板：

如果您的项目很小，并且您不期望它会随时间增长。但请记住，许多项目一开始都被认为是小的。
如果您的项目是一个临时项目，并且将在短时间内废弃。它可能是一个POC项目或用于演示或广告活动的临时应用程序。
如果您是单个开发者，或者只有2-3名开发人员在您的解决方案上工作，并且这些开发人员经验不足，也不愿意理解分层应用程序的结构和好处。

如果上述情况与您的项目相符，您可以考虑从该解决方案模板开始。然而，请记住，您的解决方案可能很快变成一个**大泥球。我们认为只有极少数应用程序**适合这种解决方案结构。

请注意，单层解决方案模板不提供以下选项/功能：

移动应用程序集成
公共网站（用于产品落地页的第二个Web应用程序）
分层架构（对于MVC应用程序，分离UI和服务层）
独立的租户架构（对于多租户应用程序）
Kubernetes / Helm配置
自动化（单元/集成）测试项目

这些选项未实现，以保持解决方案结构尽可能简单。如果您需要其中一些功能，请随时使用分层解决方案模板。

分层解决方案模板

分层应用程序启动模板是一个由多个项目组成的.NET解决方案。每个项目代表应用程序的一个层或具有解决方案的特定功能。

解决方案中确切的项目数量取决于您选择的选项。下图显示了一个具有MVC (Razor Pages) UI和Entity Framework Core数据库提供程序的解决方案，采用默认配置：

该解决方案基于领域驱动设计原则进行分层，并根据现实世界的业务应用程序需求进行了扩展。它包含每层的测试项目。解决方案分层具有显著优势：

它使您的业务代码（领域层和应用层）独立于基础设施（UI和数据库），使其更易于维护且寿命更长。
不同的开发人员可以专注于不同的层。当多个开发人员（角色不同）接触同一个解决方案时，这很有价值。
它分离了关注点，因此您可以一次专注于一个关注点。您可以在不影响其他层的情况下优化数据访问代码，您可以在不破坏业务逻辑的情况下更改UI代码。
它提供了最大的代码可重用性。如果您有多个应用程序（例如，一个后台办公应用程序、一个最终用户应用程序和一个移动应用程序），可以轻松分离这些应用程序的代码库（只需为每种应用程序类型创建新的应用层和UI层），同时它们可以共享相同的领域层和数据访问层。
分离UI层为将来替换/修改提供了机会，而不影响解决方案的其他部分。您知道，UI是软件行业变化最快的技术。

虽然一开始可能看起来有点复杂，但一旦您完成书店教程，您将轻松理解每个项目的用途和用法。

何时应使用分层解决方案模板？

在以下情况下，您可以考虑使用分层解决方案模板：

如果您的项目代码库相对较大。
如果您的项目相对复杂，涉及多个业务领域或复杂的工作流程。
如果您的项目是一个长期项目，并且您希望将其设计为可维护多年的。
如果您的团队中有多名开发人员在您的解决方案上工作。当多个团队或开发人员处理系统的不同部分时。
如果您的解决方案将拥有多个Web、移动或其他类型的应用程序，这些应用程序需要共享相同的业务逻辑。
如果您的项目需要可扩展性，即功能或用户负载可能随时间增长的解决方案。
如果您的项目需要可扩展性，需要添加新功能或与第三方服务集成。

模块化单体应用程序

ABP不提供特定的模块化单体应用程序启动模板。然而，这并非必需。让我们解释原因。

ABP框架和ABP Studio从一开始就被设计为支持模块化应用程序开发。ABP框架提供了模块化所需的所有必要基础设施，并且所有其他框架功能都与模块化解决方案兼容。

另一方面，ABP Studio的解决方案资源管理器面板的主要目的是架构和构建模块化及复杂的软件解决方案。您可以轻松创建新模块，安排模块之间的依赖关系，并将这些模块导入/安装到单体应用程序中。虽然您可以手动完成所有这些操作，但ABP Studio使其变得极其简单易懂。

如何构建模块化单体应用程序？

一个模块化单体应用程序由单个主机应用程序和多个子模块组成。通常，每个模块都有自己的.NET解决方案，其中包含与该模块相关的代码。因此，通用结构如下图所示：

在此示例中，MyCrm.Host是一个几乎为空的主机应用程序，它引用了其他模块的包。每个模块由两个包组成：实现包和契约包。

您可以按照以下步骤使用ABP Studio创建这样的模块化解决方案：

使用单层或分层应用程序启动模板创建一个新的应用程序。该应用程序将是您解决方案的主机应用程序。
创建新模块（右键单击解决方案根目录，选择添加 -> 新建模块 -> ...命令）。
导入并安装这些模块到主机应用程序。

您可以按照**模块化单体应用程序开发教程**逐步学习如何构建模块化应用程序。

模块化应用程序应使用哪个启动模板？

因此，单层和分层应用程序启动模板本质上都是模块化的。只需选择其中一个并启动您的模块化解决方案即可。您可能想知道从哪个开始：

如果您打算让主机应用程序保持为空，请为您的模块化单体的主机应用程序使用**单层启动模板**。当然，它会包含一些配置代码，但不会包含任何实际的应用代码。这是建议的方法。
如果您将一些应用代码写入主机应用程序，请使用**分层应用程序启动模板**。您可能希望编写一些协调多个模块操作的代码，这些操作在特定模块中不易实现。在这种情况下，分层的主机应用程序将是组织代码库的更好方式。然而，这种方法可能很快使您的解决方案偏离模块化系统。因此，请自行承担风险。

何时应构建模块化单体应用程序？

在以下情况下，您可以考虑构建模块化软件解决方案：

如果您的领域过于复杂，无法在单个单体代码库中开发和维护。
如果您的业务领域具有清晰的功能边界，并且可以拆分为子领域。
如果您有多个团队将并行处理该解决方案。
当您需要早期降低复杂度时。并且如果您正在考虑将应用程序迁移到微服务系统。

虽然所有这些也都适合微服务解决方案（将在下一节讨论），但对于大多数项目而言，模块化解决方案比微服务更合适。特别是如果您不需要技术多样性、独立部署和扩展服务以及以容错系统同时服务过多用户，模块化单体应用程序将是更好的选择，以避免处理微服务系统的复杂性。此外，当您有一个小团队可以专注于构建功能而不花费时间管理分布式架构的复杂性时，从精简架构开始更好。另一个优点是，模块化单体避免了微服务固有的网络延迟和通信开销，因此调试和监控更容易，因为所有模块都在单个应用程序中运行。总之，如果您预见到您的应用程序未来可能需要微服务架构，模块化单体是一个很好的起点。

为现在而构建，为明天而扩展

即使您考虑构建微服务架构，通常也建议先从单体模块化开始，一旦您的业务和模块边界更加稳定，再迁移到微服务。

微服务解决方案模板

ABP的微服务启动模板包含多个服务、API网关和应用程序，它们彼此之间紧密集成，准备好成为您微服务系统的绝佳基础解决方案。在下图中，您可以看到一个总体示意图，展示了解决方案的主要组件（这些组件会根据您创建解决方案时的选项而有所不同）：

何时应使用微服务解决方案模板？

在以下情况下，您可以考虑构建微服务系统：

如果您的领域过于复杂，无法在单个单体代码库中开发和维护。
如果您的业务领域可以拆分为子领域。
如果您有多个团队将并行处理该解决方案。
如果您需要独立地开发、测试、部署和扩展服务。
如果您需要使用多种技术栈，因此，一些服务可以用.NET构建，其他可以用Java、Python等构建...
如果您需要以高可用和容错系统为过多用户并发提供服务。
如果您的公司具备DevOps知识和文化。如果您能够应对复杂的开发、构建、测试、部署和生产环境。

使用案例示例

电子商务平台：购物车、结账、库存和物流的独立服务。
流媒体服务：内容交付、用户偏好和推荐的模块。
SaaS平台：计费、用户账户和分析的独立服务。

结论

总之，ABP平台提供了多种针对不同架构需求定制的解决方案模板，包括分层应用程序、微服务和模块化开发。这些模板通过实施最佳实践和提供基本功能，为构建稳健的应用程序奠定了良好的基础。通过选择合适的模板，您可以简化开发过程，确保项目的可扩展性和可维护性。