Stop Writing Plugins Like It’s 2011: Modern Architecture Guide

🌟 Modern Dataverse Plugin Architecture (2025 Edition)

A Clean, Testable, Maintainable, and DI-Friendly Template for Power Platform Developers

A complete, ready-to-use architecture template you can drop into your next Dataverse / Dynamics 365 project.

---

🔥 Why This Article?

Most Dataverse plugins still follow the old 2011 pattern:

• Logic inside Execute()
• Hard-coded field names
• No testability
• Zero separation of concerns
• Hard to extend
• Not reusable outside plugins
• Difficult to maintain

This article gives you a modern, scalable, testable plugin architecture with:

✔ Clean separation

✔ Supports multi-project structure

✔ Minimal DI (no heavy libraries)

✔ Test-friendly

✔ Reusable in Azure Functions / Custom APIs

✔ NuGet-based plugin deployment

✔ No system-specific logic

✔ Perfect as a starter template

---

🧱 Architecture Overview

/PluginSolution
│
├── Core
│   ├── Interfaces
│   ├── Models
│   └── Enums
│
├── Infrastructure
│   ├── Repositories
│   └── Services
│
├── Plugins
│   ├── PluginBase.cs  (from CLI template)
│   └── SamplePlugin.cs
│
└── Startup
    └── PluginFactory.cs

---

🏗 Layer Explanation

1. Core Layer (Pure, CRM-agnostic)

Contains:

• Interfaces
• Lightweight models
• Enums
• Zero dependency on Microsoft.Xrm.Sdk Benefits:
• 100% testable
• Reusable in Azure Functions / Custom APIs
• Pure C# domain layer

2. Infrastructure Layer

Contains:

• Repositories
• Dataverse operations
• FetchXML logic
• Business services This layer knows about Dataverse so the rest of the system doesn’t have to.

3. Plugins Layer

Responsible for:

• Orchestration
• Extracting context
• Mapping Entity → Core Model
• Calling services The plugin stays thin and easy to reason about.

4. Startup / Factory Layer (Minimal DI)

Instead of heavy DI (which causes sandbox issues), we use a simple factory pattern:

• No dependency conflicts
• No BCL async interface issues
• No slow DI container startup
• No Microsoft.Extensions.* packages needed Small. Fast. Compatible with Sandbox.

---

⚡ Modern Deployment: PAC CLI + .nupkg Package

In 2025, plugins should not be deployed as DLLs.
Microsoft now provides:

pac plugin init --outputDirectory . --skip-signing

This command:

• Creates a structured plugin project
• Includes PluginBase + ILocalPluginContext
• Supports NuGet packaging
• Removes need for manual DLL signing

---

🎯 Why --skip-signing?

Because NuGet-based plugin deployment does not require strong naming.
Benefits:

• No shared signing keys
• No assembly conflicts
• Smooth CI/CD
• Faster team collaboration

---

🧩 Minimal DI (Factory Pattern)

Heavy DI causes:

• Slow plugin execution
• Version conflicts
• Sandbox restrictions
• Hard-to-debug runtime errors

So we use:

Plugin → Factory → Services → Repositories

This gives you DI benefits without DI overhead.

---

🧩 Optional: Using Early-Bound Classes (Highly Recommended)

Although the template in this article uses a lightweight EntityModel for simplicity,
the architecture is fully compatible with Early-Bound classes

Note:

The Power Platform CLI can now generate Early-Bound classes for you automatically using:

pac modelbuilder build --outputDirectory Models

Just drop the generated models into a separate project and reference it from your Plugin + Infrastructure layers.

---

📝 Template Code (Copy/Paste)

A completely generic, reusable template.

---

📦 Core: Model

namespace PluginTemplate.Core.Models
{
    public class EntityModel
    {
        public Guid Id { get; set; }
        public string LogicalName { get; set; }
        public IDictionary<string, object> Attributes { get; set; }
    }
}

📦 Core: Interface

namespace PluginTemplate.Core.Interfaces
{
    public interface IEntityValidationService
    {
        void Validate(EntityModel model, Guid userId);
    }
}

📦 Infrastructure: Repository Template

using Microsoft.Xrm.Sdk;
using Microsoft.Xrm.Sdk.Query;
using PluginTemplate.Core.Interfaces;

namespace PluginTemplate.Infrastructure.Repositories
{
    public interface ISampleRepository
    {
        Entity RetrieveEntity(Guid id);
    }

    public class SampleRepository : ISampleRepository
    {
        private readonly IOrganizationService _service;

        public SampleRepository(IOrganizationService service)
        {
            _service = service;
        }

        public Entity RetrieveEntity(Guid id)
        {
            return _service.Retrieve(
                "xyz_customtable",
                id,
                new ColumnSet("xyz_textfield"));
        }
    }
}

📦 Infrastructure: Service Template

using PluginTemplate.Core.Interfaces;
using PluginTemplate.Core.Models;

namespace PluginTemplate.Infrastructure.Services
{
    public class EntityValidationService : IEntityValidationService
    {
        public void Validate(EntityModel model, Guid userId)
        {
            // Add validation logic (optional)
        }
    }
}

⚙️ Factory (Minimal DI)

using Microsoft.Xrm.Sdk;
using PluginTemplate.Core.Interfaces;
using PluginTemplate.Infrastructure.Repositories;
using PluginTemplate.Infrastructure.Services;

namespace PluginTemplate.Startup
{
    public static class PluginFactory
    {
        public static IEntityValidationService CreateValidationService(
            IOrganizationService service,
            ITracingService tracing)
        {
            var repository = new SampleRepository(service);

            return new EntityValidationService();
        }
    }
}

🔌 Plugin Template

using System;
using Microsoft.Xrm.Sdk;
using PluginTemplate.Startup;
using PluginTemplate.Core.Models;
using PluginTemplate.Core.Interfaces;

public class SamplePlugin : PluginBase
{
    public SamplePlugin(string unsecure, string secure)
        : base(typeof(SamplePlugin)) { }

    protected override void ExecuteDataversePlugin(ILocalPluginContext ctx)
    {
        var context = ctx.PluginExecutionContext;
        var tracing = ctx.TracingService;
        var org = ctx.OrgSvcFactory.CreateOrganizationService(context.UserId);

        if (!(context.InputParameters["Target"] is Entity target))
            return;

        var model = new EntityModel
        {
            Id = target.Id,
            LogicalName = target.LogicalName,
            Attributes = target.Attributes
        };

        var service = PluginFactory.CreateValidationService(org, tracing);
        service.Validate(model, context.UserId);
    }
}

---

📐 Architecture Diagram

+-----------------------+
|        Plugins        |
|  (thin orchestration) |
+-----------+-----------+
            |
            v
+-----------+-----------+
|        Factory         |
|   (minimal DI layer)  |
+-----------+-----------+
            |
            v
+-----------+-----------+
|     Infrastructure    |
| Repositories/Services |
+-----------+-----------+
            |
            v
+-----------+-----------+
|      Core Layer       |
|  Interfaces + Models  |
+-----------------------+

---

✨ Benefits of This Architecture

🔹 1. Testable

Core + Infrastructure can reach 100% test coverage.

🔹 2. Clean Separation

Plugin → Service → Repository.

🔹 3. Reusable

The same services can be used in:

• Plugins
• Custom APIs
• Azure Functions
• Virtual Tables

🔹 4. Minimal Dependencies

No need for:

• Microsoft.Extensions.DependencyInjection
• Async Interfaces
• External DI frameworks

Comments

[Mohamed ELgharably]

If you have questions about DI, plugin packaging, or Dataverse architecture, drop them here — I’ll answer everything.