# WalkingTec.Mvvm (WTM): a .NET Core framework built around ViewModels and a code generator

> WTM is an MIT-licensed ASP.NET Core framework from the .NET Core Community that pairs four ViewModel types with a code generator and stable LayUI, React, Vue and Blazor front ends. It is aimed at teams building data-heavy admin applications, and its main cost is that you adopt its conventions wholesale.

**dotnetcore/WTM** — Use WTM to write .netcore app fast !!!

- Repository: https://github.com/dotnetcore/WTM
- Website: https://wtmdoc.walkingtec.cn
- Stars: 4,351 · Forks: 896
- Language: C#
- License: MIT
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/dotnetcore-wtm

## The problem WTM targets: admin back ends that are mostly the same

Most line-of-business web applications repeat the same shapes. A list screen with paging and an export button. A create and edit form over one entity. A bulk import from a spreadsheet. A batch action that flips a status column on selected rows. Users, roles, menus, permissions and audit logs. WTM's claim is that these shapes are predictable enough to be framework primitives rather than code you rewrite per entity.

The README states the framework provides four types of ViewModel covering common web application functionality. CrudVM handles addition, deletion and modification. ListVM handles paging and exporting. ImportVM and TemplateVM handle Excel import. BatchVM handles batch operations. Alongside those, the README lists built-in user, role, user group, data permission, page permission, menu, log, mail, SMS and file functionality, plus single sign on, portal and distributed database support.

The intended reader is a .NET team that would otherwise spend its first weeks rebuilding a permission model and a paging helper. WTM is not a general-purpose web framework in the sense ASP.NET Core itself is. It is a layer of opinion on top of ASP.NET Core, and the opinion is that your application is a set of entities with screens attached.

## How the ViewModel types and the code generator fit together

The architecture visible in the README is a server-side framework plus a client-side framework, with the ViewModel as the shared unit. A CrudVM wraps one entity and carries the validation and save logic for a single record. A ListVM wraps a query, the paging state and the export path. ImportVM and TemplateVM are the two halves of an Excel round trip: TemplateVM produces the file a user fills in, ImportVM reads it back. BatchVM takes a set of selected records and applies one operation to all of them.

Because the ViewModel is the unit, the code generator can emit both halves of a screen from the same description. The README says that in client-side mode the generator produces server-side and client-side code at the same time, which it presents as reducing the communication cost between front-end and back-end developers. That is the real design bet: the generator is only useful because the ViewModel convention makes the generated output predictable.

The UI story is four modes, all listed as Stable in the README: LayUI server-side, React client-side, Vue client-side, and Blazor server or client. The repository layout reflects this. There is a demo/WalkingTec.Mvvm.Vue3Demo/ directory next to demo/WalkingTec.Mvvm.ConsoleDemo/, and the Dockerfile publishes demo/WalkingTec.Mvvm.Demo/WalkingTec.Mvvm.Demo.csproj, so the sample application is a first-class part of the tree rather than an afterthought.

## Installing WTM and generating a first project

WTM ships as NuGet packages rather than a project template you install globally. The README lists WalkingTec.Mvvm.Core, WalkingTec.Mvvm.Mvc, WalkingTec.Mvvm.Mvc.Admin and WalkingTec.Mvvm.TagHelpers.LayUI, each with a version badge pointing at nuget.org. There is no install command in the README beyond that table, and no CLI is documented for scaffolding a new solution.

The README does point at a hosted generator: it links to wtmdoc.walkingtec.cn/setup and describes it as generating a WTM project online. If you prefer to work from the repository instead, the Dockerfile shows what a published WTM application looks like, and it is a useful check that your toolchain matches what the project targets.

```dockerfile
FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build
WORKDIR /app

COPY . .
RUN dotnet publish "./demo/WalkingTec.Mvvm.Demo/WalkingTec.Mvvm.Demo.csproj" -c Release -o /app/out


FROM mcr.microsoft.com/dotnet/aspnet:10.0 AS runtime
WORKDIR /app
COPY --from=build /app/out ./
```

The build stage uses the .NET 10 SDK image and the runtime stage uses the matching ASP.NET Core image, so a container build of the demo does not need a local SDK at all. The runtime stage sets two environment variables before the entry point, which is where a first deployment usually goes wrong.

```dockerfile
ENV ASPNETCORE_URLS http://+:80
ENV ASPNETCORE_ENVIRONMENT Production
ENTRYPOINT ["dotnet", "WalkingTec.Mvvm.Demo.dll"]
```

The application listens on port 80 inside the container and runs in the Production environment. The Dockerfile also carries a comment worth reading before you plan any image work: System.Drawing is no longer supported on Linux in .NET 6 and later, and the file directs you to SkiaSharp or ImageSharp instead. If your first WTM feature involves thumbnails or uploaded images, that constraint arrives early.

Once you have a project, the first real use is to point the generator at one entity and let it produce the CrudVM, the ListVM, the controller and the matching client page, then open the generated list screen and confirm that paging and export behave as the README describes.

## Where WTM is the wrong tool

The four ViewModel types are a strong fit for CRUD over relational entities and a weak fit for anything else. If your application is a public content site, a streaming or event-driven service, a thin API consumed by a mobile client you do not control, or a system whose core value is a domain model with rich invariants, the CrudVM and ListVM abstractions buy you very little and constrain how you structure the parts that matter.

