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 -
- Where do we have logic to identify given a person male or female?
- Where do we have logic to identify given a person is physically disabled or not?
- 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.
