Separation of concerns versus performance?

Question

I have an ASP.NET MVC site and I am trying to figure out separation of controller and model (repository) and HTML helper functionality.

The goal is to query a database table of photo albums information and display it grouped by year.

The steps are:

1. Query database and return datatable of the database information.
2. Convert Datatable to AlbumCollection (List)
3. Bucket albums by year into ALbumDictionary
4. Render each year in a seperate HTML table.

Given this request, I could see: 1,2,3 all in the model and the controller simply binds the View to the AlbumDictionary model or 1,2 in the model and bind to the AlbumCollection and 3 in a HTML ViewHelper or 1,2 in the model 3 in the controller and bind to the Albumdictionary

Thoughts?

Doing every conversion in the first loop would have the best performance but I am not sure it is the best separation of concerns.

In particular to the above question, generic feedback would be interesting: when does separation of concerns overrule performance or vise versa?

Answer 1

I would do the bucketing in the controller only if either:

• the bucketing occurs just once and I can do that with one or two simple statements;

• It occurs more than once but I can do that with just a AlbumDictionary.BucketByYear() statement.

Otherwise I'd use models to do that.

Answer 2

I would try to keep the Model clear of anything that has to do with rendering.

I see the grouping by year pretty close to rendering. Thats why I would not put it into Model and also not into the Controller. A common aproach is to have a Model of Poco and DAL/BLL and anonther Model called ViewModel (the Model used by the strongly typed View). This is a good place to prepare the objects for rendering.

In ViewModel I would use Linq to group the albums by years. This will hopefully be fast enough.

Answer 3

Having been a user of some truly horrendous software that I'm sure looked good from an object-oriented perspective to the designers and was even possibly easy to maintain, I want to point out that the users will come down on the side of performance almost every time.

If the performance difference is negligible, follow the separation of concerns, if it is not, do what it takes to get the best performance. We need to stop worrying as much about the extra few minutes to possibly maintain (maybe touching that code once a year once it's in prod) and more about slowness for all the users every day issue. We like to say that development time is so expensive that we need to minimize it, but the truth is that development time is often far cheaper than the amount of time we are asking our users to waste daily.