Updated the ABP Studio vs. Aspire/AI/CRUD and ABP vs. clean architecture comparison articles to clarify positioning, tool overlap, and ABP platform tradeoffs. The copy now better distinguishes Studio, Suite, Low-Code, templates, and starter kits, and adds supporting references for Aspire, Radzen, and related frameworks.
# ABP Studio vs .NET Aspire, AI IDEs, and CRUD generators
You already have an IDE. You might already have Aspire. You might already have Cursor. None of that answers the ABP-shaped part of the week: new solution shape, module graph, run the tree, generate CRUD that matches the layers, ask an agent that has actually seen the modules.
You already have an IDE. You might already have Aspire. You might already have Cursor. The remaining question is how those tools handle ABP solution structure, modules, run profiles, and generated application code.
Teams compare [ABP Studio](https://abp.io/studio) with three neighbors. This is not an “IDE replacement” debate.
1. **.NET Aspire**, for describing distributed resources as code and watching them on a dashboard.
2. **Generic AI IDEs** (Cursor, GitHub Copilot, Claude Code), for repo-wide chat and file edits.
3. **CRUD scaffolders**, such as `dotnet aspnet-codegenerator` and visual Blazor builders (for example Radzen).
1. .NET Aspire, for describing distributed resources as code and watching them on a dashboard.
2. Generic AI IDEs (Cursor, GitHub Copilot, Claude Code), for repo-wide chat and file edits.
3. CRUD scaffolders, such as `dotnet aspnet-codegenerator` and visual Blazor builders (for example Radzen).
Those tools are good. Keep Visual Studio, Rider, or VS Code. Studio can [open the solution in them](https://abp.io/docs/latest/studio/solution-explorer). This article is about what only the ABP workflow covers: templates, module graph, Solution Runner, the **ABP Agent**, and [ABP Suite](https://abp.io/suite) (including **React**).
Those tools are good. Keep Visual Studio, Rider, or VS Code. Studio can [open the solution in them](https://abp.io/docs/latest/studio/solution-explorer). This article is about what the ABP workflow brings together in one environment: templates, module graph, Solution Runner (Studio’s tool for starting, stopping, and inspecting applications), the ABP Agent, and [ABP Suite](https://abp.io/suite) (including React).
## TL;DR
Choose **ABP Studio** when the work is ABP: solution shape, module graph, Solution Runner, AI Agent, and Suite CRUD (including React on modern solutions).
Choose ABP Studio when the work is ABP: solution shape, module graph, Solution Runner, AI Agent, and Suite CRUD (including React on modern solutions).
Keep **Visual Studio, Rider, or VS Code** beside it for refactor, tests, and language services.
Keep Visual Studio, Rider, or VS Code beside it for refactor, tests, and language services.
Add **.NET Aspire** when you want resource-as-code and the Aspire dashboard. Studio does not forbid it; microservice templates can wire Aspire in.
Add .NET Aspire when you want resource-as-code and the Aspire dashboard. Studio does not forbid it; microservice templates can wire Aspire in.
Use a **generic AI IDE** as an extra editor if the team already lives there. Prefer the ABP Agent when the change needs modules, migrations, proxies, or live run telemetry.
Use a generic AI IDE as an extra editor if the team already lives there. Prefer the ABP Agent when the change needs modules, migrations, proxies, or live run telemetry.
Tables in this article follow [official ABP documentation](https://abp.io/docs/latest).
## If the bottleneck is ABP, not the C# file
Studio is the recommended choice when your team is (or will be) on the ABP Platform and you want one place to:
Studio may be a suitable choice when your team is (or will be) on the ABP Platform and you want one place to:
- Scaffold production templates (including **React Modern** and Classic MVC / Blazor / Angular).
- Run many services, containers, and UIs from a [Solution Runner](https://abp.io/docs/latest/studio/running-applications) profile.
- Ask, plan, and **implement with AI** against modules, packages, migrations, and live telemetry.
- Generate layered CRUD with **ABP Suite** for MVC, Blazor, Angular, and **React**.
- Scaffold production templates (including React Modern and Classic MVC / Blazor / Angular).
- Run many services, containers, and UIs from a [Solution Runner](https://abp.io/docs/latest/studio/running-applications) profile (the set of applications and services started together).
- Ask, plan, and implement with AI against modules, packages, migrations, and live telemetry.
- Generate layered CRUD with ABP Suite for MVC, Blazor, Angular, and React.
If you only need a general editor, keep using your IDE. If you only need container orchestration and OpenTelemetry locally, Aspire may already be on the machine. Add Studio when the **solution graph and ABP conventions** are the bottleneck, not the C# file.
If you only need a general editor, keep using your IDE. If you only need container orchestration and OpenTelemetry locally, Aspire may already be on the machine. Add Studio when the solution graph and ABP conventions are the bottleneck, not the C# file.
## What actually sits next to Studio
| Capability | **ABP Studio + Agent** | .NET Aspire | General AI IDEs (Cursor, Copilot, Claude Code, …) | Visual Studio / Rider / VS Code |
| Capability | ABP Studio + Agent | .NET Aspire | General AI IDEs (Cursor, Copilot, Claude Code, …) | Visual Studio / Rider / VS Code |
|---|---|---|---|---|
| Role | ABP solution lifecycle + **AI coding in context** | Cloud-native orchestration, service discovery, dashboard | Repo-wide AI edit / chat / agents | General-purpose IDE |
| Role | ABP solution lifecycle + AI coding in context | Cloud-native orchestration, service discovery, dashboard | Repo-wide AI edit / chat / agents | General-purpose IDE |
| ABP / DDD structure in context | Solution, modules, packages, run profiles in the [agent system context](https://abp.io/docs/latest/studio/ai-agent) | Unaware of ABP modules | Files and text; no ABP module graph | Solution explorer of projects, not ABP modules |
| ABP-shaped artifacts | Suite generates entity, app service, DTOs, repository, and UI; Agent follows those module conventions | No | Generic C# unless you prompt every ABP convention | Language services only |
| Production ABP templates | Layered, modular, microservice; Modern React or Classic UIs | Minimal host templates for Aspire | None | `dotnet new` / ABP CLI if you add it |
| AI that can build, migrate, generate proxies | Agent mode: files, shell, [Studio tools](https://abp.io/docs/latest/studio/ai-agent-built-in-capabilities) (`dotnet_build`, `start_applications`, `generate_csharp_proxies`, `get_exceptions`, …), MCP | Not an ABP coding agent | Shell-wrapped `dotnet` if you teach it | Copilot in the editor (generic) |
| Kubernetes | Studio Kubernetes integration for ABP solutions | Publish / deploy story for Aspire apps | No | No (unless you add tools) |
| Code edit / refactor | Agent writes code; **Open with** your IDE for deep refactor | Not an editor | Strong | Strongest language tooling |
| Use together? | Yes, open IDE from Studio; optional [Aspire integration](https://abp.io/docs/latest/solution-templates/microservice/aspire-integration) | Yes with ABP microservice template | Yes as an extra editor | Yes; Studio launches them |
| Code edit / refactor | Agent writes code; Open with your IDE for deep refactor | Not an editor | Strong | Strongest language tooling |
| Use together? | Yes, open IDE from Studio; optional Aspire integration | Yes with ABP microservice template | Yes as an extra editor | Yes; Studio launches them |
**How to read the table:** these tools stack. Studio does not replace Rider’s refactorings or Aspire’s resource model. It **does** replace “fifteen terminals, a wiki of ABP conventions, and an AI that has never seen a module.”
How to read the table: these tools stack. Studio does not replace Rider's refactorings or Aspire's resource model. Its differentiated value is the ABP-aware workflow across solution structure, modules, run profiles, and agent tools.
**Kubernetes.** Studio’s Kubernetes integration is for **developing against a cluster** (browse and health using service names from the run profile). It is not Helm, GitOps, or your production deploy pipeline.
Kubernetes. Studio’s Kubernetes integration is for developing against a cluster (browse and health using service names from the run profile). It is not Helm, GitOps, or your production deploy pipeline.
## The ABP Agent vs “just ask Cursor”
Cursor and Copilot are excellent at finishing a LINQ query or explaining a regex. That is not the argument.
Ask a generic AI IDE: “Add a Product entity, make it multi-tenant, add the EF Core migration, generate the React UI.” It will guess. It will invent a module boundary from filenames. You will spend the afternoon cleaning that up.
Ask a generic AI IDE: "Add a Product entity, make it multi-tenant, add the EF Core migration, generate the React UI." A generic AI IDE can work effectively when it has sufficient repository context and explicit project conventions. ABP Studio's differentiated value is that solution, module, run-profile, and telemetry context are available through first-class Studio capabilities. For cross-layer ABP changes, this can reduce the amount of context and manual coordination the developer must provide.
[ABP Studio AI Agent](https://abp.io/docs/latest/studio/ai-agent) is not a chat sidebar glued onto a text buffer. The session already has the solution, modules, packages, runnable apps, run profile, AI scope, and tools. [ABP Suite](https://abp.io/suite) is still the CRUD generator. The Agent is the one that can follow the module graph, add a migration, start the profile, and read the live exception instead of waiting for you to paste a log.
[ABP Studio AI Agent](https://abp.io/docs/latest/studio/ai-agent) is not limited to the currently open text buffer. The session can use the solution, modules, packages, runnable apps, run profile, AI scope, and enabled tools. [ABP Suite](https://abp.io/suite) remains the CRUD generator, while the Agent is designed to work with the module graph, add a migration, start the profile, and inspect live exceptions.
Modes:
- **Ask**, read-only answers. Can search ABP documentation.
- **Plan**, read-only implementation plans.
- **Agent**, read/write files, shell, add migrations, run Studio tools, MCP, update plan steps.
- Ask, read-only answers. Can search ABP documentation.
- Plan, read-only implementation plans.
- Agent, read/write files, shell, add migrations, run Studio tools, MCP, update plan steps.
The ABP Agent fits changes where module, solution, and runtime context should remain available throughout the work.
That is the difference versus a generic AI IDE:
| What you ask | ABP Agent | Generic AI IDE |
|---|---|---|
| “Add an app service following ABP layering” | Sees packages, module rules, and ABP docs as context | Infers from files you opened |
| “Why did this HTTP call fail?” | `get_requests` / `get_exceptions` / `get_logs` on the **running** profile | You paste a log or attach a debugger |
| “Add an app service following ABP layering” | Receives solution, module, and ABP documentation context through Studio | Works from the repository context and instructions provided to it |
| “Why did this HTTP call fail?” | `get_requests` / `get_exceptions` / `get_logs` on the running profile | You paste a log or attach a debugger |
| “Generate C# / Angular proxies” | First-class Studio tools | A shell command if the model guesses it |
| “Start the apps, then continue” | `start_applications` / `start_containers` | Terminal + wait |
| Scope | AI scopes limit which modules the agent may touch; `.abpignore` blocks secrets | `.cursorignore` / similar; no ABP module notion |
| Scope | AI scopes limit which modules the agent may touch; `.abpignore` blocks secrets | Works from the repository context and instructions provided to it |
You still review the diff. Agent mode is execution with a permission boundary, not unsupervised production deploys.
The [privacy boundary](https://abp.io/docs/latest/studio/ai-agent) is the session you give it: files, prompts, Studio tool output, attachments, and allowed URLs. [`.abpignore`](https://abp.io/docs/latest/studio/ai-agent-configuration) blocks secrets even when they sit inside an [AI scope](https://abp.io/docs/latest/studio/ai-agent). You pick a model from Studio’s catalog; shell and URL fetches wait on tool permissions.
The [privacy boundary](https://abp.io/docs/latest/studio/ai-agent) is the session you give it: files, prompts, Studio tool output, attachments, and allowed URLs. Privacy depends on the selected model, configured provider, accessible scope, and enabled tools. [`.abpignore`](https://abp.io/docs/latest/studio/ai-agent-configuration) prevents excluded files from entering the agent context.
## Why Aspire does not replace Studio (they stack)
[Solution Runner](https://abp.io/docs/latest/studio/running-applications) is how you run an ABP modular or microservice tree: profiles per team, folders for apps/gateways/services, C# hosts, CLI tasks (for example Angular), Docker containers, start/stop/build, browse, health, and live HTTP / exception / log / event views.
.NET Aspire is how many .NET teams describe **distributed resources as code** and watch them on a dashboard (OpenTelemetry, containers, connection strings). See Microsoft’s [Aspire overview](https://learn.microsoft.com/en-us/dotnet/aspire/).
.NET Aspire is how many .NET teams describe distributed resources as code and watch them on a dashboard (OpenTelemetry, containers, connection strings).
They overlap on “run many processes locally.” That is it. They do not overlap on **ABP solution templates, module install, Suite, or the ABP Agent**.
Their responsibilities overlap around local orchestration, but their primary scopes are different. Aspire focuses on distributed resource orchestration, while ABP Studio adds ABP solution templates, module workflows, Suite, and the ABP Agent.
You do not have to pick one. ABP microservice templates can enable Aspire so AppHost starts infrastructure and services; you can still use Studio’s runner and Agent. See [Aspire integration](https://abp.io/docs/latest/solution-templates/microservice/aspire-integration).
Pairing ABP Studio with Aspire works well when ABP solution workflows and distributed resource orchestration are both needed.
## Suite: a CRUD slice, not a pretty grid
[ABP Suite](https://abp.io/docs/latest/suite) generates a CRUD **slice of an ABP application** from an entity: domain type, repository, application service, migration, UI, tests, navigation properties, multi-tenant flag, localization keys.
[ABP Suite](https://abp.io/docs/latest/suite) generates a CRUD slice of an ABP application from an entity: domain type, repository, application service, migration, UI, tests, navigation properties, multi-tenant flag, localization keys.
| | **ABP Suite** | `dotnet aspnet-codegenerator` / EF scaffolding | Visual Blazor app builders (for example Radzen) |
| | ABP Suite | `dotnet aspnet-codegenerator` / EF scaffolding | Visual Blazor app builders (for example Radzen) |
|---|---|---|---|
| Output | Entity through application layer + UI + optional tests | Controllers, Razor Pages, Blazor CRUD, or Minimal API endpoints against a DbContext | Blazor UI + data wiring from a database or REST source |
| UI stacks | MVC, Blazor (Blazorise or MudBlazor, detected), Angular, and **React** (modern solutions) | MVC views, Razor Pages, and Blazor components. No Angular. No React. | Blazor only (Server, WebAssembly, Auto) |
| ABP permissions, tenancy, audit base classes | Options on the entity ([CRUD generation](https://abp.io/docs/latest/suite/generating-crud-page)) | No | No |
| Custom code on regenerate | [Customizable code](https://abp.io/docs/latest/suite/customizing-the-generated-code) hook points for MVC, Blazor, and Angular. React generated pages do not have those in-page hooks yet; regenerating overwrites the React page | Easy to overwrite | Varies by product; not ABP hook points |
| React UI | **Yes**, template-based (not AI) for modern React apps: list, search, paging, filter, export, create/edit, bulk delete, validation, permissions, localization, file upload, navigation properties, many-to-many, master-detail. Registers routes and menu | **No.** Official generators are `blazor`, `razorpage`, `view`, `controller`, `identity`, `minimalapi`. There is no React generator | **No.** Radzen Blazor Studio scaffolds Blazor (C# / Razor), not React |
| UI stacks | MVC, Blazor (Blazorise or MudBlazor, detected), Angular, and React (modern solutions) | MVC views, Razor Pages, and Blazor components. No Angular. No React. | Blazor only (Server, WebAssembly, Auto) |
| ABP permissions, tenancy, audit base classes | Options on the entity ([CRUD generation](https://abp.io/docs/latest/suite/generating-crud-page)) | Does not use ABP permission and tenancy conventions | Does not use ABP permission and tenancy conventions |
| Custom code on regenerate | Customizable code [hook points](https://abp.io/docs/latest/suite/customizing-the-generated-code) for MVC, Blazor, and Angular; React pages require extra care when regenerated | Often requires manually preserving custom changes | Varies by product |
| React UI | Yes, template-based CRUD for modern React apps, including search, paging, validation, permissions, localization, and navigation properties. Registers routes and menu | No React generator in the official scaffolding set (`blazor`, `razorpage`, `view`, `controller`, `identity`, `minimalapi`) | Blazor-focused rather than React-based |
Suite is the generator for every official web UI, including React. [ABP Agent](https://abp.io/docs/latest/studio/ai-agent) is the extra path when you want AI to evolve those pages, not a substitute for Suite React output.
Suite supports the official web UI stacks, including React. [ABP Agent](https://abp.io/docs/latest/studio/ai-agent) is an extra path when you want AI to evolve those pages, not a substitute for Suite React output.
Suite is a fit when generated CRUD should follow the application's ABP layers, conventions, and selected UI stack.
## When Studio is the right tool in the stack
Choose **ABP Studio** when the work is ABP: new solution shape, module graph, run profiles, Kubernetes-connected browse, Agent that can migrate and generate proxies, Suite for CRUD.
Choose ABP Studio when the work is ABP: new solution shape, module graph, run profiles, Kubernetes-connected browse, Agent that can migrate and generate proxies, Suite for CRUD.
Keep your IDE open beside it for refactor, tests, and language services. Studio expects that.
Keep **your IDE** open beside it for refactor, tests, and language services. Studio expects that.
Add Aspire when you want resource-as-code and the Aspire dashboard. Studio does not forbid it.
Add **Aspire** when you want resource-as-code and the Aspire dashboard. Studio does not forbid it.
Use a generic AI IDE as an extra editor if your team already lives there. Prefer Agent for ABP-structured changes so the model is not guessing module boundaries from filenames.
Use a **generic AI IDE** as an extra editor if your team already lives there. Prefer Agent for ABP-structured changes so the model is not guessing module boundaries from filenames.
Studio works best when ABP-specific solution workflows complement your existing IDE.
## FAQ
**We already run .NET Aspire (AppHost + dashboard). What does Studio still do that Aspire does not?**
Aspire models **resources** (projects, containers, connection strings, OpenTelemetry) as code. Studio models an **ABP solution**: modules, package install, production templates, Suite, Kubernetes browse for ABP services, and an agent that can migrate and generate proxies. They overlap only on “start many processes locally.” You can keep AppHost; microservice templates even [wire Aspire in](https://abp.io/docs/latest/solution-templates/microservice/aspire-integration). You do not delete Aspire to “switch to Studio.”
### We already run .NET Aspire (AppHost + dashboard). What does Studio still do that Aspire does not?
Aspire models resources (projects, containers, connection strings, OpenTelemetry) as code. Studio models an ABP solution: modules, package installation, production templates, Suite, Kubernetes browse for ABP services, and an agent that can migrate and generate proxies. Their responsibilities overlap around local orchestration, but their primary scopes are different. You can keep AppHost; microservice templates can integrate Aspire. You do not need to replace Aspire with Studio.
**If the team already uses Cursor or Copilot on the same repo, when is ABP Agent the better tool for a task?**
When the task needs **ABP structure or a live run**, not only a file edit: module/package scope, `generate_csharp_proxies` / `generate_angular_proxies`, `start_applications`, or `get_exceptions` / `get_requests` / `get_logs` against the [Solution Runner](https://abp.io/docs/latest/studio/running-applications) profile. Generic IDEs can shell `dotnet`; they do not have those as first-class Studio tools or an [AI scope](https://abp.io/docs/latest/studio/ai-agent) that is an ABP module graph. Use Copilot for language-local edits; use Agent when the change must respect modules and running services.
### If the team already uses Cursor or Copilot on the same repo, when is ABP Agent the better tool for a task?
When the task needs ABP structure or a live run, not only a file edit: module/package scope, `generate_csharp_proxies` / `generate_angular_proxies`, `start_applications`, or `get_exceptions` / `get_requests` / `get_logs` against the [Solution Runner](https://abp.io/docs/latest/studio/running-applications) profile. Generic IDEs can work in the same repository when given the relevant context and conventions. Agent provides first-class access to module, run-profile, and Studio tool context for changes that coordinate ABP modules and running services.
**After Suite generates React CRUD, how do we change the page without the next generate wiping us?**
For **MVC, Blazor, and Angular**, use Suite’s [customizable code](https://abp.io/docs/latest/suite/customizing-the-generated-code) hook points (and template edits if you customize generators). Regeneration keeps those blocks. **React** generated pages do not have those in-page hooks yet, so regenerating overwrites the React page. Keep extra React UI in files Suite does not generate, or evolve the page with [ABP Agent](https://abp.io/docs/latest/studio/ai-agent). Suite React generation itself is **template-based, not AI**.
### After Suite generates React CRUD, how should we customize the page?
For MVC, Blazor, and Angular, use Suite’s [customizable code](https://abp.io/docs/latest/suite/customizing-the-generated-code) hook points. React pages require extra care when regenerated, so keep additional React UI in files Suite does not generate or evolve it with [ABP Agent](https://abp.io/docs/latest/studio/ai-agent). Suite React generation itself is template-based, not AI.
**Can Agent start the microservice profile, then use real HTTP/exception data in the same session?**
Yes, in **Agent** mode with a run profile: tools include `start_applications` / `start_containers` and then `get_requests`, `get_exceptions`, `get_logs`, `get_events` ([built-in capabilities](https://abp.io/docs/latest/studio/ai-agent-built-in-capabilities)). Ask/Plan cannot mutate or start apps. If nothing is running, those telemetry tools have nothing to read. That is why “AI that sees production-like local traffic” is a Studio and Runner loop, not a chat sidebar.
### Can Agent start the microservice profile, then use real HTTP/exception data in the same session?
Yes, in Agent mode with a run profile: tools include `start_applications` / `start_containers` and then `get_requests`, `get_exceptions`, `get_logs`, `get_events` ([built-in capabilities](https://abp.io/docs/latest/studio/ai-agent-built-in-capabilities)). Ask/Plan cannot mutate or start apps. If nothing is running, those telemetry tools have nothing to read. That is why “AI that sees production-like local traffic” is a Studio and Runner loop, not a chat sidebar.
**Does Studio Kubernetes integration replace Helm, GitOps, or our cluster deploy pipeline?**
No. It is for **developing against a cluster** (browse/health using Kubernetes service names from the run profile, manage connected services). Aspire’s publish story and your CI remain how you ship. Do not treat the Studio K8s panel as the production deployment product.
### Does Studio Kubernetes integration replace Helm, GitOps, or our cluster deploy pipeline?
No. It is for developing against a cluster (browse/health using Kubernetes service names from the run profile, manage connected services). Aspire’s publish story and your CI remain how you ship. Do not treat the Studio K8s panel as the production deployment product.
**Can one developer live in Rider and another in VS Code while sharing the same Studio solution?**
### Can one developer live in Rider and another in VS Code while sharing the same Studio solution?
Yes. Studio holds solution/run-profile metadata; [Open with](https://abp.io/docs/latest/studio/solution-explorer) launches whatever IDE is installed. Run profiles and Agent sessions are not tied to a single editor vendor. The constraint is ABP Studio itself on the machine, not a mandate to abandon Rider or VS.
@ -6,87 +6,99 @@ Search “ABP vs …” and you will land on pages written by kits and tenancy l
You are choosing among four shapes:
1. **Build it yourself** on ASP.NET Core, often with a tenancy library such as Finbuckle.MultiTenant.
2. **A Clean Architecture template** (Jason Taylor, Ardalis) that gives you folders, layers, and a sample feature.
3. **A starter kit** that copies a snapshot of production modules into your repo (fullstackhero, Brick, and similar kits).
4. **A maintained application platform.** Architecture, infrastructure, modules, and tools that keep moving.
1. Build it yourself on ASP.NET Core, often with a tenancy library such as Finbuckle.MultiTenant.
2. A Clean Architecture template (Jason Taylor, Ardalis) that gives you folders, layers, and a sample feature.
3. A starter kit that copies a snapshot of production modules into your repo (fullstackhero, Brick, and similar kits).
4. A maintained application platform. Architecture, infrastructure, modules, and tools that keep moving.
[ABP](https://abp.io) is the fourth. The rest of this article is about the things teams actually pay for later: multi-tenancy, identity, permissions, modularity, UI (including **React**), and a path from modular monolith to microservices.
ABP competes across several decision categories rather than against one uniform product set. Some teams compare it with Clean Architecture and DDD references or starter kits because they prefer to own and assemble the application foundation themselves. Others evaluate .NET application and service frameworks such as ServiceStack, model-driven RAD platforms such as DevExpress XAF, or cross-stack SaaS platforms and starter kits. Existing ASP.NET Boilerplate applications are usually a migration and adoption consideration rather than a same-generation alternative. The table below focuses on the architecture and application-foundation decision; these other categories can still enter the same broader technology discussion.
[ABP](https://abp.io) takes the application-platform approach. The rest of this article is about the things teams evaluate later: multi-tenancy, identity, permissions, modularity, UI (including React), and a path from modular monolith (one deployable application organized into independent modules) to microservices.
## TL;DR
Choose **ABP** when you are shipping a long-lived, multi-tenant, modular .NET product and want a maintained platform: tenancy, identity, modules, official UIs (including React), and Studio / Suite on the same stack.
Choose ABP when you are shipping a long-lived, multi-tenant, modular .NET product and want a maintained platform: tenancy, identity, modules, official UIs (including React), and Studio / Suite on the same stack.
Choose a **Clean Architecture template** (Jason Taylor, Ardalis) when the goal is to own every architectural decision from a well-named skeleton.
Choose a Clean Architecture template (Jason Taylor, Ardalis) when the goal is to own every architectural decision from a well-named skeleton.
Choose a **starter kit** (fullstackhero, Brick, and similar) when you prefer a copy of modules in your repo on day one and you are willing to maintain that snapshot.
Choose a starter kit (fullstackhero, Brick, and similar) when you prefer a copy of modules in your repo on day one and you are willing to maintain that snapshot.
Choose **Finbuckle** (or custom tenant middleware) when tenant *resolution* is the only extra you need on an app you already own. That is not a substitute for ABP’s tenancy plus identity, permissions, and audit.
Choose Finbuckle (or custom tenant middleware) when tenant resolution is the only additional capability you need on an app you already own. ABP also connects tenancy with application concerns such as identity, permissions, and audit.
Tables in this article follow [official ABP documentation](https://abp.io/docs/latest).
## This is for the long haul
ABP is the recommended choice when you are building a **long-lived, multi-tenant, modular .NET product**. B2B SaaS. Line of business. A platform several teams will still be extending in a few years.
ABP is the recommended choice when you are building a long-lived, multi-tenant, modular .NET product. B2B SaaS. Line of business. A platform several teams will still be extending in a few years.
- Official UI options that match your team: **React**, Angular, Blazor, MVC, MAUI, or React Native.
- Official UI options that match your team: React, Angular, Blazor, MVC, MAUI, or React Native.
- A way to add pre-built modules and, later, split a module into a service without rewriting the application code.
- Tooling (Studio, Suite, CLI) and, if you need it, commercial modules and support, without leaving the same platform.
Yes, ABP is opinionated. The first two weeks feel like extra rules. Modules. Application services. The unit of work. You will hit a DI error you did not expect. Then you need to extract a microservice and the contracts are already there. That is the point of the rules. They become **team-wide standards** so the next project does not invent a second way to do the same thing.
Yes, ABP is opinionated. The initial learning cost is real: teams need to understand modules, application services, and unit of work conventions before those conventions become productive. Then, when a module needs to become a microservice, the contracts are already there. The conventions become team-wide standards so the next project does not invent a second way to do the same thing.
## Four shapes. One table.
| What you get | Maintained framework + modules + templates + tooling | Empty host and libraries you assemble | Layered/CQRS skeleton + a sample feature | A copy of modules in your repo on day one |
| Multi-tenancy | Native: [single database, database-per-tenant, or hybrid](https://abp.io/docs/latest/framework/architecture/multi-tenancy); Identity and OpenIddict wired for tenants | You design isolation, filters, and cache keys, or add a library such as Finbuckle.MultiTenant | Not included | Often via a tenancy library you still own end-to-end |
| Identity, permissions, audit | Application modules + automatic data filters, [audit logging](https://abp.io/docs/latest/framework/infrastructure/audit-logging), permission system | You compose Identity, policies, and audit yourself | Identity sample at most | Bundled in the kit; you maintain the fork |
| Modularity | First-class [module system](https://abp.io/docs/latest/framework/architecture/modularity); install/uninstall packages | You invent module boundaries | Folders and layers, not a product module catalog | Modular folders; upgrades are merge/cherry-pick |
| Multi-tenancy | Native: [single database, database-per-tenant, or hybrid](https://abp.io/docs/latest/framework/architecture/multi-tenancy); identity and authentication/token infrastructure wired for tenants | You design isolation, filters, and cache keys, or add a library such as Finbuckle.MultiTenant | Not included | Often via a tenancy library you still own end-to-end |
| Identity, permissions, audit | Application modules + automatic tenant-data filtering, [audit logging](https://abp.io/docs/latest/framework/infrastructure/audit-logging), permission system | You compose Identity, policies, and audit yourself | Identity sample at most | Bundled in the kit; you maintain the fork |
| Modularity | First-class [module system](https://abp.io/docs/latest/framework/architecture/modularity/basics); install/uninstall packages | You invent module boundaries | Folders and layers, not a product module catalog | Modular folders; upgrades are merge/cherry-pick |
| UI | [React (Modern)](https://abp.io/docs/latest/framework/ui/react), MVC, Blazor, Angular, [React Native](https://abp.io/docs/latest/framework/ui/react-native), [MAUI](https://abp.io/docs/latest/framework/ui/maui) | You pick and integrate | Template-specific (often Angular/React/API) | Kit-specific (often one SPA) |
| Monolith → microservices | Same application contracts; HTTP/C# proxies replace in-process calls | You design the split | You design the split | Extract-a-module if the kit allows it |
| Tooling | [ABP Studio](https://abp.io/studio) (including AI Agent), [ABP Suite](https://abp.io/suite), CLI | `dotnet` CLI and your IDE | Template CLI + IDE | Kit CLI / Aspire host, varies |
| How it evolves | NuGet upgrades for the framework and modules, plus documented migrations | You upgrade every library | You copy the next template over your tree | You merge upstream into source you already customized |
| Support | Open-source core plus commercial extras and vendor support | Your team | Community | Community |
**How to read the table:** templates teach structure. Starter kits give you a snapshot you own. ABP is the **platform** those snapshots are trying to approximate. It stays current, documented, and supported with tooling. Names in the headers are examples of the category, not a review of every repository.
ABP may be a suitable fit when the application needs architecture, infrastructure modules, and development tooling to remain integrated and maintainable as the product grows.
How to read the table: templates teach structure. Starter kits give you a snapshot you own. ABP combines application architecture, infrastructure modules, and development tooling in one platform. Names in the headers are examples of the category, not a review of every repository.
**Identity, permissions, and audit.** ABP ships these as application modules: permission UI, automatic data filters, and audit logging. On plain ASP.NET Core you compose Identity, policies, and audit yourself. A Clean Architecture template usually stops at an Identity sample. A starter kit may bundle them; you then maintain that copy.
Identity, permissions, and audit. ABP ships these as application modules: permission UI, automatic filtering of tenant data, and audit logging. On plain ASP.NET Core you compose Identity, policies, and audit yourself. A Clean Architecture template usually stops at an Identity sample. A starter kit may bundle them; you then maintain that copy.
**How the stack evolves.** Remember the last time you pulled a starter-kit upgrade six months in? Identity and tenancy already have your customizations. You sit in merge conflicts across dozens of files you now own. That is not a platform upgrade. That is a lost weekend.
How the stack evolves. When a customized starter kit is updated, identity and tenancy code may already contain local changes. Reconciling those changes across the files you now own can add significant maintenance work. That is a different upgrade model from updating framework packages.
ABP does not work that way. Framework and modules move as NuGet packages, with documented migrations. A Clean Architecture template’s next version is something you copy forward. A kit’s next version is a merge into the snapshot you already changed.
ABP uses framework and module packages, together with documented migrations. A Clean Architecture template’s next version is something you copy forward. A kit’s next version is reconciled with the snapshot you already changed.
## Let’s be honest: what are you actually downloading?
### The months-of-plumbing trap
### What you build yourself
ASP.NET Core is phenomenal. It is a foundation, not a house. Build from scratch and the first months are tenant resolvers, permission filters, audit logs, job plumbing, module boundaries. Again.
ASP.NET Core is phenomenal. It is a foundation, not a complete application platform. Building from scratch gives teams maximum control, but also leaves tenant resolution, permission checks, audit logs, job plumbing, and module boundaries to the team.
That work is legitimate if the architecture is unique. For a standard business product, it is infrastructure before the first domain feature.
ABP sits **on** ASP.NET Core. You keep the Microsoft stack. You stop writing the boring parts. See [Why ABP Platform](https://abp.io/docs/latest/others/why-abp-platform).
ABP sits on ASP.NET Core. You keep the Microsoft stack. ABP provides established conventions and modules for teams that prefer those decisions to be part of the platform. See [Why ABP Platform](https://abp.io/docs/latest/others/why-abp-platform).
ABP suits teams that want application infrastructure to remain integrated with the product as it grows.
### Clean Architecture templates
This category includes the templates most often compared with ABP: Jason Taylor’s Clean Architecture template and Ardalis’s Clean Architecture template. They are a good **classroom and a clean slate**. They do not ship multi-tenancy with three database strategies, a module catalog, Suite-generated layered CRUD, or a desktop environment that understands ABP modules.
This category includes the templates most often compared with ABP: Jason Taylor’s Clean Architecture template and Ardalis’s Clean Architecture template. They provide a good classroom and a clean slate. Their focus is architectural structure and ownership rather than a built-in application module catalog or ABP-specific tooling.
Choose a template when the goal is to **own every architectural decision** from an empty, well-named skeleton. Choose ABP when the goal is to **ship the product** on a skeleton that already includes the product concerns.
Choose a Clean Architecture template when architectural ownership and a focused starting point matter most.
ABP is a fit when architectural conventions and application modules need to evolve together.
### Starter kits
A starter kit copies identity, tenancy, auditing, and a few domain modules into your repository. You own every line. That is a real preference for some teams.
The kits that already publish “ABP vs …” pages live here. **fullstackhero** is a copy-and-own MIT kit (identity, tenancy, React admin, modules in your repo). Commercial SaaS kits such as **Brick** sit in the same category when they ship as a snapshot you own. Day one looks finished. Month six is when you find out who maintains identity.
Starter kits are another common option in this decision. fullstackhero is a copy-and-own MIT kit (identity, tenancy, React admin, modules in your repo). Other starter kits, such as Brick, can also provide a prebuilt starting point; the exact features, ownership model, and update process depend on the kit. They can provide a fast starting point, but long-term maintenance depends on how each kit handles updates to customized code.
With ABP, framework and module updates are distributed through packages and documented migrations. With a kit, teams have direct ownership of the source, while updates may require reconciling local changes with upstream code. These are different maintenance models.
With ABP, infrastructure arrives as package upgrades, Studio workflows, and documented migrations. With a kit, it arrives as commits you merge into code you already customized. The lost-weekend merge is the cost of owning every line.
Choose a starter kit when an existing set of application features and direct source ownership can accelerate your team.
ABP’s open-source core is yours to use; your business code lives in your repo. There is no separate proprietary runtime for that core. Commercial extras (themes, Pro modules, Suite, support) are optional layers on the same platform, not a rewrite.
Choose ABP when you want those application concerns, modules, and tooling to evolve as part of a maintained platform. ABP’s open-source core is yours to use; your business code lives in your repo. There is no separate proprietary runtime for that core. Commercial extras (themes, Pro modules, Suite, support) are optional layers on the same platform, not a rewrite.
Package-based framework and module updates may suit teams that prefer them to reconciling changes in an owned source snapshot.
## If you last looked a year ago: React is official
@ -94,11 +106,11 @@ This is easy to miss if you last looked at ABP a year ago.
Official UI options ([ABP UI](https://abp.io/docs/latest/framework/ui)):
- **React**, in the [Modern template system](https://abp.io/docs/latest/solution-templates/modern-vs-classic) (ABP Studio or `abp new --modern`).
- **MVC / Razor Pages**, **Blazor** (WebAssembly, Server, WebApp), and **Angular**, on Classic templates.
- **React Native** and **MAUI** for mobile / hybrid.
- React, in the [Modern template system](https://abp.io/docs/latest/solution-templates/modern-vs-classic) (ABP Studio or `abp new --modern`).
- MVC / Razor Pages, Blazor (WebAssembly, Server, WebApp), and Angular, on Classic templates.
- React Native and MAUI for mobile / hybrid.
[Modern vs Classic](https://abp.io/docs/latest/solution-templates/modern-vs-classic): **Classic is not a deprecated track.** It is the actively supported family with the broadest UI matrix (MVC, Angular, Blazor, MAUI) and the template-first Studio flow. **Modern** is the newer architecture-first Studio flow, React (or no UI), and the Admin Console / Low-Code path. Choose Classic when the team’s UI is MVC, Angular, or Blazor. Choose Modern when the web UI is React.
[Modern vs Classic](https://abp.io/docs/latest/solution-templates/modern-vs-classic): Classic is not a deprecated track. It is the actively supported family with the broadest UI matrix (MVC, Angular, Blazor, MAUI) and the template-first Studio flow. Modern is the newer architecture-first Studio flow, React (or no UI), and the Admin Console / Low-Code path (metadata-driven screens configured through a designer). Choose Classic when the team’s UI is MVC, Angular, or Blazor. Choose Modern when the web UI is React.
One backend, the UI your team already knows.
@ -107,30 +119,34 @@ One backend, the UI your team already knows.
ABP treats tenancy as infrastructure, not a feature you bolt on:
- Current tenant is resolved per request.
- Entities implementing `IMultiTenant`are **automatically filtered**; new records get a `TenantId`.
- You can use **one database for all tenants**, **one database per tenant**, or a **hybrid**.
- Entities implementing `IMultiTenant`(ABP’s contract for separating tenant-owned data) are automatically filtered; new records get a `TenantId` identifying the tenant.
- You can use one database for all tenants, one database per tenant, or a hybrid.
That isolation also applies to cache and related concerns so business code stays mostly tenancy-agnostic. Details: [Multi-Tenancy](https://abp.io/docs/latest/framework/architecture/multi-tenancy).
A tenancy library on raw ASP.NET Core, including **Finbuckle.MultiTenant**, can resolve the tenant. It does not automatically give you permission UI, audit, jobs, Identity/OpenIddict tenant wiring, and module installs on the same model. That is the platform difference. Pages titled “Finbuckle vs ABP vs custom” are answering a library question. This article is answering the application-platform question.
A tenancy library on raw ASP.NET Core, including Finbuckle.MultiTenant, can resolve the tenant. It does not automatically give you permission UI, audit, jobs, Identity/OpenIddict authentication and token wiring for tenants, and module installs on the same model. That is the platform difference. Pages titled “Finbuckle vs ABP vs custom” are answering a library question. This article is answering the application-platform question.
ABP is worth considering when tenancy needs to stay connected to identity, permissions, data filtering, and the rest of the application model.
## Modularity that can become microservices
ABP modules are real packages (domain, application, HTTP API, UI) with documented dependency rules. You can start with a [modular monolith](https://abp.io/architecture/modular-monolith) and later replace in-process calls with HTTP using the same application service contracts and [client proxies](https://abp.io/docs/latest/framework/api-development/dynamic-csharp-clients).
ABP modules are real packages (domain, application, HTTP API, UI) with documented dependency rules. You can start with a [modular monolith](https://abp.io/architecture/modular-monolith) and later replace in-process calls with HTTP using the same application service contracts and [client proxies](https://abp.io/docs/latest/framework/api-development/dynamic-csharp-clients) (typed clients that call application services over HTTP).
That path is the point. You do not throw away the monolith to “do microservices”; you **change the hosting** of a module that already had a boundary.
That path is the point. You do not throw away the monolith to “do microservices”; you change the hosting of a module that already had a boundary.
This approach fits teams that want modular boundaries to support both a modular monolith and a later service split.
## ABP Low-Code: admin screens inside the same app
[ABP Low-Code](https://abp.io/docs/latest/low-code) is a module **in your ABP application** (Team license or higher). You model entities, pages, forms, permissions, and scripts in the Admin Console. The runtime uses that metadata in the same app, with the same identity, audit, and EF Core model. There is no separate low-code database.
[ABP Low-Code](https://abp.io/docs/latest/low-code) is a module in your ABP application (Team license or higher). You model entities, pages, forms, permissions, and scripts in the Admin Console. The runtime uses that metadata in the same app, with the same identity, audit, and EF Core model. There is no separate low-code database.
Designer, [Studio AI Agent](https://abp.io/docs/latest/studio/ai-agent), and hand-written C# / Script API land on one model.
The documented runtime UI is React. You can still keep MVC, Razor Pages, Angular, or Blazor as the main UI and host the React Low-Code runtime beside it ([non-React integration](https://abp.io/docs/latest/low-code/non-react-ui-integration)).
Docs still label the system **Preview** (APIs and designer may change before GA). That is a maturity label, not a missing product.
Docs still label the system Preview (APIs and designer may change before GA). That is a maturity label, not a missing product.
| | **ABP Low-Code** | External low-code platform | Hand-written CRUD every time |
| | ABP Low-Code | External low-code platform | Hand-written CRUD every time |
|---|---|---|---|
| Where it runs | Inside your ABP app | Separate product / runtime | Your repo |
| Data and identity | Same database and ABP authorization | Often a parallel model | Whatever you build |
@ -140,47 +156,50 @@ Docs still label the system **Preview** (APIs and designer may change before GA)
Studio’s *new-solution wizard step* is omitted for microservice architecture and when MongoDB is selected, because runtime-managed tables use EF Core. Layered and modular-monolith EF Core solutions are the documented enablement path today.
Use Low-Code for the **admin CRUD and metadata-driven screens**. Keep distinctive product UX in normal ABP UI, including Suite-generated React CRUD on modern solutions.
Use Low-Code for the admin CRUD and metadata-driven screens. Keep distinctive product UX in normal ABP UI, including Suite-generated React CRUD on modern solutions.
## When this is the right call
Pick **ABP** when:
Pick ABP when:
- The product will have tenants, roles, audit, and more than one team.
- You want React *or* Blazor *or* Angular *or* MVC on a shared backend.
- You expect to grow from modular monolith to services without a rewrite.
- You want Studio, Suite, and (optionally) Low-Code on the same stack.
A Clean Architecture template is a solid start when you are **learning the architecture** or assembling a thin service that will never need the SaaS surface.
A Clean Architecture template is a solid choice when architectural ownership and a focused starting point matter most.
A starter kit is a preference for **copy-and-own snapshots** (fullstackhero, Brick, and similar). ABP is the preference for a **maintained platform** and vendor-backed extras when you want them.
A starter kit is a solid choice when an existing set of application features and direct source ownership can accelerate your team. ABP is a better fit when those application concerns, modules, and tooling should evolve as part of a maintained platform.
ASP.NET Boilerplate is the predecessor, not a same-generation starter kit. If that is the comparison, it is a **migration** to the current ABP platform, not a fork-and-own kit decision.
ASP.NET Boilerplate is the predecessor, not a same-generation starter kit. If that is the comparison, it is a migration to the current ABP platform, not a fork-and-own kit decision.
DevExpress XAF and similar commercial “model → UI” frameworks are a different buyer conversation (RAD on a vendor UI model). ABP stays on open ASP.NET Core with the UI framework you choose. If that is your comparison, start from the table above and the [framework page](https://abp.io/framework).
DevExpress XAF and similar commercial frameworks follow a model-driven RAD approach built around a vendor UI ecosystem. That approach can reduce application boilerplate and accelerate internal business applications, while also placing the application’s model and much of its UI experience within DevExpress conventions and controls. ABP is an application platform on ASP.NET Core, with an open-source core, modular architecture, and multiple UI options. It gives teams more direct control over the application layers and frontend choices, including MVC, Blazor, Angular, and React, while supporting a modular-monolith-to-microservices path. XAF may be the better fit when the priority is delivering a model-driven business application quickly within the DevExpress ecosystem. ABP may be the better fit when the product needs ASP.NET Core, a more customized frontend experience, multiple client options, or a modular architecture that can evolve toward services.
## FAQ
**If we stop paying for commercial extras, or we leave ABP later, is the app a black box?**
### Is ABP free or commercial?
ABP Framework has an open-source core. Some themes, modules, generators, Studio capabilities, support, and other commercial offerings require an appropriate commercial license. Exact availability depends on the product and license level.
### If we stop paying for commercial extras, or we leave ABP later, is the app a black box?
No. The application is still ASP.NET Core, your C#, and EF Core (or MongoDB). The [open-source framework](https://abp.io/docs/latest/others/why-abp-platform) stays in the solution as packages you already reference. Leaving ABP means replacing those packages the way you would replace any framework, not extracting code from a closed runtime. Suite output is source in your repo. Commercial modules, themes, and Suite itself are optional layers; dropping them does not delete your domain.
**If we already have a Clean Architecture or starter-kit repo (Jason Taylor, Ardalis, fullstackhero, Brick), can we “just add ABP” like a NuGet?**
No. ABP’s module pipeline, interceptors, data filters, and startup conventions assume it **is** the host. Teams adopt ABP on a new solution (or plan a migration), they do not drop `Volo.Abp.*` onto an existing CA template and keep the old composition root unchanged. That is the real cost versus a tenancy library you add to code you already own. See [Why ABP Platform](https://abp.io/docs/latest/others/why-abp-platform).
### If we already have a Clean Architecture or starter-kit repo (Jason Taylor, Ardalis, fullstackhero, Brick), can we “just add ABP” like a NuGet?
No. ABP’s module pipeline, interceptors, automatic tenant-data filters (which limit queries to the current tenant), and startup conventions assume it is the host. Teams adopt ABP on a new solution (or plan a migration), they do not drop `Volo.Abp.*` onto an existing CA template and keep the old composition root unchanged. That is the real cost versus a tenancy library you add to code you already own. See [Why ABP Platform](https://abp.io/docs/latest/others/why-abp-platform).
**We already use Finbuckle (or custom tenant middleware). What does ABP tenancy still do that that library does not?**
A tenancy library resolves *who the tenant is*. ABP also **isolates queries and inserts** (`IMultiTenant` data filters), wires Identity and OpenIddict for tenants, and applies the same tenant context to cache and related infrastructure. That covers [single database, database-per-tenant, or hybrid](https://abp.io/docs/latest/framework/architecture/multi-tenancy). Permissions, audit, and jobs then run inside that model instead of each being a separate integration project.
### We already use Finbuckle (or custom tenant middleware). What does ABP tenancy still do that that library does not?
A tenancy library resolves *who the tenant is*. ABP also isolates queries and inserts (`IMultiTenant` data filters), wires Identity and OpenIddict for tenants, and applies the same tenant context to cache and related infrastructure. That covers [single database, database-per-tenant, or hybrid](https://abp.io/docs/latest/framework/architecture/multi-tenancy). Permissions, audit, and jobs then run inside that model instead of each being a separate integration project.
**If we start Modern/React, can the same backend later serve a second UI (public MVC, partner Blazor, mobile)?**
Yes. Application services and HTTP APIs are UI-agnostic. [Official UIs](https://abp.io/docs/latest/framework/ui) (React, Angular, Blazor, MVC, React Native, MAUI) are hosts on that backend. You choose Modern vs Classic at **solution creation** for the primary web app; extra clients consume the same APIs. You do not rewrite domain or application layers to add a second frontend.
### If we start Modern/React, can the same backend later serve a second UI (public MVC, partner Blazor, mobile)?
Yes. Application services and HTTP APIs are UI-agnostic. [Official UIs](https://abp.io/docs/latest/framework/ui) (React, Angular, Blazor, MVC, React Native, MAUI) are hosts on that backend. You choose Modern vs Classic at solution creation for the primary web app; extra clients consume the same APIs. You do not rewrite domain or application layers to add a second frontend.
**When we split a module into a microservice, do we rewrite application services as controllers?**
Not as the default path. Module contracts stay; in-process calls become HTTP (or messaging) via [client proxies](https://abp.io/docs/latest/framework/api-development/dynamic-csharp-clients) against the same application-service interfaces. You change **hosting**, not the feature’s application API. That is the comparison point versus a starter kit whose “modules” are folders with no proxy story.
### When we split a module into a microservice, do we rewrite application services as controllers?
Not as the default path. Module contracts stay; in-process calls become HTTP (or messaging) via [client proxies](https://abp.io/docs/latest/framework/api-development/dynamic-csharp-clients) against the same application-service interfaces. You change hosting, not the feature’s application API. That is the comparison point versus a starter kit whose “modules” are folders with no proxy story.
**For the same admin entity, should we use Suite-generated React CRUD or Low-Code pages?**
[Suite](https://abp.io/docs/latest/suite) writes **source** into your layers (entity, app service, UI, tests) that you commit and customize, including React on modern solutions. [Low-Code](https://abp.io/docs/latest/low-code) keeps the entity in **metadata** (designer + runtime APIs/pages) without generating those classes for the standard flow. Use Suite when the screen will grow into product code; use Low-Code when the screen should stay designer-driven. They are not substitutes for each other.
### For the same admin entity, should we use Suite-generated React CRUD or Low-Code pages?
[Suite](https://abp.io/docs/latest/suite) writes source into your layers (entity, app service, UI, tests) that you commit and customize, including React on modern solutions. [Low-Code](https://abp.io/docs/latest/low-code) keeps the entity in metadata (designer + runtime APIs/pages) without generating those classes for the standard flow. Use Suite when the screen will grow into product code; use Low-Code when the screen should stay designer-driven. They are not substitutes for each other.
**Can we keep MediatR / vertical-slice handlers for new features inside an ABP solution?**
You can reference extra libraries, but ABP’s default application surface is [application services](https://abp.io/docs/latest/framework/architecture/domain-driven-design/application-services) with unit of work, validation, and authorization conventions. Comparison with CA templates is not “MediatR vs nothing”; it is **whether the team standardizes on ABP’s application layer** or on a handler-per-feature folder as the public API. Mixing both without a rule usually duplicates the same use case in two styles.
### Can we keep MediatR / vertical-slice handlers for new features inside an ABP solution?
You can reference extra libraries, but ABP’s default application surface is [application services](https://abp.io/docs/latest/framework/architecture/domain-driven-design/application-services) with unit of work, validation, and authorization conventions. Comparison with CA templates is not “MediatR vs nothing”; it is whether the team standardizes on ABP’s application layer or on a handler-per-feature folder as the public API. Mixing both without a rule usually duplicates the same use case in two styles.
## Next step
@ -196,5 +215,11 @@ Create a solution in [ABP Studio](https://abp.io/studio) and pick Modern (React)
Ahmet Çelik
1 week ago