Entity Framework aplikacja dwuwarstwowa czy trójwarstwowa?

Odpowiedz Nowy wątek
2017-11-04 11:42
0

Witam,
Aktualnie tworzę aplikację w WinForms z wykorzystaniem Entity Framework. Jednak nie umiem określić czy moja aplikacja jest dwuwarstwowa czy trójwarstwowa mianowicie na msdn znalazłem informacje że Entity Framework umożliwia tworzenie zarówno aplikacji dwuwarstwowych oraz trójwarstwowych. Wygląda to następująco:

dwuwarstwowa - Warstwa prezentacji(WPF) -> Warstwa dostępu do danych (Entity Framework)
trójwarstwowa - Warstwa prezentacji(WPF) -> Warstwa pośrednia (WCF) -> Warstwa dostępu do danych (Entity Framework)

W mojej aplikacji nie korzystam z WCF tylko WinFroms i Entity Framework.

Jednak z definicją podaną na studiach gdzie aplikacja trój warstwowa to:
Warstwa prezentacji -> Warstwa biznesowa (odpowiedzialna za przetwarzanie danych (żądań) od użytkownika. W tej warstwie realizowane są wszelkiego rodzaju funkcjonalności biznesowe) -> Warstwa danych

To wydaje mi się że Entity Framework jest właśnie tą warstwą biznesową.

Czy ktoś by mógł to wytłumaczyć ?

Pozostało 580 znaków

2017-11-05 03:17
1

Entity Framework pozwala na tworzenie aplikacji gazylion warstwowych, bo to od Ciebie zależy, co z nim zrobisz, a bez kodu nie da się powiedzieć, co Ci wyszło.
Przy typowej implementacji EF jest używany w warstwie dostępu do danych, wrzucanie do niego logiki biznesowej nie jest zalecane.

Pozostało 580 znaków

2017-11-05 19:19
1

EF nie jest zadna warstwą. Jesli masz wywolania ef w oknach to nie jest to 2 warstwowa aplikacja. Jesli masz jakies serwisy opakowujace komunikacja z db lub reppzytoria udostepniajace dane dla okien to mozna mowic o 2 warstwach.

Pozostało 580 znaków

2017-11-06 08:56
0
jacek.placek napisał(a):

EF nie jest zadna warstwą. Jesli masz wywolania ef w oknach to nie jest to 2 warstwowa aplikacja. Jesli masz jakies serwisy opakowujace komunikacja z db lub reppzytoria udostepniajace dane dla okien to mozna mowic o 2 warstwach.

EF jest jak najbardziej pełnoprawną warstwą abstrakcji nad źródłem danych, inną sprawą jest czy jest wystarczającą dla danego projektu i czy nie potrzebujemy jej dalej opakować by osiągnąć jakieś wymagania poza funkcjonalne stawiane przed naszą architekturą.

Pozostało 580 znaków

2017-11-06 12:36
2

EF nie jest warstwą tylko biblioteką ORM. Warstwę DAO możemy zaimplementować przy użyciu EF.


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."

Pozostało 580 znaków

2017-11-06 18:19
0

@neves: Ja to sie nie znam ale trudno chyba mowic o abstrakcji jak musisz wstawiac kod zapytania do widoku
Wszystkie where, group, orderby itp. Crudy to przeżyją ale utrzymanie takiej nawet średnią aplikacje to masakra.

Pozostało 580 znaków

2017-11-06 18:52
3

Użycie EF czy innego ORM'a wcale nie świadczy o tym, że aplikacja jest już z automatu wielowarstwowa i spełnia założenia MVC czy MVVM, tak jak to nam wiele razy próbuje się usilnie wciskać w różnego rodzaju tutorialach. Tam wielu, zapewne "bardzo mądrych" ludzi tworzy sobie katalog o nazwie Model, w którym to trzyma sobie encje i całe to barachło z EF. Ludzie Ci wciskają swoim widzom, tudzież czytelnikom, że to właśnie jest warstwa modelu w wyżej wymienionych wzorcach i, że już mamy super zapewnioną separację. Bo wiecie... se folder utworzyli to znaczy, że kod separują, prawda? A GUZIK!

