Search code examples
asp.net-mvcseparation-of-concerns

Separation of concerns versus performance?

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?

Solution

  • 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.