Designing Menu Displaying Multiple Categories

Question

I am looking for help designing the code to create a menu displaying multiple categories. Currently, the code (classic asp) makes a call to the database and then loops through the results, so it is all inline. I am porting the code to MVC 5/C#. What I am doing now is getting all the categories from the database, passing them to the view, and then for each category I loop through the results to create the menu items. This doesn't seem like the worst plan, but it does have the code smell of having to run a linq query for each category in the razor view. So I am hoping someone out there might have a better idea or would let me know if this is an acceptable option. Just to add to the conversation, here are the options I currently think I can choose from.

Option 1 - Create a ViewModel with all the categories already separated. In this case I would handle all the sorting in the controller and then all the view would do is iterate the results. The draw back in my mind is that any changes to the menu structure requires me to change the view model, so I need to update files on the server.

Option 2 (one I am using now) - Set the list of categories as the model for the view and in the razor code, let it filter the categories I need for the particular menu group and then iterate over them to create the menu items. This gives me more flexibility, since I can change the view without needing to recompile the code. The draw back is having to run linq queries in the code.

If anyone can think of any other worthwhile options I would appreciate the help.

Answer 1

This sounds like a micro-optimization to me.

Unless proven otherwise by rigorous testing, micro-optimizations are often a waste of time. You might save a few milliseconds off your execution time, but the cost is code that's harder to read and more difficult to maintain.

You have to balance the amount of time saved in the execution against the additional time required for the developers to maintain the code.

I'd go with the simplest, easiest to understand code as possible. That sounds like your Option 2 with the linq queries.

If you want to feel better about it, try using System.Diagnostics.Stopwatch to see just how much that linq query is costing you. I'd be surprised if it's over 200 milliseconds.