Tak zwana warstwa w aplikacji to tak naprawdę samodzielny byt, który można dołączyć np. do projektów z testami jednostkowymi i testować niezależnie od całości solucji. Posiadając osobno projekt modelu guzik powinno obchodzić Cię to co znajduje się wyżej. Model dostarcza np. interfejsy w postaci serwisów, z których korzystają warstwy wyżej. Na tym poziomie abstrakcji guzik obchodzi Cię, czy skorzysta z tego aplka webowa czy jakieś inne ustrojstwo, chociaż tutaj może trochę przesadzam, bo jakieś odgórne zalecenia zawsze są i dostosować się trzeba. ...i to jest właśnie backend, który żyje własnym życiem i dostarcza takie... hmm... "API" dla tego co będziesz chciał do tego podłączyć.

Dostarczasz również dane do wyższych warstw z takich serwisów i tutaj również NIE za pomocą gołych emcji z hinduskich tutoriali tylko wydelegowanych specjalnie do tego DTO. I naprawdę: wdrażając MVC czy MVVM nie musi być żadnych wuceefów ani czegoś tam innego. Aplikacja trójwarstwowa, która jest dobrze zrobiona posiada realnie działającą separacje tychże warstw. A co to oznacza? Ano to, że jak w takim modelu zmienisz pincet rzeczy to VM czy kontroler wyższej warstwy nawet tego nie zauważy. Powiadasz: ale tak się nie da zrobić! Da się i się robi.

Robi się:

  • interfejsując serwisy, które wystawia model;
  • używając kontenerów IoC do zarządzania serwisami, choć to tylko czubek góry lodowej;
  • korzystając z DTO czy (albo nawet i) tworząc Viewmodele;
  • korzystając z event aggregatora do komunikacji pod spodem, jeszcze bardziej separując od siebie już nawet pojedyncze viewmodele (tutaj mowa o MVVM).

Da się, da :)

PS: Ba... w MVVM wielokroć same viewmodele są interfejsowane i wsadzane jako osobny projekt do solucji :)

edytowany 3x, ostatnio: grzesiek51114, 2017-11-06 19:26
co masz na myśli pisząc serwis? Do czego służy taka klasa? - discoStar 2017-11-08 03:46
to jest taka klasa zwykle implementująca jakiś interfejs w zależności do tego co ma robić, która wystawia na zewnątrz modelu DTO z danymi, coś tam liczy, ma w sobie logikę biznesową, potrafi przyjąć z wyższych warstw odpowiednie dane i coś z nimi robić, nie wystawiając na świat gołych encji np.: zautentykować usera. Trochę jak usługa z Windowsa. :) Bindujesz później taki interfejs z implementacją w IoC i wstrzykujesz przez konstruktor do viewmodeli czy kontrolerów. - grzesiek51114 2017-11-08 07:16

Pozostało 580 znaków

2017-11-06 21:19
1
jacek.placek napisał(a):

@neves: Ja to sie nie znam ale trudno chyba mowic o abstrakcji jak musisz wstawiac kod zapytania do widoku
Wszystkie where, group, orderby itp. Crudy to przeżyją ale utrzymanie takiej nawet średnią aplikacje to masakra.

Zauważ że nie wstawiasz tego kodu w języku SQL, tylko za pomocą abstrakcyjnego obiektu zapytania(Fowler PoEE Query Object), czyli jesteś kompletnie niezależny od źródła danych które jest pod spodem. Co daje nam warstwę i abstrakcję nad źródłem danych.

Oczywiście w wielu wypadkach nie jest to wystarczające i dalej rozbudowujemy tą warstwę ...

somekind napisał(a):

EF nie jest warstwą tylko biblioteką ORM. Warstwę DAO możemy zaimplementować przy użyciu EF.

Jak już się tak czepiamy szczegółów, to DAO też nie jest warstwą ;), no ale uściślijmy :

Za pomocą EF można zaimplementować minimalną warstwę abstrakcji (DAL) nad źródłem danych bez używania żadnych dodatkowych konstrukcji takich jak DAO ;)

Tak, chodziło mi oczywiście o DAL, a nie DAO. Dzięki za sprecyzowanie. - somekind 2017-11-06 21:50

Pozostało 580 znaków

2017-11-07 02:04
0

@neves: A czy to ma znaczenie w jakim języku? SQL, Linq, Criteria... Tak czy siak masz kod warstwy DAL osadzony w innej warstwie (widok, logika...) i to chyba kasuje abstrakcyjność takiego rozwiązania. A QueryObject też nie powinien raczej być stosowany warstwach innych niż DAL (okna w WinForms czy kontrolery w web). To tylko taki interpreter SQL <=> objects, żeby w czystym SQL-u nie grzebać bez potrzeby co wynika z podanego przez Cienie linka.

