WebEdify, MACRIM's .NET application platform, replaces the per-feature Controller–Service–Repository stack with three declarative layers: HTML templates and tags for presentation, markdown command files for orchestration and business logic, and named processors for atomic steps including data access. You still run on ASP.NET Core and standard .NET tooling; you simply stop writing three C# classes every time someone needs a new screen.

What actually runs when someone opens a page?

A URL maps to a template file — blog.html serves /blog, contact.html serves /contact, and route patterns can map nested paths to the same template when one file handles many URLs.

The framework's static controller resolves the path, renders the template through the tag engine, and returns HTML. There is no separate front-end build and no client-side router assembling the page. Tags in the template load data, branch on context, and emit markup.

That template is the presentation layer. It is the closest analogue to a view — except it also declares data dependencies inline.

What replaces the controller?

In classic MVC, a controller action prepares a view model and returns a view. In WebEdify, a template prepares its own context with tags that execute server-side work without rendering HTML themselves.

The command tag runs a named command and attaches the result to the shared data tree:

<@auth />
<@command name="resolve" group="models/article"
          resolve="/blog/what-replaces-the-controller-the-service-and-the-repository" prefix="/blog"
          segment="webedify" purpose="blog" />
<h1></h1>

The relay tag does the same for HTTP-backed sources when the data lives on an external API rather than your repository profile.

Neither tag emits visible output. They populate context — field names like resolve the same way on a contact form, a dashboard widget, or a blog post. Multiple commands on one page compose naturally; order in the template is order of execution.

HTTP APIs still exist for form posts, AJAX table loads, and integrations. Those entry points are thin: they validate access, bind parameters, and dispatch into the same command processor pipeline. Application authors define behavior in command files, not in controller classes per entity.

What replaces the service layer?

The service layer in MVC usually holds business rules, orchestration, and cross-entity workflows. In WebEdify that work lives in markdown command files — human-readable documents with named steps.

A typical save flow might merge form fields onto a working node, apply validation rules, and persist:

## save-contact

### Steps

**merge** form except active, segment, created
**save** contact to default

Steps are processor invocations. Merge copies attributes. Join matches two lists. Aggregate groups and counts. Rules runs a named ruleset with before/when/success blocks. Command (nested) calls another command definition for reuse.

Complex workflows remain readable because the file is the documentation. Business analysts can review a command without opening Visual Studio. The AI assistant in the workspace reads and writes the same files developers do — which is why declarative logic tends to survive LLM-assisted development better than scattered imperative code.

When configuration genuinely cannot express a requirement, a code processor step runs a short C# block inside the pipeline — still part of the command, still auditable, still in plain text on disk. Custom processors implement IProcessor in your assembly when a capability must be reusable across clients.

What replaces the repository?

Data access is not gone — it is packaged as processors with a consistent shorthand. Get retrieves one record by id. List queries and attaches children. Save and save-batch persist. Delete removes. Each step names a model, identifiers, and a writable repository profile such as Cosmos, SQL Server, Snowflake, Supabase, or Turso. The SQLite hybrid profile is a separate read-only option for querying CSV or encrypted reference data through SQLite.

**list** patients from default
- maxrows: 50

Under the hood, the get and list processors resolve an INodeRepository from a factory — the repository pattern still exists as infrastructure. Application authors declare what to load or save in the command; they do not hand-write a PatientRepository for every model.

Everything flows as INode: attributes on nodes, children for collections, locators for navigation. Processors transform one node into the next; no parallel DTO graph to maintain.

Where does C# still belong?

WebEdify is "low-code with no ceiling," not "no code." Extension points are explicit interfaces discovered at startup:

Reference your assembly; the factory registers implementations. Your extensions live in your libraries on your versioning, separate from platform upgrades.

That separation is why Why WebEdify describes extension as implementing a contract — not forking the framework every time a payer API or document parser differs from the last project.

What does a real feature look like end to end?

Take the public blog on this site:

1. Route — /blog/ maps to blog.html.
2. Template — command tag calls models/article/resolve with the path and segment.
3. Command — resolve decides feed, category, or single-article mode; lists or loads documents; joins media metadata.
4. Presentation — CMS and article tags render the body; each tag reads from the node tree the command populated.

Take the contact pilot form:

1. Template — form tag posts to /api/marketing/request-pilot.
2. Command — marketing command validates, merges fields, saves a lead record.
3. Processors — merge and save against the configured profile.

No PilotController, PilotService, or PilotRepository trio — just a template, a command file, and processor steps you can read in one sitting.

How does this compare to "just use MVC"?

ASP.NET Core remains the host. Security middleware, authentication, HTTPS, and deployment are standard. What changes is where your feature logic lives: in text files that diff cleanly in Git. When a versioning platform is registered, those files can also be previewed in isolated working lanes and promoted through that platform's release flow.

That model is what Features calls velocity with no ceiling — markdown and HTML execute directly; C# is there when you need it.

For the AI implications of declarative commands, see Why WebEdify — AI data access. For a step-by-step engagement picture, see How it works.

How can you test this architecture?

Bring one screen you already maintain — a list, a form, or a report — and ask us to express it as a template plus command file in a pilot environment. You will see the mapping from URL to template to processors in your own codebase, and you can decide whether the readability trade works for your team before you talk bands on Pricing.