How best to design and implement a page elements model, and it's logic?

Question

In order to keep my views as uncluttered as possible I’m removing all logic that determines the state/appearance of 'dynamic' page elements, ie highlighting selected items, greying out buttons that are not context relevant, etc. etc.

Htmlhelpers will be used for this. What I'm not so sure about is where to place the model for the page elements whose state is 'dynamic', and the logic that processes them before they hit the htmlhelper.

Can this be incorporated directly into a page’s viewmodel, or should it be separated out and into it’s own class. I can’t see any advantage to the latter approach, but I'm asking now before I commit myself to a path I may regret having taken further on down the road, as has happened before. …

Answer 1

Can this be incorporated directly into a page’s viewmodel, or should it be separated out and into it’s own class

If I understand you correctly, then your question is something like this -

I have 10 person objects, out of 10 (this can change in future say 20 persons or etc, so this is dynamic) persons, I have 6 males and 4 females (this proportion also changes dynamically). And out of 6 males, one is physically disabled (this too changes with time, so dynamic). So questions are -

1. Where do we have logic to identify given a person male or female?
2. Where do we have logic to identify given a person is physically disabled or not?
3. Where do we apply proper style to Physically disabled person?

If I am right with your understanding, then my answer would be as follows -

The logic for (1), (2) would be your Model classes. Then when you construct your ViewModel from Model classes (though constructing ViewModel from Model is not necessary, assuming you are having ViewModels), those corresponding properties from Model should be persisted in ViewModel. There might be some complex calculations required in some cases, then that specific calculations (provided those calculations are worthy for business) needs to be gone into business logic layer. But if there are calculations like formatting numbers, rounding precisions, convert upper to lowercase etc., they they are specific to View, so that calculations needs to go into View Models.

For (3), I would say I will have that logic in View itself. A simple ternary operator in Razor would be more appropriate for this calculation. I wouldn't take any code related to styles (or its related) to Controller Actions and neither to business logic layer.

HTH!

UPDATE1

Example: Page has 7 buttons to be switched on or off, and styled, according to the status of an invoice. The viewmodel processes the logic for the button model and the view will pass this to the custom htmlheper button. M question is, does this approach, of including processing logic in the view-model, have a flaw? No processing, either complex or reusable, will occur. (3) CSS styling can be included in the view using ternaries but if tag.addcssclass can do this, isn't this a better solution, both tidier and OOP compliant?

Processing logic in ViewModel is fine, but at the same time debatable. At least in my perspective like this -

• Want to show different color for different status of invoice? Then Status calculation logic will reside in Business logic layer.
• Want to show different color for different range of amounts on invoices? Then categorizing invoices into different group of colors will be done by ViewModel Logic.
• Want to show different formatted money display? then that logiv (either setting up proper culture or using String.Format()) would be going into HtmlHelpers or Views.

Coming to you second point with example of tag.addcssclass, I wouldn't do it that way. Usually we will have different set of people for designing, CSS & HTML coding, backend developers. Taking CSS into backend (I mean at least in C# code in ViewModels) is fine for small changes and also this approach is good for code which is getting repetitive (at least throgh HTML Helpers), but for larger chunks (like adding CSS classes based on different scenarios for different fields in ViewModels), it will be hard to maintain between different sets of people who are involved. Also in my perspective, it will hard to understand over period of time.