Ich vermute, das Drucken hängt an der Form selber.
Am einfachsten ist es immer noch, alles in der Form darzustellen und einen Screenshot davon zu drucken.
In's Business-Layer würde ich das aber nicht legen, sondern vielleicht die Grundlogik zum Drucken.
Was am Ende gedruckt werden soll - und das ist vermutlich der eigentliche Aufwand - gehört meiner Meinung nach aber in die View-Ebene.
Was das MVVM angeht, ganz grob beschrieben:
Die View-Ebene wird in zwei Ebenen aufgesplittet: View und ViewModel
Die View hat einzig die Aufgabe darzustellen. Keine Logik, die nicht explizit zur Darstellung (z.B. Animationen) gehört.
Das ViewModel ist die Datenquelle von der View, sie bekommt die Daten von irgendwo (z.B. mehrere BusinessObjects) und bereitet sie so auf, dass die View sie direkt und ohne Aufwand nutzen kann. Im Idealfall kann die View per DataBinding ein Feld an eine Property im ViewModel binden. Oder sie nutzt die Funktionen, die das ViewModel bereit hält (z.B. Anmeldungsformular öffnen und dessen Daten empfangen).
Ziel ist es, die reine Darstellung, die schwer bis gar nicht zu testen ist, von der gut testbaren Logik zu trennen. Zusätzlich kannst du bei Bedarf die View komplett austauschen, ohne die View-Logik, die ja im ViewModel liegt, mit übertragen zu müssen. Außerdem - so empfinde ich das - trägt es viel zur Übersichtlichkeit bei, da komplexere Controls sich leicht verständlich auf zwei rund halb so große Klassen splitten lassen.
Am besten funktioniert das mit WPF, das MVVM-Pattern ist auf WPF zugeschnitten und umgekehrt, viele Features von WPF machen das ganze View-Layer auf diese Weise deutlich "schöner". Bei WPF kann man auch nur mit dem MVVM-Pattern wirklich jedes Feature effektiv ausnutzen.
Bei Forms geht das auch und ist in gewisser Hinsicht bestimmt auch besser als alles Andere, aber es ist nicht so angenehm umzusetzen.