Konsekwencje podziału aplikacji na trzy warstwy

0

Zacząłem niedawno tworzyć nowy projekt (w zamyśle spory), i oczywiście ładnie wydzieliłem w nim 3 warstwy - prezentacji, 'biznesową', oraz dostępu do danych.

O ile z połączeniem PL/BL sobie jakoś radzę, nie wiem jak dobrze napisać interfejs BL/DAL - pierwsza rzecz, czyli czytanie pliku.
Muszę z niego odczytać pewne dane, powiedzmy, listę obiektów. Te obiekty są óżnych klas i łączy je dość mętne powiązanie, implementują wszystkie interfejs, for ex. IObiekt.
I są to obiekty zdecydowanie biznesowe - warstwa dostępu do danych nic o nich nie wie. I teraz jak przeczytać i przekazać tą listę?

Wpadłem na kilka pomysłów, z czego żaden nie wydaje mi się dobry :)

  1. Stworzenie pasywnych (bez żadnych metod) odpowiedników obiektów biznesowych i wczytywanie/przekazywanie ich. Tak zacząłem, ale ilość typów obiektów do serializacji rośnie i nie wiem czy podążam właściwą drogą.
  • zalety: wygląda na czyste 'akademicko' rozwiązanie.
  • wady: wygląda na czysto 'akademickie' rozwiązanie, dużo nadmiarowego kodu...
  1. Wyrzucenie obiektów biznesowych do DAL
  • zalety: zero pisania
  • wady: brzydki kod :/
  1. Stworzenie ogólnej klasy Dataz kilkoma polami danych i polem ElementType (który wskazywałby na co skonwertować po stronie BL) która służyłaby do zapisywania wszystkich pól.
  • zalety: brak?
  • wady: brzydki kod, dużo pisania, podatne na błędy.

Ogólnie nie wiem co z tym zrobić... Na pewno dużo osób tutaj pisało takie aplikacje, w jaki sposób radzi się z takimi problememi?

I jeśli już przy odczytywaniu jestem - jak powinien wyglądać interfejs do odczytywania informacji? Ja stworzyłem statyczną klasę TypWczytywanegoObiektuDataLoader z metodą Load(string filename) i też nie jestem pewnie właściwości takiego rozwiązania

PS. Uprzedzając pytanie po co warstwa danych jeśli nie korzystam z bazy danych - nie wiem :). Ale jestem zdeterminowany.

1
  1. Możesz zdublować klasy, spotkałem się z takimi rozwiązaniami. Niby pozwala to na seperację i autonomiczność źródła danych i oderwanie go od całości aplikacji. W przepisywaniu właściwości z jednych klas do innych może pomóc zewnętrzne rozwiązanie np. dla .NET jest coś takiego jak AutoMapper. Ale to nie jest DRY!
  2. Nie do DAL, tylko do nowej "warstwy" - Modelu. DAL będzie znał Model i BL będzie znało Model. Ja bym zastosował takie rozwiązanie, bo nie wymaga pisania kodu, wszystko jest w jednym miejscu, no i można całkowicie zmienić DAL, a aplikacja będzie działać.
  3. Z takimi pomysłami to można trafić do perełek. ;)

1 użytkowników online, w tym zalogowanych: 0, gości: 1