Previous article: Shared Foundation Layout for Razor Pages and Cotomy
Up to the previous note, I summarized the structure I use when I develop with Cotomy and Razor Pages. In truth, the exact shape of the structure is not the most important thing to me. What matters to me is how to get through a large amount of daily work efficiently and with fewer mistakes.
The structure I described helps with development, but it also shortens maintenance and later investigation quite noticeably. The biggest effect, however, is that most of the systems I have built since a certain point now follow almost the same structure. There are small differences, of course. Some older systems still use an earlier form of what later became Cotomy. But the broad arrangement is now stable across most of my work.
That kind of consistency obviously improves day-to-day work. But there is another problem I wanted to solve, and adopting Razor Pages helped me solve it. This time, I want to write about that problem.
The problem is how to keep one consistent naming path from persisted data, in other words from database tables, all the way to the screen the user actually touches.
This way of thinking is especially effective in form-centered SSR applications, particularly in CRUD-heavy business systems. It works best when the practical unit of change is the screen, because the server-rendered form and the UI behavior usually change together. I do not think it applies equally well to every frontend architecture. In more independent SPA structures or highly dynamic UI products, different tradeoffs often become more important.
The same field used to have too many names
If I build in a strongly separated SPA style, the server side and client side are treated as distinct systems, and the frontend is implemented against API contracts. That is a rational approach. It is also a strong way to build very large applications with more dynamic UI behavior.
But the systems I build, and the kind of systems I imagine people building with Cotomy, are usually not that kind of product. They are not trying to be flashy. They need to be steady, durable over long operation, able to handle complexity, and at the same time avoid creating unnecessary complexity.
For a long time, the problem that kept bothering me in web development was that the database field name, the Entity property name, the name attribute on the screen, and the property name read by JavaScript were all disconnected. To access one field, the same concept had to be declared again and again as strings or program identifiers at several different points in the route.
And those declarations were usually made separately.
That means the same business fact could drift by small errors. One place used one spelling. Another place used a slightly different spelling. Another place changed and one more did not. During development, that is already annoying. In a large system, when only one small part is reading data incorrectly, the place where the defect appears can be far away from the place where the naming mismatch was introduced. That makes investigation slower than it should be.
Many of these issues can eventually be found by testing. But that is not really the point. The problem is that the cost of detecting, tracing, and rechecking them keeps accumulating. Even when the defect is not severe, the structure keeps generating small verification costs that add up over time.
In desktop-style systems or older two-tier client-server systems, this kind of mismatch often surfaces earlier because the compiler catches more of it. On the web, especially when strings are passed across multiple layers, the same problem tends to survive longer.
What I liked in older connected tools
There was a period when I often chose Microsoft Access for solo development.
Access had many problems. I do not want to romanticize it. But it had one remarkable strength. When I built screens and reports from database data, the implementation was connected in a way that made simple naming mismatches much less likely. It was not easy to mistype a field name in one place and silently drift away from the data definition in another.
Because of that, when I developed systems in Access, there were times when I could implement more than ten different reports in only a few days. This was long before AI assistance existed, which impressed me quite a lot at the time.
That speed was not only because naming stayed connected. Access also had very strong built-in reporting features, and that was a major part of why so many reports could be produced in such a short time.
I saw the same kind of strength again in older SOAP-based three-tier client-server systems. When the client-side DTOs were generated from WSDL, the route from server contract to client-side structure was already connected by the toolchain. That did not make those systems simple overall, but it did mean this particular naming problem was much less likely to occur. The client was not retyping every field contract by hand.
So what I wanted to recover later was not Access itself, and not SOAP itself either. What I wanted to recover was that same structural quality. I wanted the route from data to screen to stay connected instead of being manually re-declared at every step.
Entity Framework solved the first half
Before I moved to Razor Pages, this problem kept bothering me. Razor Pages did not solve everything by itself, but it gave me an environment where the missing pieces could be lined up properly.
The first large improvement came from Entity Framework.
Once I moved to a code-first style, I could implement the Entity class first and let that definition drive the database structure. In that arrangement, the program and the database become connected in a much tighter and more reliable way. At least on the server side, the gap between program structure and database structure becomes much smaller.
That alone made development far more comfortable for me.
The point is not only convenience. It changes where the authoritative name lives. If the Entity definition is the source, then the database no longer evolves as a separate naming world that the application must constantly reinterpret.
The remaining problem was the screen
Even after that, one large problem remained.
No matter whether I use Cotomy or not, data usually moves from frontend to server through forms and inputs. The HTTP method may be GET, POST, or something else, but the practical route is still often a form with fields, and the field name is decided by the name attribute.
That name may point to a simple property, one field inside a nested object, or one array element. But structurally it is the same problem. If the names at that stage drift away from the names used on the server side, the route is broken again.
C# has a feature that was extremely important for me here: nameof.
If there is a property named PartnerId on Order, then nameof(Order.PartnerId) gives me the string PartnerId. That sounds small, but to me it solved one of the most persistent problems in web development. It is also one of the major reasons I have continued developing in C#.
In practice, almost every form input has a name attribute. I set those names with nameof whenever I reasonably can.
<input name="@nameof(UserEntity.Name)" />
<input name="@nameof(UserEntity.Email)" />
<input name="@nameof(UserEntity.Phone)" />
That one habit changes a surprising amount.
Now the form is no longer inventing its own field vocabulary. The screen is borrowing the property name from the C# side instead of retyping it as an unrelated string.
This does not mean DTOs are always unnecessary. There are cases where I still define DTOs explicitly. In particular, I think external API boundaries, security boundaries, and versioned contracts often justify a clearer DTO layer. For externally exposed or versioned APIs, I think a clearer DTO boundary is often necessary. For internal business screens, it can often be reduced or omitted.
When I do define DTOs or projection shapes, they are usually edited intentionally as part of the contract, which makes mistakes easier to notice. In C#, there are also cases where it is enough to project only the fields to expose through an anonymous object instead of sending a broader model as it is, or to match fields automatically by property names. So even when DTOs exist, the naming problem is still much easier to control than in a structure where each layer re-declares names independently by hand.
Razor Pages made this route feel much more natural
This is where Razor Pages helped me a great deal.
Because the screen is server-rendered, the frontend does not need to define a second full model just to know what field names exist. The server emits the form with its name attributes already decided. The client side can then submit those names back as they are, or use the same names to fill values later.
That does not mean the frontend can never know anything about the data. Some pages still need page-specific display logic. But in many ordinary business screens, the client side does not need to redefine the data structure just to move values between the API response and the DOM. The HTML already contains the route.
That is an important difference for me.
The names do not have to be rediscovered separately on the client. They are already present on the screen that the server rendered.
Of course, this has limits. If the UI becomes highly interactive, if the frontend is released independently, or if the API boundary must be versioned and controlled separately, then a stronger DTO boundary and a more explicit client-side model can be the correct choice. I do not think this article describes a universal answer.
How Cotomy fits into this
Cotomy does not solve database design. It does not define server-side models. Its role is narrower than that.
What Cotomy gives me is a way to continue the same naming path on the UI side without adding another unnecessary model layer.
CotomyEntityApiForm handles entity-oriented API submit flow. It manages the entity key and switches from POST to PUT when an entity key is present.
CotomyEntityFillApiForm extends that behavior with load and fill support. When the form has an entity key, it can load data from the API on page ready. And when it fills the form, it applies values to inputs by matching their name attributes.
That behavior is visible in the implementation itself. CotomyEntityFillApiForm searches for inputs, textareas, and selects by name and fills matching fields from the API response. For non-input display elements, it uses CotomyViewRenderer and data-cotomy-bind.
This also includes nested objects and indexed data when the naming rule stays consistent. In the sample structure, names such as profile.code, details[0].itemCode, Lines[0].Quantity, or the more general shape of Order.Items[0].Name can still be matched because the route is expressed through names instead of through a separately rebuilt client-side model. With nested names, the name itself becomes the path, so structural changes on the server side can affect the UI route directly.
In practice, that means I can build a screen around names already present in the DOM. Those names may come directly from entity-side definitions, or from DTOs and projection shapes prepared on the server side. The important point is that the client does not need to invent a separate naming layer again.
<form id="user-form" action="/api/user">
<input name="@nameof(UserEntity.Name)" />
<input name="@nameof(UserEntity.Email)" />
<span data-cotomy-bind="@nameof(UserEntity.Name)"></span>
<span data-cotomy-bind="@nameof(UserEntity.Email)"></span>
</form>
import { CotomyEntityFillApiForm, CotomyPageController } from "cotomy";
CotomyPageController.set(class extends CotomyPageController {
protected override async initializeAsync(): Promise<void> {
this.setForm(CotomyEntityFillApiForm.byId(
"user-form",
CotomyEntityFillApiForm
)!);
}
});
The important point is not that the TypeScript side now knows the whole Entity definition. The important point is that it usually does not have to recreate the naming contract by hand.
The form submits by the names already attached to the inputs. The fill process restores values by those same names. And display-only elements can be updated through data-cotomy-bind using the same response object.
This is why I care so much about name consistency
When each layer reads data with its own independently declared names, the system becomes harder to trust.
One mismatch may only break one small area. But in a large system, that small area may be physically far from the source of the problem. The code that writes the name, the code that sends the request, the code that reads the response, and the place where the user notices the failure may all be different.
That is exactly the kind of structure that slows investigation down.
What I wanted instead was a route where the same meaning could travel from persisted data to the screen with as little reinterpretation as possible.
In my current style, the route is roughly this.
Entity Framework keeps the persisted model and the database definition aligned. Razor Pages emits form fields using names borrowed from C#. CotomyEntityFillApiForm uses those names again when loading and filling. CotomyViewRenderer uses the same response object for display bindings.
That does not remove all mistakes, of course. No structure can do that. But it removes a whole category of mistakes created only by duplicated naming declarations. Names alone are not sufficient for total safety. Type mismatches, null handling, nested structure drift, and partial update behavior still need to be considered separately.
Where Cotomy stops
This boundary is important.
Cotomy is not replacing Entity Framework. It is not deciding the Entity model. It is not designing the API contract. And it is not business logic.
What it does is continue the UI-side part of the route once the server has already decided what names exist on the screen. In other words, Cotomy helps me avoid rebuilding the same mapping yet again on the frontend.
That is why I think of this less as a frontend convenience and more as a consistency mechanism in the overall application path.
At the same time, I do not mean that every page must be completely ignorant of data shape. Some pages still need extra UI behavior and may inspect a few response properties directly in page-specific code. The important point is that the normal form and display path does not require a second full declaration of the data model just to move values around.
Even when extra screen-specific behavior is needed, I do not think that justifies rebuilding the whole data contract on the client side. In many cases, it is enough to define only the small interface that the extra behavior actually needs. That keeps the implementation local, keeps the impact surface small, and reduces the risk introduced by the additional code itself.
This also means I am not against view-specific transformation itself. Screens still need formatting, display-only values, and other presentation decisions. The point is simply that those concerns should be added deliberately at the edges where they are needed, instead of forcing the whole route from persistence to the screen to fork into a second broad naming system too early.
Although I am explaining this through Entity Framework, Razor Pages, and Cotomy, I do not think the underlying idea belongs only to that stack. The broader principle is to keep naming contracts connected for as long as practical, and to introduce extra translation layers only where they are truly required.
Closing
What I wanted for a long time was simple to say and surprisingly hard to achieve in ordinary web development: I wanted the same field to keep the same identity from persistence to the screen.
Entity Framework solved the gap between program structure and the database. Razor Pages let the server render the field names directly into the screen. And Cotomy let the UI continue using those names for load, fill, submit, and display without demanding another parallel client-side model in the ordinary case.
For me, this has had a very large effect. It reduced mistakes, reduced the amount of declaration I had to repeat, and made later investigation much easier when something still went wrong.
More than anything else, it made the route from stored data to actual screen behavior feel connected again.
The next thing worth writing about is what Entity Framework changed after that first comfort. Once data design and implementation were brought together, the longer-term effects on migration work, schema change tracking, and operational maintenance became impossible for me to ignore.
C# Architecture Notes
This article is part of the Cotomy C# Architecture Notes, which reflect on backend and project-structure decisions around business systems.
Series articles: Why I Chose C# for Business Systems and Still Use It , From Global CSS Chaos to Scoped Isolation , Unifying Data Design and Code with Entity Framework , How I Split Projects in Razor Pages Systems , Integrating TypeScript into Razor Pages with Cotomy , Shared Foundation Layout for Razor Pages and Cotomy , and Consistent Data Flow from Persisted Models to the Frontend.
Next article (planned): how Entity Framework changed not only my data design style, but also migration work, change tracking, and long-term operations.
