It all comes down to what you consider to be a "view-specific". If that is a calculation of screen resolution or browser version - then absolutely. If you are talking about duration that is simple enough, I'd think twice. It might look simple, but actually in the future can evolve - just keep it in BLL.
In comments you mentioned period duration. This might look simple just now (End - Start).Date
. But this might evolve later into calculate the duration of this period excluding Weekends (for example). And this is definitely BLL, not even Mapping layer.
I've done a views with logic embedded. And then I've seen these views evolving. This was not pretty. Ended up gutting ALL the logic out of views and placing that into a QueryHandler<T>
. So my rule of thumb is to do all calculations in BLL (or Query Handlers if you are using CQRS). And just give prepared data to a view. (Also this approach minimises the need for mapping layer). This way your view only has a Single Responsibility - display data in the required format.
As for mapping layer, again I prefer to have minimum logic there. I allow for DateTime
to be converted to a String
in format 2 Feb 2014
, but anything more than that and you are in trouble again.
Paging is a spread-out concept. It is not really Business Logic, but also not a responsibility of a View. But because it goes so deep into the application, it ends up with BLL anyway (Or Query Handlers in our case).