Projekt okienkowy WinForms nawet nie musi (nie powinien?) mieć referencji do EF bo referencje do EF mogą być w projekcie DAL. Niech się mądrzejsi wypowiedzą, czy np. brak referencji do EF w projekcie WinForms może określać ogólnie, wstępnie aplikację jako 2-warstwową.

Już pomijam użycie warstwy DAL w różnych projektach (desktop, web, mobile, api) bo czasami się tego nie potrzebuje ale jak masz kod DAL (ponownie, obojętnie w jakim języku, SQL, Linq, Criteria) w okienkach to on jest tam i nigdzie indziej. Jak to mówi Sławek Sobótka na YT, taki kod jest totalnie zakodowany.

Szczególnie w WinForms gdzie, jak ktoś nie zna lepszych rozwiązań, kusi użycie long live contextów dla okien lub nawet całej aplikacji i bindowanie wyników z EF (śledzonych) bo tak jest w tutorialach o czym pisał już @grzesiek51114. Kusi bo jest takie fajne, super szybkie ale jak to z kuszeniem, kończy się zwykle fatalnie. W super prostych CRUDach (ale takich naprawdę SUPER prostych) albo jakichś szybkich prototypach to może i ma jakiś sens ale w normalnych aplikacjach to raczej nie. Ja kiedyś coś takiego zrobiłem w dużej aplikacji i jak klient dzwoni, żeby coś zmienić czy poprawić to się zastanawiam dłuższą chwilę czy odebrać telefon :)

No i cały ten SOLID :)

Pozostało 580 znaków

2017-11-07 07:25
0

ale w normalnych aplikacjach to raczej nie. Ja kiedyś coś takiego zrobiłem w dużej aplikacji i jak klient dzwoni, żeby coś zmienić czy poprawić to się zastanawiam dłuższą chwilę czy odebrać telefon

Sam sobie odpowiedziałeś. :) To w żadnych apkach nie ma sensu, bo a nóż zdarzy się tak, że ktoś o tym zapomni i tak już zostanie i będziecie mieli bardzo nieprzyjemnego babola do poprawiania tylekroć ilekroć coś trzeba będzie zmienić w modelu danych.

Na szczęście klient płaci za zmiany bez szemrania za każdą godzinę nawet jeśli jest ich 10 razy więcej niż powinno przy drobnych zmianach :) - jacek.placek 2017-11-07 12:30

Pozostało 580 znaków

2017-11-07 08:50
1
jacek.placek napisał(a):

@neves: A czy to ma znaczenie w jakim języku? SQL, Linq, Criteria... Tak czy siak masz kod warstwy DAL osadzony w innej warstwie (widok, logika...) i to chyba kasuje abstrakcyjność takiego rozwiązania. A QueryObject też nie powinien raczej być stosowany warstwach innych niż DAL (okna w WinForms czy kontrolery w web). To tylko taki interpreter SQL <=> objects, żeby w czystym SQL-u nie grzebać bez potrzeby co wynika z podanego przez Cienie linka.

Ma ogromne znaczenie ! Różne bazy danych używają różnych dielektów sql, zresztą entity framework może operować na dowolnym źródle danych dla którego dostarczysz mu providera (chociażby bazy w pamieci). Więc w teorii możesz podmienić żródło danych i dzięki warstwie DAL stworzonej za pomocą EF nie musisz nic zmieniać w warstwach które od niej zależą. Bo te warstwy zależne od DAL używają abstrakcyjnego języka który jest interpretowany na SQL specyficzny dla relacyjnej bazy danych, ba to nawet nie musi być SQL.
Czyli mamy warstwę -> bo dzięku EF nie uzywamy niczego co jest pod spodem niej, czyli specyficznych driverów do naszego wybranego źródla danych
Czyli mamy abstrakcję -> bo zapytania tworzymy w uogólnionym języku który jest tłumaczony na specyficzny język źródla danych

Jak dalej zauważyleś w wielu przypadkach bazowanie na samym EF nie jest dobrym pomysłem, ale to nie zmiena faktu że sam w sobie EF jest warstwą abstrakcji źródła danych i nie może tego skasować to że użycie jego samego jako DAL moze się skończyć katastrofą dla projektu :).

edytowany 1x, ostatnio: neves, 2017-11-07 08:52

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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