Return to Answer

This is the age-old mantra of bad practice justifications. I want to cut this corner because I it's a waste of time.

This is the age-old mantra of bad practice justifications. I want to cut this corner because I it's a waste of time. Or, more aptly put, anything that takes longer than the shortest thing I can think of is therefore a needless waste of time.

Note that a slightly different argument applies to non-HTML formats, e.g. a WPF app; but it's the same conclusion in the end. Here, at the end of a rendering a view the entity does not necessarily descope yet (because it can and most likely will be kept in memory). However, the only way in which your rendered view impacts the entity is if you set up a binding. And it makes no sense to set up the binding for the content of an immutable object. If it's immutable, then you wouldn't be able to reflect any changes made to the data anyway.

var model = new CustomerOrderPageViewModel(new Customer);

model.CustomerSubject.Name = "I can totally change this";

Is this immutable? I've heard argument either way. You cannot alter a CustomerOrderPageViewModel instance. However, it's still possible to indirectly alter the data contained in this CustomerOrderPageViewModel instance:

var customer = new Customer();
var model = new CustomerOrderPageViewModel(customer);
 
var modelName_1 = model.CustomerName;

customer.Name = "Different";
 
var modelName_2 = model.CustomerName;

Note that when you do actually implement the indirection described above, and your viewmodels and entities are separate, then you can in fact achieve immutability easily here. I just wanted to point out that what you call immutability is not in fact immutability, because you are liable to repeat that mistake even if you were to add a layer of indirection.

var model = new CustomerOrderPageViewModel(new Customer());

model.CustomerSubject.Name = "I can totally change this";

Is this immutable? You cannot alter a CustomerOrderPageViewModel instance, so it must be immutable, right?

However, it's still possible to indirectly alter the data contained in this CustomerOrderPageViewModel instance:

var customer = new Customer() { Name = "Original" }; 

var model = new CustomerOrderPageViewModel(customer);
var modelName_1 = model.CustomerName;

customer.Name = "Different";
var modelName_2 = model.CustomerName;

var isImmutable = modelName_1 == modelName_2; // false

Note that when you do actually implement the indirection described above, and your viewmodels and entities are separate, then you can in fact achieve immutability easily here. I just wanted to point out that what you call immutability is not in fact immutability, because otherwise you are liable to repeat that mistake even if you were to add a layer of indirection.

An example based on the scenario above would involve a new type struct CustomerWithLoadedOrders

You've basically just reinvented the DTO.

It's interesting to see that you first balk at the thought of having to develop a separate type (think of the work it will cause), and then solve the problem by... developing a separate type.

Credit where credit is due, you have written a great question here. You've elaborated on all the considerations and your thought process. You've done your due diligence and I would definitely not accuse you of not thinking things through.

But your eloquence means you're clever, and clever is dangerous in the field of clean coding. Clean code is boring, but boring is good. Being clever can become your undoing, when it leads you to try and cleverly work around a commonly accepted feature, somehow end up doing it anyway (just with a different name), and then not realize that you've done the same thing you were avoiding, and it's now needlessly more complex because its atypical and therefore harder to understand.

Take this from me, someone who is infinitely attracted to clever solutions, that the unsexy truth is that good practice and cleverness rarely go hand in hand. There's a reason why Code Golf has zero overlap with any good practice principle.