EditorEntryFor helper makes the code DRYer and opens new possibilities, such as automatic indication of required fields. A small addition in one helper method will mark all required fields in entire MVC web application.
It’s more or less standard to indicate required fields in a form with a red * next to the label. Entering them one by one in the markup is tedious. Adding them to the description text is outright wrong and will look bad if the description is used in other places, such as validation messages.
They shouldn’t need to be handled at all, since the metadata already contains a property indicating if the field is required or not. If all form entries are created in the same way as I showed in the DRYing MVC Forms with an EditorEntryFor Helper post it’s easy to automatically add a required marker whenever a form field is required.
Instead of calling
LabelFor directly, I’ve created an own helper method that checks the
IsRequired flag on the metadata.
When creating forms in ASP.NET MVC I use a small helper to keep the code DRY (Don’t Repeat Yourself). The
EditorEntryFor helper creates everything needed for a form field – the label, the input and the validation.
When creating line of business applications, a huge part of the coding is often to create forms. Each form can consist of a huge number of fields and each field requires some common formatting. It’s usually quite straightforward with a few divs surrounding a
label and the
input field. Running the default MVC scaffolding tooling, that’s exactly what’s generated:
@Html.LabelFor(model => model.TopSpeed)
@Html.EditorFor(model => model.TopSpeed)
@Html.ValidationMessageFor(model => model.TopSpeed)
In my opinion that code has two severe problems:
- It’s too verbose.
- It’s repeating itself for each form field, making the class name and div structure a pain to modify.
In my projects I usually create a small helper, so the above lines of code can be replaced with one single statement:
@Html.EditorEntryFor(model => model.TopSpeed)
What’s the best way to name a css class:
bold-text? Is there any difference between MVC’s
TextBoxFor? Or between a
DetailedRowText property and
For all the cases, there is a difference. The first one is naming by purpose and the other naming by effect, or what it actually does. Even though the methods/properties do exactly the same thing, there’s a huge difference in the coupling they imply. When named by effect, the name is a promise to the caller on exactly what will be done. It is safe to use it in different circumstances, trusting that it will always do what the name implies. When a method is named by purpose there’s no guarantee on exactly what it will do, there’s instead a promise that it will adopt it’s behaviour as needed.
Both naming by purpose and naming by effect have their uses, but they shouldn’t be confused. The choice between them should always be deliberate and not accidental.
Let’s look closer at the examples listed above.
MVC and Entity Framework scaffolding is powerful, but I prefer to know what actually happens before accepting generated code. The code generated to update an entity when an edit has been done looked interesting, so I decided to have a closer look at it.
When an edit is done to an entity, the data is posted as a simple collection of form elements from the web browser. Remember that when working with MVC, we’re closer to the metal than with Web Forms and we are fully exposed to the stateless nature of the web. The gigantic hidden ViewState form field is gone, leaving us in a clean, but stateless world. When the updated data is posted to the server, the server has no more info about it than available in the request. The server doesn’t know where it came from and has to find out itself where, how and what part of it to update.
Tracking changes for objects moving across tiers, being disconnected from their original data source is always tricky. I’m still looking for the silver bullet to this problem and one step in the search is to investigate what other have done. In this post, I’ll take a closer look on how the Scaffolded code of MVC handles updates to EF Entities.
A typical architecture of a .NET web application is to use EF Code First for data access and MVC to render the web pages. The data model in the database is usually (and should be!) normalized. A normalized data model is also great for updates, but when displaying data it is not enough. E.g. in a table of cars I don’t want to display a numeric, database internal id of the car’s brand. I want to display the name of the brand. Creating a separate read model simplifies that.
Separating the read and write models are a key concept of the recently popular CQRS (Command Query Responsibility Separation) architecture. I won’t go as far as the CQRS model does, but rather show a simple way to dress the write model’s car entity with the values required for displaying.
My key objective is to get a model where I can get everything needed for rendering a view to the user in one fetch from the database, with a minimum of extra coding and mapping code.