The heavier cost is coupling. Because permissions, menus, logging, mail and SMS are built in, the framework is present in your startup path, your data access and your UI layer at once. The README does not document rollback, and it does not describe how to remove a built-in subsystem you decide not to use. That is a one-way door in practice: adopting WTM is closer to adopting a platform than adding a library, and a team that later wants plain ASP.NET Core with its own permission model should assume a rewrite rather than a removal.

There is also a versioning trap. The repository's default branch is dotnet10 and the Dockerfile targets .NET 10, but the newest release listed in the README is v8.1.12 from 2024-10-10, with v8.1.10 and v6.5.9 both dated 2024-07-14. The README separately notes that version 5.0x lives on a VNext branch. Source, container image and published packages are not guaranteed to line up, so check the NuGet version you actually restore against the branch you are reading. The last push to the repository was on 2026-07-05.

## WTM versus building the same admin layer on plain ASP.NET Core

The real alternative is not another framework. It is ASP.NET Core with a scaffolding tool such as the built-in dotnet aspnet-codegenerator, or a lighter admin package, plus your own permission and audit code. The difference in approach is where the abstraction sits. WTM puts it in the ViewModel, so a screen is a ViewModel plus a generated view, and the generator can write both sides. Plain ASP.NET Core puts it in the controller and the Razor page or component, so each screen is assembled by hand and nothing can be generated from a shared description.

That difference shows up in two places. First, onboarding: a developer who knows ASP.NET Core but not WTM has to learn four ViewModel types before writing anything, whereas a controller-and-view codebase is readable on day one. Second, change cost: when a screen needs behaviour the CrudVM shape does not cover, WTM asks you to work with or around the ViewModel, while plain ASP.NET Core asks nothing because there was never a shape to begin with.

The trade is time against ceiling. If your application is a long series of similar admin screens, WTM's generator and its built-in permission, menu and logging layers will save weeks. If your application has a handful of unusual screens and a large amount of unusual business logic, the generator has little to generate and the built-in layers are weight you carry without using.

## Licence, maintenance and what an upgrade actually costs

WTM is MIT licensed, and the README links to the LICENSE file at the repository root. MIT is permissive: it allows commercial use and modification, and it requires that the copyright notice and permission notice be preserved in copies or substantial portions. That is the general shape of the licence, not advice about your situation; if you redistribute WTM inside a product, have your own counsel confirm what notices you must ship.

The maintenance picture is mixed and worth stating plainly. The repository is not archived, and the last push was on 2026-07-05, so the code is moving. Releases are a different story: the newest listed is v8.1.12 from 2024-10-10, roughly nine months before that last push. A team that pins to released NuGet packages and a team that tracks the default branch are effectively on two different projects.

Upgrade cost follows from the ViewModel coupling. A major version bump can touch CrudVM, ListVM, ImportVM and BatchVM at once, and the generated code in your application inherits whatever those types do. The practical mitigation is to keep generated code and hand-written code in separate files so a regeneration does not overwrite your work, and to build the demo project against your target SDK before upgrading anything real. The repository's Dockerfile is the shortest test of that: if the demo publishes and runs in the .NET 10 images, the framework core is at least coherent on that SDK.

## Conclusion

WTM suits teams building conventional, data-heavy admin back ends on ASP.NET Core who want CRUD, paging, Excel import, batch operations, permissions and menus already wired up, and who accept its ViewModel conventions as the price. It is a poor fit for public-facing, content-led or API-only services where almost none of that scaffolding is used, and for anyone who needs a documented path back out of the framework later. Verify three things before committing: that the demo project builds and runs on your target .NET SDK and database, that the code generator's output matches the naming and layering your team already uses, and that the .NET version you need is actually published to NuGet, since the default branch and the newest release listed in the README do not move in step.

## FAQ

### What is WTM (WalkingTec.Mvvm) used for?

WTM is a rapid development framework based on .NET Core for building web applications, with built-in CrudVM, ListVM, ImportVM and BatchVM types plus a code generator. The README positions it as a tool for efficient web development with LayUI, React, Vue and Blazor front ends.

### How do I install WTM in an ASP.NET Core project?

WTM is distributed as NuGet packages: WalkingTec.Mvvm.Core, WalkingTec.Mvvm.Mvc, WalkingTec.Mvvm.Mvc.Admin and WalkingTec.Mvvm.TagHelpers.LayUI. The README does not give an install command, and instead links to an online generator at wtmdoc.walkingtec.cn/setup for creating a WTM project.

### Which front-end frameworks does WTM support?

The README lists four modes, all marked Stable: LayUI server-side, React client-side, Vue client-side, and Blazor for server or client. In client-side mode the README states the code generator can produce server-side and client-side code at the same time.

### What licence does WTM use?

The repository is MIT licensed, with the LICENSE file at the repository root. MIT permits commercial use and modification provided the copyright and permission notices are preserved in copies or substantial portions.

### What .NET version does WTM target?

The repository's default branch is dotnet10 and the Dockerfile builds and runs on the .NET 10 SDK and ASP.NET Core images. The README's CI table also lists builds for SDK v2.2.300, v3.1.101, v5.0.103 and v6.0.101, and notes that version 5.0x is on the VNext branch.

## Sources

- [dotnetcore/WTM on GitHub](https://github.com/dotnetcore/WTM)
- [License: MIT](https://github.com/dotnetcore/WTM/blob/dotnet10/LICENSE)
- [Project website](https://wtmdoc.walkingtec.cn)
- [README](https://github.com/dotnetcore/WTM/blob/dotnet10/README.md)
- [Releases](https://github.com/dotnetcore/WTM/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dotnetcore-wtm