3 Schichten, DataSets & Co.

Hi, ich hab mir die Tage mal einige Beiträge bezüglich der Aufteilung in 3 Schichten (auch im Zusammenhang mit DataSets) durchgelesen und möchte meine Anwendungen natürlich möglichst gut trennen.

Was die DataSets dabei angeht, gibts ja eine ganze Menge verschiedenster Meinungen (Rainbird: Pro, JuyJuka: Contra, etc.).
Die Beiträge waren echt interessant. Genauso wird der Blog von Rainbird:
http://yellow-rainbird.de/blogs/rainbird/archive/2008/03/18/ich-m-246-chte-f-252-r-typisierte-datasets-eine-lanze-brechen.aspx

Jetzt möchte ich gerne wissen, ob ich es halbwegs verstanden habe.

Das Beispiel:
So, nicht lachen: Es handelt es sich um eine simple Datenstruktur für ein Kochbuch:

(DB-Diagramm siehe angehängtes Bild)

Die Frage ist, wie kann solch eine Anwendung am schönsten Aufteilen?
In meinem ersten Ansatz habe ich mich für eine Benutzung von DataSets entschieden, weil dadurch das Handling in der UI erleichtert wird
(bitte nicht schreien, hab ein wenig UML-Mischen gespielt)

(Bild siehe Anhang)

In dem Kasten sind in einem getrennten Assembly meine typisierten DataSets die als DatanContainer dienen.

++Nun habe ich leider ein paar offene Fragen zu solch einer Struktur++1. Schnittstelle zur DataAccessLogic (IDalAccess): Wie kann ich meinen Datenrückweg, also den Schreibvorgang, am besten lösen? Für jede Tabelle eine separate Methode? Oder das ganze DS übergeben (nicht ellegant oder)?

1. BusinessLogic so in der Art Ok (mit den Speichermethoden pro Tabelle)?
   Wie kann die m:n - Beziehung tblZutatRezept am besten gehandelt werden?

2. An welcher Stelle erfolgt/erfolgen die Validierung(en) der Datenwerte?

3. Mir ist gerade aufgefallen, ich habe gar keine BusinessObjekte. Sind diese in meinem Fall überflüssig, bzw. die DataSets ein Ersatz dafür?

4. Wie würdet ihr das gegebene Bsp. (besser) aufteilen?

Bin irgendwie von Möglichkeiten überschüttet und sehe den richtigen Weg nicht 🤔
Würde mich deshalb sehr über Vorschläge freuen! =)