将旧SaaS方案迁移至ASP.NET Zero的自定义项目结构优化问询

Hey there, let’s dive into your approach and share some practical, battle-tested advice from working with ASP.NET Zero migrations. Your plan to isolate core logic in custom class libraries is smart—here’s how to make it even more robust for smooth future upgrades:

• Align Layers and Enforce Clear Boundaries
  Match your custom class library structure to ASP.NET Zero’s (Core, Core.Shared, Application, etc.), but use distinct namespaces (e.g., YourSaaS.Core instead of AbpZeroTemplate.Core) to avoid conflicts. Keep shared constants, base DTOs, and interfaces in YourSaaS.Core.Shared—this way, when AZ updates its own shared layers, your core definitions stay untouched.

• Control Dependencies Wisely
  Have your custom libraries depend on AZ’s NuGet packages (like Abp.ZeroCore or Abp.AspNetCore) rather than directly referencing AZ’s project files. This decouples your code from AZ’s specific project structure, making it easier to update NuGet versions without rewriting references. Avoid pulling in unnecessary AZ modules—only include what you need for integration (e.g., authentication, permission management).

• Isolate Core Business Logic Completely
  Treat your custom class libraries as the "source of truth" for your SaaS’s core functionality. Let ASP.NET Zero handle the boilerplate: authentication, role management, UI scaffolding, etc. For example, if you have existing order processing logic, keep it in YourSaaS.Application.Orders—use AZ’s ApplicationService only as a thin wrapper to expose your logic with AZ’s permission checks, not to rewrite core rules.

• Build an Adaptation Layer for AZ Changes
  ASP.NET Zero occasionally updates base classes or APIs (e.g., changes to ApplicationService methods). Instead of modifying your core logic to match, create an adaptation layer: write custom base classes that inherit from AZ’s base classes, then have your core services inherit from these custom bases. When AZ updates, you only need to adjust the adaptation layer, not your core business code.

• Separate Database Migrations
  If you’re using Entity Framework Core, split your migrations into two sets: one for ASP.NET Zero’s schema (users, roles, permissions) and one for your custom SaaS tables. Use separate migration folders (e.g., Migrations/AZ and Migrations/Custom) and configure your DbContext to target the right folder. When upgrading AZ, run its migrations first, then apply your own—this prevents schema conflicts and makes rollbacks easier.

• Depend on Interfaces, Not Concrete Implementations
  In your custom code, always use AZ’s abstract interfaces (like IAbpSession, IPermissionChecker) instead of their concrete classes. This insulates your code from AZ’s internal changes—if AZ swaps out how sessions are managed, your code remains compatible as long as the interface stays the same.

• Use a Structured Upgrade Workflow
  Create a dedicated Git branch (e.g., az-upgrade) for testing each new AZ release. Upgrade the NuGet packages there, run your unit/integration tests, fix any compatibility issues in the adaptation layer, then merge back to your main branch. This keeps your production code stable while you validate upgrades.

Your core idea of preserving existing logic while integrating with AZ is solid—focus on minimizing coupling between your custom code and AZ’s framework, and you’ll be able to upgrade smoothly for years to come.

内容的提问来源于stack exchange，提问作者Pietro Asghedom