Architektura ASP.NET

1. IQueryable - Używać wszędzie czy tylko w/przed zapytaniem do bazy? Jeśli tak to jak?
   a)

 IQueryable<Entity> GetAll()
{
return db.EntitySet;
}

b)

 ICollection<Entity> GetAll() // może IEnumerable?
{
IQueryable<Entity> x = db.EntitySet; // jakieś metody? ToList? 
return x;
}

2. Co powinno znajdować się w Buisness Logic Layer(BLL)?
   W DAL mam dostęp do bazy za pomocą generycznego repozytorium i uow to w BAL mam opakować to jeszcze raz w np. Service i tutaj metody Add, delete?

Czy może w kontrolerach korzystać bezpośrednio z DAL?
Mapowanie obiektów między Model a ViewModel w kontrolerze czy BAL?

Czym BAL powinnien się zajmować i co posiadać?

1. IQueryable to szczegół implementacji warstwy DAL, więc nie powinien jej opuszczać.
   Po co Ci w ogóle metoda GetAll?

2. Logika biznesowa, co dokładnie to zależy od domeny Twojej aplikacji. To nie ma być opakowanie na DAL, tylko z niego korzystać, gdy potrzebuje coś zapisać/odczytać z bazy. Logika biznesowa to np. utworzenie obiektu faktura na podstawie zamówienia, naliczenie rabatu klientowi i wysłanie jej do druku.

Można w kontrolerach korzystać z DAL, ale moim zdaniem trudno to wtedy nazywać MVC.
Logika biznesowa to np. różne serwisy, jak chcesz je mapować na ViewModele?

Dzięki za odpowiedź.

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?

Metoda GetAll do rozdzielenia metod pobierających.
Mam coś takiego:

 
Entity Get();
Entity Get(predicate);
IQueryable<Entity> GetAll();
IQueryable<Entity> GetAll(predicate);

// gdzie predicate to albo Func<Entity, bool> albo Linq.Expressions<Func<Entity,bool>>.

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?

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.

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?

Zimny Szczur napisał(a):

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.

GetAll używam by pobrać wiele obiektów np. do wyświetlenia w tabeli a przeciążoną opcje np. gdy jest możliwość wyświetlanie tylko kilku lub pod jakimś kryterium.
Get dla pojedynczych do Details, delete itd...

Znaczy te modele to klasy POCO.

Krzywy Orzeł napisał(a):

GetAll używam by pobrać wiele obiektów np. do wyświetlenia w tabeli

I wyświetlisz w ten sposób milion obiektów w tabeli?

Hmm? No nie.

Pobieram i wyświetlam np. 500 tyle ile jest ustawione pageSize.
Albo pobieram wszystko i wrzucam do jakieś operacji asynchronicznej w tabeli co sprawdza jakieś warunki lub coś.

A nie lepiej byłoby pobrac tyle, ile potrzeba zamiast pobierac wszystko i wyswietlac jakas czesc tych danych? ;>

Krzywy Orzeł napisał(a):

Hmm? No nie.

Pobieram i wyświetlam np. 500 tyle ile jest ustawione pageSize.
Albo pobieram wszystko i wrzucam do jakieś operacji asynchronicznej w tabeli co sprawdza jakieś warunki lub coś.

Taaa nie ma to jak pobierać parę milionów rekordów tylko po to żeby wyświetlić pierwsze 500, po czym i tak użytkownik oleje te 500 i pozostałe miliony bo go i tak interesuje zwykle jedna konkretna pozycja w danym czasie. :P