Skoro według ciebie IQueryable nie powinno opuszczać struktur DAL to w takim razie zwracać IEnumerable.
Ale korzystać z IQueryable w ciele metod DAL? By osiągnąć Lazy loading?
Tak, chociaż z LL to nie ma nic wspólnego.
Metoda GetAll do rozdzielenia metod pobierających.
Użyjesz jej kiedykolwiek?
Dane obiektów biznesowych zazwyczaj pobiera się pojedynczo, albo jako stronę (do wyświetlenia określonej liczby rekordów w jakiejś tabelce).
Jedynym miejscem, w którym trzeba pobrać wszystkie rekordy to jakieś słowniki (np. stawki VAT) do wypełnienia jakiegoś dropdowna.
Ale czy w przypadku obiektów biznesowych, czy słowników, trzeba sobie odpowiedzieć na pytanie, czy zawsze potrzebujemy wszystkich właściwości danego obiektu. I generalnie nigdy nie potrzebujemy wszystkich - więc po co je pobierać? Po co tworzyć metody, które z definicji nie mają sensu?
Metoda GetAll
jest przereklamowana tak samo jak Delete
oraz w ogóle repozytoria.
// gdzie predicate to albo Func<Entity, bool> albo Linq.Expressions<Func<Entity,bool>>.
Albo?! To jest ogromna różnica - pierwsze spowoduje problem N+1, drugie może nie. (Zakładam, że masz zamiar przekazać to do Where
operując na kontekście Entity Frameworka.)
Znaczy modele mam w DAL w models a ViewModele w Models/ViewModels w warstwie prezentacji(kontrolery, widoki) i chcę je zmapować automatycznie jakimś mapperem to w BLL podczas pobierania i wysyłania?
O ile Cię dobrze rozumiem, to modelem nazywasz obiekty opisujące strukturę tabel w bazie. Zapewne wziąłeś to przekonanie z tutoriali, w których wszystko przedstawia się w maksymalnie uproszczony sposób, ale to nie jest prawda. Model to to samo co BLL, składa się z obiektów biznesowych (encji) i serwisów. Encje zawierają dane i operacje, i mogą być mapowane na relacje w bazie. Co ważne - nie każda klasa, którą mapuje się na tabelę, jest encją!
Reasumując -nie możesz mieć tych swoich modeli w DAL, bo to nie jest DAL tylko BLL. BLL ma nic nie wiedzieć o DAL, ani też o warstwie prezentacji, więc nie możesz ich w BLL mapować.
Jak zatem połączyć BLL z prezentacją? W warstwie logiki aplikacji, która wystawia serwisy aplikacyjne tworzące swego rodzaju API, z którego korzysta warstwa prezentacji, aby operować na modelu. I w warstwie aplikacji powinno następować mapowanie encji biznesowych na jakieś DTO (które warstwa prezentacji przetworzy sobie) albo od razu na viewmodele.
Skoro mówisz, że korzystanie z DAL w kontrolerach zabija MVC to przepuszczać DAL poprzez BLL więc i w warstwie biznesowej trzeba mieć metody do komunikacji.
Nie rozumem tego zdania.
Serwisy w BLL, mógłbyś podać jeszcze jakieś inne możliwości? Co może być takim serwisem? Logiką? Czy może to być logika sprawdzania danych przeniesiona z kontrolera? Tak by wywoływał on tylko BLL i zwracał result?
Walidacja danych to także część logiki biznesowej. Ale walidacja powinna być także po stronie logiki prezentacji, aby w ogóle bezsensownych danych nie wysyłać niepotrzebnie do przetwarzania.